修复MPP主备

场景：两节点 MPP主备、两组数据守护、四个数据库实例交叉部署。其中一个 MPP 主节点实例（GRP2_MPP_EP02）被删除，同时所有数据库实例、守护进程和确认监视器均已停止。

1.启动GRP2_MPP_EP22

./DmServiceMPP_EP22 start

2.启动GRP1 的主备库 `EP01`、`EP11`

./DmServiceMPP_EP01 start

./DmServiceMPP_EP11 start

3.临时调整服务器 B 的守护配置

由于服务器 B 上的同一个守护进程同时管理 EP11 和已经丢失的 EP02,所以需要临时调整守护配置。

临时处理原则：

保留 GRP1. EP11 的配置；
暂时注释或移除服务器 B 本地指向 EP02_INI 的 GRP2 守护段。

4.启动服务器 A、B 两台服务器的守护进程

./DmWatcherService01 start

./DmWatcherService02 start

5.启动确认监视器

./DmMonitorService01 start

进入监视器后先执行检查：

show

6.让备库EP22接管，切换为主库

takeover force

在确认监视器中登录：

login

然后执行：

choose takeover force

按提示选择：

GRP2_MPP_EP22

7.被删的原主库02按照备库重建

7.1 重新初始化 `EP02`

7.2 执行脱机还原和备库恢复

BACKUP DATABASE '/data/SLQ/MPP_DATA/MPP_EP22/DAMENG/dm.ini' FULL TO BACKUP_FILE0804 BACKUPSET '/data/SLQ/MPP_DATA/dmbak/BACKUP_FILE_02';

RESTORE DATABASE '/data/SLQ/MPP_DATA/MPP_EP02/DAMENG/dm.ini' FROM BACKUPSET '/data/SLQ/MPP_DATA/dmbakBACKUP_FILE_02';

RECOVER DATABASE '/data/SLQ/MPP_DATA/MPP_EP02/DAMENG/dm.ini' FROM BACKUPSET '/data/SLQ/MPP_DATA/dmbak/BACKUP_FILE_02';

RECOVER DATABASE '/data/SLQ/MPP_DATA/MPP_EP02/DAMENG/dm.ini' UPDATE DB_MAGIC;

7.3 配置EP02

配置dm.ini 、dmmal.ini、dmarch.ini、dmmpp.ctl。

其中EP02 使用的 dmmal.ini 必须与其他实例严格一致；dmmpp.ctl从当前有效的活动 MPP 主节点复制。

8.启动02数据库

以 Mount 方式启动实例。

./dmserver /data/SLQ/MPP_DATA/MPP_EP02/DAMENG/dm.ini mount

9.设置OGUID

启动命令行工具 DIsql，登录实例设置 OGUID 值。

SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
SQL>SP_SET_OGUID(45331);
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

10.修改数据库模式

启动命令行工具 DIsql，登录实例修改数据库为 Standby 模式:

SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); 
SQL>ALTER DATABASE Standby; 
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

11.重启服务器 B 守护进程

还原前面临时处理中对GRP2 守护段的注释。

12.切回原始主备角色

在监视器中：

show #查看flsn主备库数据同步情况

若一致进行主备切换:

login
choose switchover

按提示选择：

GRP2 / GRP2_MPP_EP02

确认后：

switchover

切换完成后：

EP02 应成为 GRP2 PRIMARY；
EP22 应成为 GRP2 STANDBY；

13.总结

本次恢复的核心思路是：先利用仍然完整的 GRP2_MPP_EP22 恢复 GRP2 的主库服务，再将已经删除的 GRP2_MPP_EP02 按备库方式重新构建，待主备同步正常后，根据实际需要切回原始主备角色。

整个恢复过程可以概括为以下四个阶段：

恢复现存实例和守护
先启动 GRP2_MPP_EP22、GRP1_MPP_EP01 和 GRP1_MPP_EP11，并临时调整服务器 B 的守护配置，避免守护进程反复尝试启动尚未重建的 EP02。
由 EP22 接管 GRP2 主库角色
启动守护进程和确认监视器后，确认当前集群状态，再让 EP22 接管为 GRP2 主库，使 MPP 的两个活动节点恢复可用。
将 EP02 按备库方式重建
以当前有效的 GRP2 主库为数据基准，重新准备 EP02 的数据库文件及 dm.ini、dmmal.ini、dmarch.ini、dmmpp.ctl 等配置，设置正确的 OGUID，并将数据库模式修改为 STANDBY。
恢复主备保护并按需切回
将 EP02 重新加入守护系统，确认主备数据同步正常后，可以继续保持 EP22 为主库，也可以通过 switchover 将 EP02 切回主库。

恢复工作完成后，应达到以下状态：

GRP1 和 GRP2 均只有一个主库和一个备库；
两组守护状态正常，不存在 Split 或 Error；
MPP 的两个活动节点均可正常访问；
dmmpp.ctl 在相关节点之间保持一致；
主备归档传输和日志重演正常；
应用连接、跨节点查询及关键业务操作均通过验证。

本次故障恢复最重要的原则是：

先确定唯一可信主库，再重建故障实例；先完成数据同步和状态验证，再进行主备切换。

14.注意事项

14.1 不要手工编辑 `dmmpp.ctl`

dmmpp.ctl 是 MPP 控制文件，不能使用文本编辑器直接修改。应从当前有效的 MPP 活动主节点复制。

接管或切换完成后，应检查各活动 MPP 节点上的 dmmpp.ctl 是否一致。控制文件不一致可能导致：

MPP 节点识别异常；
跨节点查询失败；
用户登录受到限制；
分布式任务执行异常。

14.2 重建 `EP02` 不能只复制配置文件

配置 dm.ini、dmmal.ini、dmarch.ini 和 dmmpp.ctl 只是重建过程的一部分。数据库数据文件必须以当前有效主库为基准完成物理备份、还原和备库恢复。

不应执行以下操作：

将旧的、不确定是否完整的数据文件直接启动；
只复制 EP22 的数据库目录后修改实例名；
在未更新数据库标识和模式的情况下加入守护组。