在达梦数据库主备集群的运行过程中，网络故障是较为常见且可能影响数据库服务稳定性的因素。网络如同“血脉”，一旦出现故障，可能引发数据同步中断、服务不可用等严重问题。接下来，我们将深入探讨达梦数据库主备集群中可能出现的不同类型的内部网络故障及其对应的处理策略。

1.环境说明

准备三台机器部署dm8主备集群，其中192.168.154.30用来部署确认监视器，192.168.154.31和192.168.154.32用来部署主备库，本示例中组名为“GRP1”，配置为实时主备，主库命名为“GRP1_DM1”，备库命名为“GRP1_DM2”。

2.故障模拟

2.1.故障一：监视器与备库网络中断

模拟监视器与备库之间网络故障。监视器与备库网络故障后，监视器提示接收守护进程(GRP1_DM2)消息超时，但是主备机数据库之间数据还是同步的，集群还可以正常对外提供服务。

网络故障处理之后，等待备库守护进程自动重建与监视器的网络连接，备库守护进程状态从NONE，切换至OPEN。

2.2.故障二：监视器与主库网络中断
模拟监视器与主库之间网络故障。监视器与主库网络故障后，监视器提示接收守护进程(GRP1_DM1)消息超时，集群主备机未发生切换。

通过监视器show命令查看，无法查看集群中主库的信息，但是备库也未发生切换，虽然监视提示“组(GRP1)中当前没有活动的PRIMARY实例或PRIMARY实例处于分裂状态或者监视器的MON_DW_IP配置有误”，但是整个集群能正常对外提供访问。

仅仅只是主库的守护进程和监视器之间的网络通信受到影响，主、备机数据库的状态未受到影响，主备机之间数据依然是同步的。


网络故障处理之后，等待主库守护进程自动重建与监视器的网络连接，主库守护进程状态从NONE，切换至OPEN。

2.3.故障三：主库与备库网络中断

模拟主库与备库之间的网络故障。主备库之间网络故障，但与确认监视器之间的网络正常，主库守护进程切换到 Confirm 状态，向确认监视器进行求证，确认监视器确认主库满足Failover 执行条件，主库守护进程会切换为 Failover 状态，启动故障处理流程。

此时备库的 RSTAT 字段是 Invalid 状态，因为主备库之间的网络故障，导致主、备库之间的数据同步出现问题，备库的lsn不往前的推进，主、备库的lsn慢慢变大。此时主库正常对外提供访问，主备库之间的数据是不一致的。

主备库网络故障处理后，主库守护进程启动Recovery 流程，重新恢复主备库到一致状态。

2.4.故障四：备库与监视器、主库网络中断
模拟备库与监视器、主库网络故障。故障后备库守护进程(GRP1_DM2)消息超时，主库守护进程切换到CONFIRM状态，此时实时归档失败，主库切换为Suspend状态，数据库无法正常写入，集群功能短暂受到影响。

主库守护进程等待确认监视器的确认消息，确认为符合故障处理条件，主库守护进程切换至Failover状态，将故障备库的归档失效。此时主库实例从SUSPEND切换至OPEN，正常对外提供服务。

备库与监视器、主库网络故障恢复后，备库可以直接加入集群，监视器收到备库GRP1_DM2的连接，备库归档状态为INVALID状态，主库进入故障恢复流程，主库守护进程切换到RECOVERY状态，重新恢复主备库到一直状态。

2.5.故障五：主库与监视器、备库网络中断

模拟主库与监视器、备库网络故障。故障后主库守护进程(GRP1_DM1)消息超时，判断为主库实例故障，集群进行自动切换，将备库切换成主库，目前实例GRP1_DM2为主库。

此时原主库GRP1_DM1处于主库挂起状态，即SUSPEND，PRIMARY。

原备库GRP1_DM2切换为主库，正常对外提供服务。集群内主备库的数据是不同步的。

原主机（GRP1_DM1）网络故障恢复后，可以直接加入集群，实例GRP1_DM1守护进程与监视器重新建立连接，集群状态变化如下：
守护进程(GRP1_DM1)状态切换 [NONE-->MON CONFIRM]
守护进程(GRP1_DM1)状态切换 [MON CONFIRM-->STARTUP]
实例GRP1_DM1[PRIMARY, SUSPEND, ISTAT_SAME:TRUE]故障
实例GRP1_DM1[PRIMARY, MOUNT, ISTAT_SAME:TRUE]恢复正常

实例GRP1_DM1守护进程进入 Unify_ep 状态，将数据库模式从PRIMARY，修改为STANDBY，此时备库的 RSTAT 是 Invalid 状态。

实例GRP1_DM1作为备库正常OPEN后，现主库GRP1_DM2进入RECOVERY流程，恢复主备库到一致状态。