达梦数据库主备集群管理：防脑裂、性能优化与故障处理

一、DM 集群如何防止脑裂

1.1 脑裂是怎么发生的

正常情况下，数据守护集群不会发生脑裂。最容易触发脑裂的场景是人工干预——在没有确认主库状态的情况下，强行把备库切换为主库。

一个典型的过程如下：

1. 关闭主、备库的监控；
2. 在主库仍正常的情况下，强制将备库切换为主库；
3. 此时重启主库和备库的监控，监视器上就会同时出现两个主库。

需要说明的是，此时重启两个"主库"中的任意一个，该库会自动降级为备库，集群仍可恢复。只有在异常状态下对两个数据库都进行了写操作（例如通过 disql 直连数据库进行操作），才会造成不可修复的损坏。因此，脑裂后的"双写"才是真正的危险所在。

1.2 如何预防脑裂

预防脑裂，建议从以下几个方面入手：

1. 提供稳定可靠的网络：网卡、交换机等关键设备做好冗余，避免因心跳网络抖动误判主库故障。
2. 优先采用非自动切换模式：

   DW_MODE = AUTO    # 自动切换
   DW_MODE = MANUAL  # 手动切换（更安全，推荐）
   

3. 自动切换模式下，必须在第三台机器部署确认监视器，由监视器仲裁主备状态，避免"双主"。
4. 人工干预前务必确认原主机是否存活：在将备库切换为主库之前，一定要确认主库确实已经发生故障，避免主库仍在活动时备库强制接管，人为造成脑裂。
   • 可以在 dm.ini 中设置 ALTER_MODE_STATUS = 0，禁止人工修改数据库模式、状态以及 OGUID，从制度层面杜绝误操作。

1.3 确认监视器的作用

关闭主库的监控后，监视器会显示主库异常。

此时即使通过监视器强制切换主库，监视器仍会先监测主库的真实状态：如果主库功能其实正常，只是心跳网络异常，则无法执行强制切换。这正是确认监视器作为"仲裁者"的价值所在——它能有效避免因心跳误判而引发的脑裂。

1.4 脑裂发生后如何修复

一旦发生脑裂，可按照以下步骤修复：

1. 确认现状并清理分裂标识：通过监视器的 show 命令确认哪个是正常主库、哪个是 SPLIT 分裂库。在分裂库所在机器上，必须手动删除数据目录下的 dmwatcher.ctl 文件——只要该文件存在，守护进程就会一直认为该库处于分裂状态，无法重新加入集群。
2. 备份正常主库：在正常对外服务的主库上执行一次联机全备。
3. 停止并重置分裂库：停止分裂库的守护进程和数据库服务，将主库备份文件拷贝过去，进行脱机还原与恢复。
4. 修改模式并重新加入：以 Mount 方式启动恢复后的库，将其 OGUID 修改为与主库一致，并把模式改为 Standby。完成后启动该节点的守护进程，数据守护系统会自动将其作为备库重新纳入集群并开始同步数据。

二、数据守护集群性能优化

2.1 高性能与事务一致性

关键控制参数为 TARCH_WAIT_APPLY，它决定备库收到 Redo 日志后，是否要等日志重演完成再响应主库：

高性能模式优先保证吞吐量，事务一致模式优先保证主备数据强一致，需要根据业务对一致性的要求进行取舍。

2.2 dm.ini 参数优化

三、常见故障处理

3.1 主节点挂起

问题描述：手动切换模式下，若守护进程被配置为 DW_MODE = AUTO，而环境里又没有配置确认监视器，此时停掉备机节点实例服务并继续往主节点写入数据，就会导致主节点挂起。

解决办法：

• 将守护进程配置改为 MANUAL（手动切换）；
• 配置并启动确认监视器。

3.2 单一节点故障

在自动切换模式下，如果备库发生故障，集群会退化为单节点运行。此时若主库重启，确认监视器会先确认备库状态，导致主库一直停留在 mount 状态无法正常打开。

解决方式：在确认监视器中直接启动数据库：

open database GRP1.DW02

数据库启动后即可进行数据操作。若归档连续，则备库启动后数据一致；若归档不一致，则需要对主、备库进行备份还原操作。