目录
1.Primary/Standby 模式的库启动后，自动进入 Mount 状态,需要启动守护进程才会open。
2.Standby数据库mount后，DW才会启动主库。
3.如果不停守护进程，数据库stop以后，DW会把进程自动拉起。 INST_AUTO_RESTART = 0 可以关闭自动拉起功能。
监视器关闭
主库DW02，备库DW01
关闭监视器
关闭主库DW02，DW01(备库)仍然是standby，因为没有启动监视器，不会进行switchover。
这个时候，再启动监视器，DW01会切换为primary吗？不会。
把主库DW02启动，守护组恢复正常。
监视器启动，Detach备库
login
detach database xx
stop dmwatcher database xx
startup dmwatcher database xx
attach database xx
主库DW01，备库DW02
执行detach database DW02
退出重新进入监视器，show
备库的归档状态是INVALID
此时我们关闭DW01（主库）
可以看到DW02还是standby，detach备库后，备库不会进行接管。
把DW02加入到DW里
对应的主库DW01是停掉的状态，不允许备库DW02加入。
启动DW01
测试一下，是否会数据同步。
发现数据从DW01可以正常同步到DW02，难道DW02自动加入DW组了？
启动主库后，备库自动加入了。
主备正常，手动switchover
假定Choose Switchover选出的可切换备库是 B，Switchover 切换流程如下：
- 通知主备库守护进程，切换为 Switchover 状态
- 通知主库(A) Mount
- 实时或 MPP 主备环境下，通知备库(B) APPLY KEEP_RLOG_PKG
- 通知备库(B) Mount
- 通知(A) 切换为 Standby 模式
- MPP 主备环境下，通知(A)修改 MPP_INI 内存值为 0
- 通知(B) 切换为 Primary 模式
- 通知(B) 修改所有归档目标的归档状态为无效
- MPP 主备需要通知各组活动主库更新 dmmpp.ctl 文件，参考后文说明
- 通知新的备库(A) Open
- 通知新的主库(B) Open
- 通知主备库守护进程切换为 Open 状态
- 清理所有守护进程上记录的监视器命令执行信息
主库DW02，备库DW01
需要登录，输入login
登录成功后，执行switchover
主库故障，自动switchover
检测到主库故障的情况下，会自动进行switchover
主库DW01，备库DW02
杀掉主库DB进程
检测到故障，自动切换
主库故障，手动Takeover
以备库 B 为例，接管的执行流程包括：
- 监视器通知守护进程(B)切换为 Takeover 状态
- 实时主备或 MPP 主备环境下，通知备库(B) APPLY KEEP_RLOG_PKG
- 通知备库(B) Mount
- 通知(B) 切换为 Primary 模式
- 通知(B) 修改到所有归档目标的归档状态为 Invalid
- MPP 主备需要通知活动主库更新 dmmpp.ctl 文件
- 通知新的主库(B) Open
- 通知守护进程(B)切换为 Open 状态
主库故障的情况下，自动切换失败，可以手动进行切换。
dmwatcher的参数DW_MODE设为MANUAL进行测试：
主库DW02，备库DW01
杀掉DW02进程
可见DW02判断为故障，DW的状态由open变为startup
show看一下状态
主库DW02状态为error，备库DW01状态正常，DW01没有自动切换，我们让备库DW01接管：
takeover DW01
此时，备库DW01切换成了primary。可以看到此时DW02仍然是primary。
再开启DW02，看实例一DW日志：
DW02由Primary转变为standby，DW的状态也变为了startup
后面，DW和DW02状态会变为OPEN，然后进行DW02的恢复
主库故障，备库强制takeover
与正常 takeover 命令相比，强制接管时系统不会对故障主库与待接管备库的数据一致性进行检查，若接管前主备库的数据是一致的，则强制接管与正常 takeover 效果相同，接管成功后不会出现数据丢失的情况，故障主库重启后也能正常加回集群。若接管前主备库的数据不一致，则强制接管后会存在数据丢失，故障主库重启后无法加回集群，出现集群分裂。
典型的主备库数据一致的场景：REALTIME 归档模式，主库故障前到备库的归档状态为 VALID。由于 REALTIME 归档流程为主库先发送日志到备库，等待收到所有备库的响应消息后再将该日志写入本地的联机日志文件中，所以在主库故障后其联机日志文件中已经写入的日志一定不会备库收到的日志更多。这种场景下执行强制接管后不会出现数据丢失，故障主库重启后也能够作为备库重新加入集群，不会发生集群分裂。
强制接管的条件包括：
- 不存在活动主库
- 备库守护进程处于 Open 或 Startup 状态
- 备库实例运行正常
- 备库是 Standby 模式
- 备库处于 Open 或 Mount 状态
- 备库的 KLSN 必须是所有备库中最大的
- 备库守护进程控制文件必须有效
主库DW01，备库DW02
以下继续做测试，杀掉DW01(主库)：
强制接管DW02
由于是realtime同步，强制接管前数据是一致的，所以并没有发生守护组分裂。
开启DW01
过程同前面takeover介绍的一样，DW01状态为standby，状态恢复正常。
主库重启
主库DW02，备库DW01
主库重启，守护进程状态会先变成startup，然后再open，Open 成功后继续作为主库
备库故障
手动切换模式
主库DW02，备库DW01
Kill DW01（备库）
先看监视器，DW01 STANDBY故障
看到DW状态由OPEN变为startup
从故障节点的DW日志里，也能看到：
DW接收不到实例的TCP连接信息，状态置为startup
DW02的状态也会发生变化
守护进程（DW02）先由OPEN到STARTUP，再变为FAILOVER，然后OPEN
实例（DW02）先SUSPEND,再OPEN
公网连接异常
影响：用户无法连接数据库
如果主库公网无法连接，可以手动switchover，将备库切换为主库使用。
主库私网异常
- 主备库之间无法通信
- 守护进程间无法进行通信
3.REALTIME无法归档
4.守护进程无法与主库进行通信
主库挂起后，连接主库的会话会挂住不切换新主库，设置参数SESS_FREE_IN_SUSPEND配置的时间，会话会自动断开老主库。
主库DW02，备库DW01
关掉主库私网网卡
守护进程间无法进行通信,DW02的守护进程为ERROR
DW01的归档为unkonwn，DW02的归档为invalid
守护进程无法与主库进行通信
监视器检测到Primary实例故障，开始执行takeover自动接管
使用备库DW01自动接管成功
重新开启DW02的网卡
守护进程DW02恢复了OPEN，但是实例DW02还是异常
原来是实例当掉了，我们重新开启DW02实例
实例恢复正常，DW恢复正常。
备库私网异常
1.主备库之间无法通信
2.守护进程间无法进行通信
3.REALTIME归档失败
4.守护进程无法与备库进行通信
主库DW01，备库DW02
停掉DW02（备库）的网卡
首先守护进程间无法通信，,DW02的守护进程为ERROR
主库DW01的归档为unkonwn，备库DW02的归档为unkonwn
守护进程无法与主库进行通信，检测到备库故障
主库实例状态suspend->open，wstatus状态failover->open
重新开启DW02的网卡
DW02的守护进程状态由none变为open
主备私网同时异常
主库DW01，备库DW02
两节点同时关闭网卡
守护进程与DW01和DW02间无法通信
守护进程间无法通信
实例之间无法通信
监视器与守护进程无法通信
主备库不会切换，主库状态变为suspend
打开两节点网卡
守护进程：
DW01 none-> failover->open
DW02 none->open
实例：
DW01 suspend->open