DM7 达梦数据库数据守护(Data Watch) (13) -- DW的主备库切换 -- cnDBA.cn

主备库的切换与监视器的配置模式有很大关系，关于监视器，之前的博客有说明，如下：

DM7 达梦数据库数据守护(Data Watch) (4) — 监视器
https://www.cndba.cn/dave/article/3669

1主备库切换

主库维护，滚动升级等场景，可以执行 Switchover 命令，实现主备库切换。如果存在多个备库，需要先执行 Choose Switchover 命令，选出守护进程组中可以切换的备库。

主库守护进程是 Open 状态

备库守护进程是 Open 状态

主、备库守护进程控制文件 dmwatcher.ctl 相同，且为 Valid 状态

主库正常运行

备库正常运行

主库处于 Open 状态

备库处于 Open 状态

主库到备库的归档是 Valid 状态

假定选出的可切换备库是 B，Switchover 切换流程如下：

通知主备库守护进程，切换为 Switchover 状态

通知主库(A) Mount

实时或 MPP 主备环境下，通知备库(B) APPLY KEEP_BUF

通知备库(B) Mount

通知(A) 切换为 Standby 模式

MPP 主备环境下，通知(A)修改 MPP_INI 内存值为 0

通知(B) 切换为 Primary 模式

通知(B) 修改所有归档目标的归档状态为无效

通知守护进程(B)修改控制文件，增加一条切换记录

MPP 主备需要通知各组活动主库更新 dmmpp.ctl 文件

通知新的备库(A) Open

通知新的主库(B) Open

通知主备库守护进程切换为 Open 状态

清理所有守护进程上记录的监视器信息

其中第 10 步，MPP 主备环境下更新 dmmpp.ctl 步骤说明如下：

收集各组的活动主库信息，构造新的 dmmpp.ctl 文件。
主库收集条件：
a. 组中只有一个活动主库，不存在多个 OPEN 主库
b. 主库守护进程不是 Error 状态,且控制文件是有效状态
c. 主库实例不是 Error 状态

通知步骤 1 中收集到的主库更新 dmmpp.ctl 文件
首先通知执行 Switchover 命令的守护进程组的主库执行更新操作，再通知其他组的主库执行更新操作，通知其他组执行更新操作时，会先将其主库的守护进程切换为MPPCTL UPDATE 状态，更新完成后，再切换回 OPEN 状态。
对步骤 1 中不符合收集条件的组，在步骤 2 中跳过不再处理，后续待其主库恢复正常后，可借助 RECOVER MPPCTL 命令恢复 dmmpp.ctl 文件到一致状态。
更新 MPP 控制文件时，服务器自动断开当前所有的会话连接，回滚未提交事务，挂起所有工作线程，该过程可能会持续一段时间。

根据步骤 2 的结果决定是否继续执行 Switchover 的后续步骤
步骤 2 中如果某个活动主库更新失败，则终止切换，执行失败。
主备库切换在实现逻辑上等同于主备库正常状态下，用户主动发起的Takeover 操作。Swithover 完成后，主备库之间数据是不完全同步的；要由新主库 B 的守护进程通过 Recovery 流程，重新同步数据和dmwatcher.ctl 到新备库 A。

Switchover 命令，会修改切换后主库守护进程 INST_RECOVER_TIME 内存值为 0（默认 60 秒），确保尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。在故障恢复流程完成之前，再次执行Switchover 命令会报错，如果主库故障，备库接管将会报错；备库强制接管会引发守护进程组分裂。

2主库故障、备库接管

当出现硬件故障（掉电、存储损坏等）原因，主库无法启动，或者是主库内部网卡故障，导致主库短期不能恢复正常的情况下，可使用备库接管功能，将备库切换为主库继续对外服务。

故障自动切换模式下，确认监视器会自动选择符合条件的备库进行接管。
故障手动切换模式下，可以先在监视器上执行 Choose Takeover 命令，选出守护进程组中可以接管的备库。

为了避免备库接管后，造成守护进程组分裂，执行 Takeover 必须满足下列条件：

主库是 Primary 模式、Open 状态时，产生故障

主库守护进程故障，故障前是 Open/Recovery 状态；或者主库守护进程正常

故障主库到接管备库的归档状态为 Valid

接管备库是 Standby 模式、Open 状态

接管备库的 dmwatcher.ctl 控制文件状态为 Valid

故障主库和接管备库的 dmwatcher.ctl 控制文件相同

假设主库 A 故障时，在故障自动切换模式下确认监视器自动选出待接管备库 B 并通知备库 B 自动接管，或者在故障手动切换模式下，通过监视器上的 Choose Takeover 命令，选出待接管备库 B，在监视器上输入 Takeover 命令通知备库 B 执行接管，这两种方式的接管执行流程是一样的。

以备库 B 为例，接管的执行流程包括：

监视器通知守护进程(B)切换为 Takeover 状态

实时主备或 MPP 主备环境下，通知备库(B) APPLY KEEP_BUF

通知备库(B) Mount

通知(B) 切换为 Primary 模式

通知(B) 修改到所有归档目标的归档状态为 Invalid

通知守护进程(B)修改控制文件，增加一条接管记录

MPP 主备需要通知活动主库更新 dmmpp.ctl 文件

通知新的主库(B) Open

通知守护进程(B)切换为 Open 状态

例如，主库 C 故障，备库 B 接管。执行 Takeover 命令后，会修改守护进程(B)的 INST_RECOVER_TIME 内存值为 0（默认 60 秒），确保尽快启动 B->C的故障恢复流程，同步主库数据完成后，重新将 B->C 的归档设置为 Valid 状态。在故障恢复流程完成之前，主库（B）故障，备库（C）无法接管；强制备库（C）接管会引发守护进程组分裂。

3备库强制接管

有些情况下，备库接管会失败，但主库不能启动或者及时恢复对外服务的情况下，可以使用 Takeover Force 命令，进行备库强制接管。强制接管具有一定的风险，可能导致备库和故障主库数据不一致，而造成部分数据的丢失，出现数据库分裂的情况，所以应该慎重使用。

比如主库和守护进程故障时，监视器未启动，用户启动监视器后，由于监视器并未收到故障主库任何信息，因此不满足 Takeover 条件，执行 Takeover 会报错。如果用户可确认主库故障时主备数据是一致的（比如故障时主库未执行操作，主备库归档有效的，并且两者的 SLSN 一致）、或者丢失小部分数据的影响可忽略、或者丢失小部分数据的影响小于主库持续宕机造成的影响，则可以考虑执行 takeover force 强制接管。

强制接管，先通过 Choose Takeover Force 选出符合强制接管条件的备库，再执行 Takeover Force 命令。备库强制接管时，如果接管备库是处于 Mount 状态/Standby模式的库，则会自动 Open 备库，其他执行流程与备库接管一致。

强制接管的条件包括：

不存在活动主库

备库守护进程处于 Open 或 Startup 状态

备库实例运行正常

备库是 Standby 模式

备库处于 Open 或 Mount 状态

备库 SLSN 必须是所有备库中最大的

备库守护进程控制文件必须有效

与 Takeover 命令一样，Takeover Force 命令会修改主库守护进程的INST_RECOVER_TIME 内存值为 0（默认 60 秒），确保尽快启动故障恢复流程。
强制接管具有一定的风险，可能导致备库和故障主库数据不一致，而造成部分数据的丢失、数据库分裂，所以应该综合考虑当时情况，慎重使用。

4主库故障重启（备库接管前重启）

主库故障后立即重启，此时主库的守护进程变成 Startup 状态，重新进入守护进程的启动流程，将所有备库归档设置成无效状态，并重新 Open 主数据库。Open 成功后继续作为主库，当检测到备库正常时会启动 Recovery 处理流程，重新同步主备库数据。

5备库故障处理

备库产生故障（硬件故障或者内部网卡故障）时，主库的处理流程对手动切换、自动切换模式处理上有些差异。

5.1 手动切换模式

对于手动切换模式，检测到备库故障，满足 Failover 条件时，主库的守护进程立即切换到 Failover 状态，执行对应的故障处理，如果不满足切换 Failover 条件，则保持当前状态不变。

手动切换模式下，主库守护进程切换 Failover 条件：

备库实例故障，或者主备库之间出现网络故障，或者备库重演时校验 LSN 不匹配，这三种场景下引发主库同步日志到备库失败挂起，主库实例处于 Suspend 状态

主库到此备库的归档状态是 Valid（读写分离集群没有此限制）

主库的守护进程处于 Startup 或 Open 状态

当前没有监视器命令正在执行

5.2 自动切换模式

对于自动切换模式，主库的守护进程会自动判断切换到 Failover 状态或者 Confirm确认状态，如果两种状态切换条件都不满足，则保持当前状态不变。

自动切换模式下，主库守护进程不进入 Confirm 确认状态，直接切换 Failover 条件：

前四项条件，和上面列出的手动切换条件相同

备库实例故障，备库守护进程正常

如果只满足条件 1，不满足条件 2，则主库守护进程会先进入 Confirm 确认状态，等待确认监视器的确认消息。主库的守护进程进入 Confirm 确认状态后，会有下面几种不同的处理：

1. 主库和确认监视器之间网络连接正常

主库的守护进程收到了确认监视器返回的确认消息，如果确认监视器认定可以执行Failover，则主库的守护进程会切换为 Failover 状态并执行对应的处理，如果确认监视器认定不满足执行 Failover 条件，则主库的守护进程会一直保持在 Confirm 状态。确认监视器认定主库可以执行 Failover 条件：

a. 主库守护进程处于 Confirm 状态
b. 主库实例正常，处于 Suspend 状态
c. 主库没有被接管，不存在其他主库
d. 没有 takeover/switchover 命令在执行
e. 当前所有归档有效的备库守护进程控制文件可以加入主库

2. 主库和确认监视器之间网络连接异常，或者没有启动确认监视器。满足下面条件后主库允许切换 failover 状态执行故障处理：

a. 主库实例正常，处于 Open 或 Suspend 状态
b. 备库守护进程正常
c. 主库没有被接管，不存在其他主库
d. 没有 takeover/switchover 命令正在执行
e. 故障备库的守护进程控制文件可以加入主库

3. 主库和确认监视器网络恢复正常后，主库已经被接管。老主库的守护进程切换为Startup 状态，重新判断是否可加入新主库。

主库守护进程进入 Failover 状态后的执行流程（自动或手动切换模式下执行流程相同）：

a. 对实时主备或 MPP 主备，通知主库修改发送归档失败的备库归档状态无效
b. 通知主库重新 Open
c. 将主库的守护进程切换为 Open 状态

6 测试

6.1 监视器命令

在之前的博客中我们提到在监视器中可以执行很多的命令。

DM7 达梦数据库数据守护(Data Watch) (4) — 监视器
https://www.cndba.cn/dave/article/3669

这里有个前提条件就是不能是自动切换模式，否则在监视器中执行命令时会报如下错误：

help
Processing log print or auto takeover now, please retry later
http://www.cndba.cn/cndba/dave/article/3683

http://www.cndba.cn/cndba/dave/article/3683

在自动切换模式中，主备库的启动和切换由监视器自动管理。不需要手工干预。

6.2 kill 备库进程

当前监视器显示一切正常:

[monitor]         2029-03-14 12:42:57: Received message from(GRP2_RWW_01)
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 12:42:57  OPEN           OK        GRP2_RWW_01      OPEN        PRIMARY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 12:42:57: Received message from(GRP2_RWW_03)
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 12:42:57  OPEN           OK        GRP2_RWW_03      OPEN        STANDBY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 12:42:57: Received message from(GRP2_RWW_02)
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 12:42:57  OPEN           OK        GRP2_RWW_02      OPEN        STANDBY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 12:42:57: Received message from(GRP2_RWW_04)
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:39:04  OPEN           OK        GRP2_RWW_04      OPEN        STANDBY   VALID    6        262184         262184         262184         262184    

#Kill 掉一个备库：
[dave@www.cndba.cn2 ~]$ ps -ef|grep dm.ini
dmdba     1591     1  0 Sep13 ?        00:01:11 /dm/dmdbms/bin/dmserver /dm/dmdbms/data/CNDBA/dm.ini mount
dmdba    22715 22602  0 18:48 pts/1    00:00:00 grep dm.ini
[dave@www.cndba.cn2 ~]$ kill -9 1591

#监视器会自动启动从库：

[monitor]         2029-03-14 12:52:19: Instance GRP2_RWW_04[STANDBY, OPEN] error 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:48:26  OPEN           ERROR     GRP2_RWW_04      OPEN        STANDBY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 12:52:19: Dmwatcher process GRP2_RWW_04 status switching [OPEN-->STARTUP] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:48:26  STARTUP        ERROR     GRP2_RWW_04      OPEN        STANDBY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 12:52:34: Instance GRP2_RWW_04[STANDBY, AFTER REDO] recover to OK 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:48:41  STARTUP        OK        GRP2_RWW_04      AFTER REDO  STANDBY   VALID    6        262184         262184         0              262184         

[monitor]         2029-03-14 12:52:35: Dmwatcher process GRP2_RWW_04 status switching [STARTUP-->OPEN] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:48:42  OPEN           OK        GRP2_RWW_04      OPEN        STANDBY   VALID    6        262184         262184         262184         262184         


#查看监视器日志：

[GRP2_RWW_04]      2019-09-14 18:48:33 [INFO] DM watch P0000001523 T0000140062583256832  [!!! Local instance restarted by dmwatcher. !!!]
[monitor]         2029-03-14 12:52:34: <INST CHECK GRP2_RWW_04>
[monitor]         2029-03-14 12:52:34: Instance GRP2_RWW_04[STANDBY, AFTER REDO] recover to OK 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2019-09-14 18:48:41  STARTUP        OK        GRP2_RWW_04      AFTER REDO  STANDBY   VALID    6        262184         262184         0              262184         

[monitor]         2029-03-14 12:52:34: </INST CHECK GRP2_RWW_04>

[GRP2_RWW_04]      2019-09-14 18:48:41 [INFO] DM watch P0000001523 T0000140062581671680  Server public key changed, broadcast new value to monitor


#查看之前kill 的备库进程，有自动起来了：
[dave@www.cndba.cn2 ~]$ ps -ef|grep dm.ini
dmdba    22717     1  0 18:48 ?        00:00:00 /dm/dmdbms/bin/dmserver /dm/dmdbms/data/CNDBA/dm.ini mount
dmdba    22795 22602  0 18:48 pts/1    00:00:00 grep dm.ini
[dave@www.cndba.cn2 ~]$

6.3 Kill主库

[dave@www.cndba.cn3 ~]$ ps -ef|grep dm.ini
dmdba     2676     1  0 Mar13 ?        00:02:03 /dm/dmdbms/bin/dmserver /dm/dmdbms/data/CNDBA/dm.ini mount
dmdba    10138  9563  0 13:07 pts/1    00:00:00 grep dm.ini
[dave@www.cndba.cn3 ~]$ kill -9 2676
[dave@www.cndba.cn3 ~]$ 

查看监视器的自动处理过程：
[monitor]         2029-03-14 13:07:57: Instance GRP2_RWW_01[PRIMARY, OPEN] error 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:07:57  OPEN           ERROR     GRP2_RWW_01      OPEN        PRIMARY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 13:07:57: Dmwatcher process GRP2_RWW_01 status switching [OPEN-->STARTUP] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:07:57  STARTUP        ERROR     GRP2_RWW_01      OPEN        PRIMARY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 13:08:13: Instance GRP2_RWW_01[PRIMARY, MOUNT] recover to OK 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:08:13  STARTUP        OK        GRP2_RWW_01      MOUNT       PRIMARY   VALID    6        262184         262184         262184         262184         

[monitor]         2029-03-14 13:08:14: Dmwatcher process GRP2_RWW_01 status switching [STARTUP-->OPEN] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:08:15  OPEN           OK        GRP2_RWW_01      OPEN        PRIMARY   VALID    7        267151         267151         267151         267151         

[monitor]         2029-03-14 13:08:17: Dmwatcher process GRP2_RWW_01 status switching [OPEN-->RECOVERY] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:08:18  RECOVERY       OK        GRP2_RWW_01      OPEN        PRIMARY   VALID    7        267151         267151         267151         267151         

[monitor]         2029-03-14 13:08:21: Dmwatcher process GRP2_RWW_01 status switching [RECOVERY-->OPEN] 
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:08:22  OPEN           OK        GRP2_RWW_01      OPEN        PRIMARY   VALID    7        267151         267151         267151         267151

6.4 模拟主库故障

之前我们测试kill进程，都会被确认监视器自动启动。我们这次模拟出库故障。之间删除主库文件，在kill 进程，在这种情况下，主库是无法正常启动的。

#破坏主库：
[dave@www.cndba.cn3 data]$ ps -ef|grep dm.ini
dmdba    10712     1  0 13:24 ?        00:00:00 /dm/dmdbms/bin/dmserver /dm/dmdbms/data/CNDBA/dm.ini mount
dmdba    10940 10913  0 13:28 pts/2    00:00:00 grep dm.ini
[dave@www.cndba.cn3 data]$ cd CNDBA/
[dave@www.cndba.cn3 CNDBA]$ pwd
/dm/dmdbms/data/CNDBA
[dave@www.cndba.cn3 CNDBA]$ ls
bak          ctl_bak     dm.ini                    dmmal.ini                      dmwatcher.ctl  HMAIN             ROLL.DBF    TEMP.DBF
CNDBA01.log  dmarch.ini  dminit20290312091350.log  dm_service.prikey              dmwatcher.ini  MAIN.DBF          sqllog.ini  trace
CNDBA02.log  dm.ctl      dminst.sys                dmsql.buf1868068849525580.buf  GRP2           rep_conflict.log  SYSTEM.DBF
[dave@www.cndba.cn3 CNDBA]$ mv SYSTEM.DBF SYSTEM.DBF.bak
[dave@www.cndba.cn3 CNDBA]$ kill -9 10712

#监视器尝试启动主库：
[GRP2_RWW_01]      2029-03-14 13:29:11 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:29:43 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:30:15 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:30:46 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:31:17 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:31:48 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:32:19 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:32:51 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:33:23 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:33:54 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:34:25 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:34:56 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:35:27 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]
[GRP2_RWW_01]      2029-03-14 13:35:58 [INFO] DM watch P0000003079 T0000140343943522048  [!!! Local instance restarted by dmwatcher. !!!]

从日志看，此时监视器一直在尝试不断重启，并没有发生自动切换的动作。

这种模拟方法无效。恢复之前移除的文件，恢复正常。

6.5 直接将主库网络全部中断，模拟主库异常

[root@dm3 ~]# service network stop
Shutting down interface eth0:  Device state: 3 (disconnected)
                                                           [  OK  ]


#查看监视器日志：
[monitor]         2029-03-14 13:41:30: <RECEIVE TIMEOUT GRP2_RWW_01>
[monitor]         2029-03-14 13:41:30: Received message timeout from(GRP2_RWW_01)
                  WTIME                WSTATUS        INST_OK   INAME            ISTATUS     IMODE     RSTAT    N_OPEN   FLSN           CLSN           SSLSN          SLSN           
                  2029-03-14 13:41:19  ERROR          OK        GRP2_RWW_01      OPEN        PRIMARY   VALID    9        277085         277085         277085         277085         

[monitor]         2029-03-14 13:41:30: </RECEIVE TIMEOUT GRP2_RWW_01>

[monitor]         2029-03-14 13:41:30: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_02[STANDBY, OPEN] can do auto takeover. !!!]

[monitor]         2029-03-14 13:41:30: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_03[STANDBY, OPEN] can do auto takeover. !!!]

[monitor]         2029-03-14 13:41:30: dwmon_tcp_recv failed, close port, vio:0, mid:1868157777, errno:0, code:-6007
[monitor]         2029-03-14 13:41:30: mon tcp port vio(0) close
[monitor]         2029-03-14 13:41:30: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_04[STANDBY, OPEN] can do auto takeover. !!!]

[GRP2_RWW_02]      2029-03-14 13:41:30 [INFO] DM watch P0000029063 T0000140200939845376  Instance: dmwatcher status(ERROR) Instance status(OK) Instance Name(GRP2_RWW_01) Mode(PRIMARY) Instance status(OPEN) Arch status(UNKNOWN) POCNT(9) FLSN(277085) CLSN(277085) SLSN(277085) SSLSN(277085).

这里提示我们主库连接超时，备库2，3，4 可以做auto takeover，但是监视器并没有主动帮我们做这个动作。而是等待。所以这里条件还不满足自动切换的条件。

直接将主库系统关闭：

[root@dm3 ~]# shutdown -h now

Broadcast message from root@dm3
    (/dev/pts/1) at 14:21 ...

The system is going down for halt NOW!
[root@dm3 ~]# 

监视器告警和之前一样，只是提示我们可以切换，并没有自动帮我们做：
[monitor]         2029-03-14 14:21:25: </RECEIVE TIMEOUT GRP2_RWW_01>

[monitor]         2029-03-14 14:21:25: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_02[STANDBY, OPEN] can do auto takeover. !!!]

[monitor]         2029-03-14 14:21:25: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_03[STANDBY, OPEN] can do auto takeover. !!!]

[monitor]         2029-03-14 14:21:25: [!!! Instance GRP2_RWW_01[PRIMARY, OPEN] error, instance GRP2_RWW_04[STANDBY, OPEN] can do auto takeover. !!!]

[monitor]         2029-03-14 14:21:25: dwmon_tcp_recv failed, close port, vio:0, mid:1868157777, errno:107, code:-6007
[monitor]         2029-03-14 14:21:25: mon tcp port vio(0) close
[GRP2_RWW_03]      2029-03-14 14:21:25 [INFO] DM watch P0000028500 T0000140199889864448  Do not receive remote dmwatcher(GRP2_RWW_01) message, original status is OPEN, time after last received msg(11)s, last set remote dmwatcher ERROR.
[GRP2_RWW_03]      2029-03-14 14:21:25 [INFO] DM watch P0000028500 T0000140199889864448  Local instance: dmwatcher status(OPEN) Instance status(OK) Instance Name(GRP2_RWW_03) Mode(STANDBY) Instance status(OPEN) Arch status(UNKNOWN) POCNT(10) FLSN(282052) CLSN(282052) SLSN(282052) SSLSN(282052).
[GRP2_RWW_03]      2029-03-14 14:21:25 [INFO] DM watch P0000028500 T0000140199889864448  Instance: dmwatcher status(ERROR) Instance status(OK) Instance Name(GRP2_RWW_01) Mode(PRIMARY) Instance status(OPEN) Arch status(UNKNOWN) POCNT(10) FLSN(282052) CLSN(282052) SLSN(282052) SSLSN(282052).

7 小结

按照官方的配置测试，主备库切换测试无法成功。鉴于目前官方资料有限，暂时测试到这里，后期有其他内容，在进行补充。

签到成功

CNDBA社区