故障模拟目的
通过模拟各种故障场景，不仅可以检测系统在设计、配置和运行过程中的薄弱环节，提前采取改进措施，提高系统整体可靠性；还能验证应急预案的可行性与有效性，及时发现预案中操作步骤不清晰、资源分配不合理、恢复时间过长等问题，并进行修订完善。同时，有助于在故障发生时快速采取有效应对措施，缩小故障对业务的影响范围与持续时间，降低业务损失，提升客户满意度。此外，可验证数据备份机制的有效性和完整性，确保数据丢失或损坏时能快速准确恢复，保障数据安全与完整。在此过程中，运维团队及相关人员能在模拟环境中熟悉故障发生时的应急响应流程，涵盖故障发现、报告、排查、处置和恢复等环节，从而提高团队在真实故障发生时的应对效率与准确性。
模拟环境
节点名称 公网IP 私网IP 监视器IP
GRP1_RT_01 192.168.177.100 192.168.177.100
GRP1_RT_02 192.168.177.13 192.168.177.13
monitor 192.168.177.16
场景模拟
1.场景一：有确认监视器但两个节点配置故障切换模式为手动切换模式（DW_MODE=MANUAL）情况下，GRP1_RT_01私网故障。
1.1 关闭GRP1_RT_01节点私网网口
ifdown eth0
确认监视器发现GRP1_RT_01守护异常，判定GRP1_RT_01故障。

因为两节点都为手动切换模式，人工介入启动备库接管流程GRP1_RT_02切主运行。

GRP1_RT_02接管业务后，GRP1_RT_01节点实例模式为Primary

1.2 启动GRP1_RT_01节点私网网口
ifup eth0
GRP1_RT_02接管成功，网络恢复后，原主库GRP1_RT_01自动加入集群。

因GRP1_RT_01、GRP1_RT_02两节点数据库的SN值和N_NEW出现不一致，导致出现双主情况。

重启GRP1_RT_01中的dmwatcher，进入故障恢复状态（Recovery）加入集群恢复主备集群运行。

2.场景二：无确认监视器情况下，GRP1_RT_01私网故障。
2.1 关闭GRP1_RT_01节点私网网口
ifdown eth0
登录监视器，只有GRP1_RT_02在线，采用强制接管模式，将GRP1_RT_02接管为主库，接管成功。

2.2 当GRP1_RT_02强制接管成功后，立即启动GRP1_RT_01节点私网网口
监视器显示GRP1_RT_01瞬间加入集群，出现双主情况

重启GRP1_RT_01的dmwatcher服务，GRP1_RT_01的守护进程自动进入 Recovery 状态，恢复主备集群运行。

3.场景三:有确认监视器情且两个节点配置故障切换模式为手动切换模式（DW_MODE=AUTO）况下，GRP1_RT_01私网故障。
3.1关闭GRP1_RT_01节点私网网口
ifdown eth0
GRP1_RT_01网络中断，确认监视器启动自动故障切换流程，GRP1_RT_02为主库运行，但GRP1_RT_01节点状态异常。

3.2 启动GRP1_RT_01节点私网网口
ifup eth0
恢复GRP1_RT_01私网网络，GRP1_RT_01自动加入集群进入 Recovery 状态，恢复主备集群运行。

模拟总结
1.1在确认监视器开启且守护进程处于手动切换模式时，数据库将无法对外提供服务。此时，需人工介入，将备库节点切换为主库运行，集群才能恢复对外服务功能。当原主库节点的私网连接恢复后，监视器会自动将该节点的数据库重新纳入集群。然而，该节点的数据库实例模式会出现异常，显示为“primary”。为使集群恢复正常的运行状态，必须人工重启dmwatcher。
1.2在未开启确认监视器的场景下，数据库将无法对外提供服务。此时，需人工介入，将备库节点切换为主库运行，集群才能恢复对外服务功能。当原主库节点的私网连接恢复后，监视器会自动将该节点的数据库重新纳入集群。然而，该节点的数据库实例模式会出现异常，显示为“primary”。为使集群恢复正常的运行状态，必须人工重启dmwatcher。
1.3当确认监视器处于开启状态时，若主备集群的主库节点私网出现异常，确认监视器将自动接管集群操作，把备库节点切换为主库，确保集群能够正常对外提供服务。待原主库节点的私网连接恢复后，监视器会将该节点的数据库实例模式切换至 standby 模式，以维持集群的正常运行。