主备集群组分裂

介绍：

同一守护进程组中，不同数据库实例的数据出现不一致，并且无法通过重演 Redo 日志 重新同步数据的情况，我们称为组分裂。引发组分裂的主要原因包括：

• 即时归档中，主库在将 Redo 日志写入本地联机 Redo 日志文件之后，发送 Redo
  日志到备库之前出现故障，导致主备库数据不一致，为了继续提供服务，执行备库强制接管。
  此时，当故障主库重启后，就会引发组分裂。
• 故障备库重新完成数据同步之前，主库硬件故障，并且长时间无法恢复；在用户接
  受丢失部分数据情况下，为了尽快恢复数据库服务，执行备库强制接管，将备库切换为主库。
  此时，如果故障主库重启，也会造成组分裂。
  检测到组分裂后，守护进程会修改控制文件为分裂状态，强制退出被分裂的库，被分裂
  出去的数据库需要通过备份还原等技术手段重新恢复。

1.查看监视器

查看集群监视器发现监视器报集群组分裂。

如果分裂库的守护进程控制文件状态不是Valid，可借助监视器的show open info 命令，根据 DESC 字段找出原因。

2.修复方式一（完全备份还原）

2.1 停止备库服务

停止分裂库的守护进程及数据库服务。

2.2 主库备份

登录主库，执行联机备份。
联机备份：SQL> BACKUP DATABASE BACKUPSET ‘/data/dmdata/BACKUP_FILE_01’;

2.3 备库数据还原

将主库备份集拷贝到备库服务器并执行脱机还原与恢复。
./dmrman CTLSTMT=“RESTORE DATABASE ‘/data/dmdata/DAMENG/dm.ini’ FROM BACKUPSET
‘/data/dmdata/BACKUP_FILE_01’”
./dmrman CTLSTMT=“RECOVER DATABASE ‘/data/dmdata/DAMENG/dm.ini’ FROM BACKUPSET
‘/data/dmdata/BACKUP_FILE_01’”
./dmrman CTLSTMT=“RECOVER DATABASE ‘/data/dmdata/DAMENG/dm.ini’ UPDATE DB_MAGIC”

2.4删除dmwatcher.ctl

控制文件
数据守护 V4.0 对守护进程控制文件（dmwatcher.ctl）进行了简化，仅用于记录本地
数据库的分裂状态和分裂描述信息。守护进程在检测到本地库分裂时，自动创dmwatcher.ctl 文件，保存在本地库的 SYSTEM_PATH路径下，并且文件中记录的状态一定是 Split 分裂状态。如果dmwatcher 加载到 dmwatcher.ctl 文件，则认为对应的库一定是分裂状态。如果需要对分裂库进行重建，则需要手动将 dmwatcher.ctl 文件删除，否则守护进程仍然会认定本地库为分裂库。
守护进程控制文件仅包含版本号、状态及分裂描述信息这三项内容。
状态字段包含以下两种：

• 有效（VALID）
  正常运行时状态。
• 分裂（SPLIT）
  数据和有效主库的数据不一致时设置。
  [dmdba@localhost DAMENG]$ rm -rf dmwatcher.ctl
  

2.5启动备库

已mount方式启动备库。
[dmdba@localhost bin]$ ./DmServiceGRP1 start

2.6修改备库模式

重置OGUID和数据库模式。
sp_set_oguid()设置的 OGUID 值必须与主库一致。若重建的备库仍和主库在同一个集群中，则还原后备库的 OGUID 值与主库是一致的。
SQL>SP_SET_PARA_VALUE(1, ‘ALTER_MODE_STATUS’, 1);
SQL> SP_SET_OGUID(45331);
SQL> ALTER DATABASE STANDBY;
SQL>SP_SET_PARA_VALUE(1, ‘ALTER_MODE_STATUS’, 0);

2.7启动守护进程

[dmdba@localhost bin]$ ./DmWatcherServiceWatcher start

2.8 查看监视器

登录监视器查看集群状态已恢复正常，实例状态均为OPEN。
[dmdba@localhost bin]$ ./dmmonitor /data/dmdata/DAMENG/dmmonitor_auto.ini

3.修复方式 二（归档备份还原）

如果数据规模比较大、联机备份耗时较长、应用压力比较大的情况下，主库联机备份、
备库脱机还原过程中，主库可能又新产生了大量归档日志。使用上述步骤重建备库后，主库
向备库同步历史数据的时间会比较久，主备库数据会在比较长的一段时间内处于不一致状
态。对这种情况，用户可以通过归档备份、还原和归档恢复功能，将备库数据恢复到更加接
近主库的最新状态，有效减少备库加入主备系统后的历史数据同步时间。执行步骤如下：

3.1 停止备库服务

停止数据库实例和守护进程。

3.2 主库备份

登录主库，执行联机备份。
解释：
数据备份主要针对数据文件内容，包括库备份、表空间备份和表备份。其中，未指定
WITHOUT LOG 参数执行的库备份和表空间备份还包含了 REDO 日志备份。
库备份，顾名思义就是对整个数据库执行的备份，又称为库级备份。库备份会拷贝数据
库中所有数据文件的有效数据页。DM8 备份与还原
表空间备份是针对特定表空间执行的备份，又称为表空间级备份。表空间备份只能在联
机状态下执行。
表备份则拷贝指定表的所有数据页到备份集中，并会记录各个数据页之间的逻辑关系用
以恢复。表备份只能在联机状态下执行，一次表备份操作只能备份一张用户表，并且不支持
增量表备份。

SQL> BACKUP DATABASE FULL BACKUPSET ‘/data/dmdata/BACKUP_FILE_03’ WITHOUT LOG;

3.3 备库还原

将主库备份文件拷贝到备库，执行脱机还原
[dmdba@localhost bin]$ ./dmrman CTLSTMT=“RESTORE DATABASE ‘/data/dmdata/DAMENG/dm.ini’ FROM BACKUPSET ‘/data/dmdata/BACKUP_FILE_03’”

3.4 备份主库归档日志

启动 DIsql 登录主库，查看备份集的 BEGIN_LSN，并从 BEGIN_LSN 开始备份主
库的归档日志。（这里假设查询到的备份集 BEGIN_LSN 是 2176891）。
如果备份集不是在默认备份路径下，则需要先将备份集所在目录添加进来，否则会查询
不到备份集信息：
SQL> SELECT SF_BAKSET_BACKUP_DIR_ADD(‘DISK’,’/data/dmdata/’);

备份归档日志
SQL> SELECT BACKUP_NAME,BEGIN_LSN FROM V$BACKUPSET;
SQL> BACKUP ARCHIVE LOG FROM LSN 2176891 BACKUPSET ‘/data/dmdata/ARCH_BAK_03’;

3.5删除dmwatcher.ctl

控制文件
数据守护 V4.0 对守护进程控制文件（dmwatcher.ctl）进行了简化，仅用于记录本地
数据库的分裂状态和分裂描述信息。守护进程在检测到本地库分裂时，自动创dmwatcher.ctl 文件，保存在本地库的 SYSTEM_PATH路径下，并且文件中记录的状态一定是 Split 分裂状态。如果dmwatcher 加载到 dmwatcher.ctl 文件，则认为对应的库一定是分裂状态。如果需要对分裂库进行重建，则需要手动将 dmwatcher.ctl 文件删除，否则守护进程仍然会认定本地库为分裂库。
守护进程控制文件仅包含版本号、状态及分裂描述信息这三项内容。
状态字段包含以下两种：

• 有效（VALID）
  正常运行时状态。
• 分裂（SPLIT）
  数据和有效主库的数据不一致时设置。
  [dmdba@localhost DAMENG]$ rm -rf dmwatcher.ctl
  

3.6 备库归档还原

利用这些归档日志进行数据库 恢复。
[dmdba@localhost bin]$ ./dmrman CTLSTMT=“RESTORE ARCHIVE LOG FROM BACKUPSET ‘/data/dmdata/ARCH_BAK_03’ TO ARCHIVEDIR ‘/data/dmdata/DAMENG/arch1’”
[dmdba@localhost bin]$ ./dmrman CTLSTMT=“RECOVER DATABASE ‘/data/dmdata/DAMENG/dm.ini’ WITH ARCHIVEDIR ‘/data/dmdata/DAMENG/arch1’”
[dmdba@localhost bin]$ ./dmrman CTLSTMT=“RECOVER DATABASE ‘/data/dmdata/DAMENG/dm.ini’ UPDATE DB_MAGIC”

3.7启动备库

已mount方式启动备库。
[dmdba@localhost bin]$ ./DmServiceGRP1 start

3.8 修改数据库模式

重置OGUID和数据库模式。
sp_set_oguid()设置的 OGUID 值必须与主库一致。若重建的备库仍和主库在同一个集群中，则还原后备库的 OGUID 值与主库是一致的。
SQL>SP_SET_PARA_VALUE(1, ‘ALTER_MODE_STATUS’, 1);
SQL> SP_SET_OGUID(45331);
SQL> ALTER DATABASE STANDBY;
SQL>SP_SET_PARA_VALUE(1, ‘ALTER_MODE_STATUS’, 0);

3.9启动守护进程

[dmdba@localhost bin]$ ./DmWatcherServiceWatcher start

3.10查看监视器

登录监视器查看集群状态已恢复正常，实例状态均为OPEN。
[dmdba@localhost bin]$ ./dmmonitor /data/dmdata/DAMENG/dmmonitor_auto.ini

4.总结

4.1 组分裂和脑裂比对

在数据库高可用性（HA）和集群环境中，组分裂（Split）和脑裂（Split-Brain） 是两种不同的异常状态，但都与网络或同步问题相关。它们的核心区别如下：

4.1.1 组分裂（Split）

• 定义：
  指主备数据库或集群节点之间的通信中断，导致它们无法同步数据，但系统能自动或手动检测到问题并采取保护措施（如将备库设为独立状态）。
  重点是“组内成员失去联系”，但通常不会导致数据冲突。
• 常见原因：
  网络分区（Network Partition）。
  主备库之间的复制链路中断。
  防火墙/路由问题阻止节点通信。
• 系统行为：
  检测到通信中断后，备库会被标记为 SPLIT 或 DISCONNECTED 状态，停止从主库同步数据，防止数据不一致。
  主库可能继续服务，但备库会进入只读或不可用状态（取决于配置）。
• 影响：
  数据暂时不同步，但不会直接导致数据损坏。
  需要人工介入修复网络或重新同步数据。

4.1.2 脑裂（Split-Brain）

• 定义：
  指 集群或主备环境中的多个节点同时认为自己是“主节点”，并独立接受写入，导致数据严重冲突。
  重点是“多个主节点同时活跃”，可能引发数据损坏。
• 常见原因：
  心跳检测失败（如网络延迟过高）
  故障切换（Failover）逻辑缺陷
  人为错误（如强制提升备库为主库而未正确降级原主库）
• 系统行为：
  两个或多个节点同时以 PRIMARY 状态运行，独立处理写入请求。
  数据可能在不同节点上被同时修改，导致数据不一致甚至逻辑冲突（例如同一行记录被两个主库更新为不同值）。
• 影响：
  数据一致性被破坏，恢复困难（需人工合并冲突数据或丢弃部分写入）。
  业务可能面临逻辑错误（如订单重复、账户余额异常等）。

4.2关键区别对比

4.3如何避免这两种问题？

• 组分裂的预防：
  配置合理的超时和心跳检测机制。
  使用多路径网络冗余减少通信中断风险。

• 脑裂的预防：
  仲裁机制（Quorum）：确保集群中只有多数节点存活时才能选举主节点。
  Fencing（隔离）：强制关闭不确定状态的节点（如电源隔离）。
  人工干预确认：关键切换需手动确认（如 FORCE FAILOVER 命令）。