4、集群数据守护场景
（1）正常运行状态
守护系统正常运行时，同一个守护进程组中，只有一个主库，其他的都是备库。主库处于 Open 状态，主库守护进程也处于 Open 状态，本地没有守护进程控制文件，其内存值是 Valid 有效状态。所有备库也处于 Open 状态，所有备库守护进程处于 Open 状态，本地没有守护进程控制文件，其内存值是 Valid 有效状态。主库到所有备库的归档也都处于 Valid 有效状态。
（2）数据守护的启动
Normal 模式的库默认以 Open 状态启动，也可以通过增加启动参数 Mount 将数据库启动到 Mount 状态。而 Primary/Standby 模式的库启动后，自动进入 Mount 状态，因此，数据守护系统启动时，所有数据库实例处于 Mount 状态。所有守护进程处于 Startup状态。如果实例还未启动到 Mount 状态（比如还处于 After redo 状态），守护进程不会通知实例 Open。
Local 守护类型的守护进程，直接 Open 数据库实例，并修改守护进程状态为 Open。
Global 守护类型的守护进程，需要相互协调信息，自动将数据库实例切换到 Open 状态，并将守护进程状态也切换为 Open 状态。
Global 守护类型的守护进程通知本地库 Open 的总体原则：
- 对于备库，如果可加入远程任意一个库，则允许将其 Open；
- 对于主库，如果远程所有库都可加入自己，则允许将其 Open。
还有一些细节条件这里不再具体列出，如果通过监视器没有观察到主库或备库 Open，可以借助监视器的 Check Open 命令查找原因，根据命令返回的原因考虑是否进行人工干预，比如需要通过监视器命令强制 Open 主库或备库。
注意：
- 手动方式启动数据守护系统时，对于守护进程，数据库实例和监视器的启动顺序没有严格要求，也可以通过监视器命令启动守护系统（前提是所有守护进程已经启动）。
- 启动流程中，守护进程在通知主库 Open 之前，会先收集出和主库数据一致的备库（备库的 ALSN 信息和主库的 FLSN 信息相等），守护进程会将这些备库的归档设置为 Valid 有效状态，其他数据不一致的备库则设置为Invalid 无效状态。Primary 模式数据库实例切换为 Open 状态时，需要回滚活动事务、Purge 已提交事务，并重构回滚段，会引发数据变化、LSN增长。对归档无效的备库，在数据守护启动完成后，主备库数据肯定是处于不一致状态。
- 主库守护进程 Open 主库后，会修改 INST_RECOVER_TIME 内存值为 3 秒（默认 60 秒），确保归档状态无效的备库 Open 后，尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。
- 如果在故障恢复流程完成之前，主库故障，并且不存在归档状态有效的备库，则无法执行备库接管；备库强制接管会引发守护进程组分裂。
- 读写分离集群，在 Timely 或 Realtime 归档变为 Valid 之前，不会在备库上创建数据库连接，只读操作也无法分流到对应的备库。
（3）强制 Open 数据库
正常情况下，守护进程 dmwatcher 可以自动 Open 数据库实例，但某些情况下（比如备库硬件故障无法启动），数据守护系统不满足启动条件，我们可以通过监视器执行 Open database 命令强制 Open 数据库实例。主备库都可以强制 Open，其执行流程如下：
1 假设需要强制 Open 数据库 A，只需要启动一个监视器，登录后输入 Open database A 即可完成强制启动。 如果数据库 A 是 Standby 模式，强制 Open 的执行流程如下：
①通知 A 的守护进程切换为 Open Force 状态
②通知 A 执行 Open 操作
③通知守护进程切换 Open 状态
2 如果数据库 A 是 Primary 模式，强制 Open 的执行流程如下：
①通知 A 的守护进程切换为 Open Force 状态
②修改 A 到所有归档目标的实时归档/即时归档状态为无效
③通知 A 执行 Open 操作
④通知守护进程切换 Open 状态
3 Primary 模式数据库实例切换为 Open 状态时，需要回滚活动事务、Purge 已提交事 务，并重构回滚段，会引发数据变化、LSN 增长。因此，这个操作可能会引发守护进程组分 裂，比如下面的场景：
①主库 A 故障
②备库 B 接管，成为主库
③B 故障
④A 重启，并强制 Open
⑤A 和 B 数据不一致，并且无法恢复到一致状态。此时，B 重启，就会产生守护进程 组分裂。
注意：
- 强制 Open 主库前，会设置主库到所有归档目标的实时归档/即时归档为 Invalid 状态。
- 强制 Open 主库命令，会修改主库守护进程 INST_RECOVER_TIME 内存值为3 秒（默认 60 秒），确保
- 主库 Open 后，尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。
- 如果在故障恢复流程完成之前，主库故障，将无法执行备库接管；备库强制接管会引发守护进程组分裂。
注意：
强制 Open 主库前，会设置主库到所有归档目标的实时归档/即时归档为 Invalid 状态。
强制 Open 主库命令，会修改主库守护进程 INST_RECOVER_TIME 内存值为3 秒（默认 60 秒），确保
主库 Open 后，尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。
如果在故障恢复流程完成之前，主库故障，将无法执行备库接管；备库强制接管会引发守护进程组分裂。
（4）关闭数据守护系统
关闭守护系统时，必须按照一定的顺序来关闭守护进程和数据库实例。特别是自动切换模式，如果退出守护进程或主备库的顺序不正确，可能会引起主备切换，甚至造成守护进程组分裂。通过监视器执行 Stop Group 命令关闭数据守护系统，是最简单、安全的方式。命令执行成功后，数据库实例正常关闭。但守护进程并没有真正退出，而是将状态切换为Shutdown 状态。
Stop Group 命令内部流程如下：
①通知守护进程切换为 Shutdown 状态
②通知主库退出
③通知其他备库退出
如果使用手动方式关闭数据守护系统，请严格按照以下顺序执行：
①如果启动了确认监视器，先关闭确认监视器（防止自动接管）
②关闭备库守护进程（防止重启实例）
③关闭主库守护进程（防止重启实例）
④Shutdown 主库
⑤Shutdown 备库
如果是只关闭主库，并且不想引发备库自动接管，有以下两种方法：
方法一：
1 通过 Detach database 命令将所有备库分离
2 通过 Stop database 命令退出主库
方法二：严格按照以下顺序执行：
1 通过 Stop dmwatcher 命令关闭所有守护进程监控
2 手动正常退出主库
如果是只关闭备库，并且不想引发主库发送日志失败进入 Suspend 状态，请严格按照以下顺序执行：
1 通过 Detach database 命令将备库分离出数据守护系统
2 正常退出备库（手动退出或者通过 Stop database命令退出）
（5）主备库切换
主库维护，滚动升级等场景，可以执行 Switchover 命令，实现主备库切换。如果存在多个备库，需要先执行 Choose Switchover 命令，选出守护进程组中可以切换的备库。
Choose Switchover 命令选择可切换备库的条件如下：
主库守护进程是 Open 状态
备库守护进程是 Open 状态
主、备库的 OPEN 记录项内容相同，并且守护进程控制文件是 Valid 有效状态（内存值）
主库正常运行
备库正常运行
主库处于 Open 状态
备库处于 Open 状态
主库到备库的归档是 Valid 状态
假定选出的可切换备库是 B，Switchover 切换流程如下：
通知主备库守护进程，切换为 Switchover 状态
通知主库(A) Mount
实时或 MPP 主备环境下，通知备库(B) APPLY KEEP_RLOG_PKG
通知备库(B) Mount
通知(A) 切换为 Standby 模式
MPP 主备环境下，通知(A)修改 MPP_INI 内存值为 0
通知(B) 切换为 Primary 模式
通知(B) 修改所有归档目标的归档状态为无效
MPP 主备需要通知各组活动主库更新 dmmpp.ctl 文件，参考后文说明
通知新的备库(A) Open
通知新的主库(B) Open
通知主备库守护进程切换为 Open 状态
清理所有守护进程上记录的监视器命令执行信息
注意：
主备库切换在实现逻辑上等同于主备库正常状态 下用户主动发起的Takeover 操作。Swithover完成后，主备库之间数据是不完全同步的，要由新主库 B 的守护进程通过 Recovery 流程，重新同步数据到新备库 A。Switchover 命令会修改切换后主库守护进ZINST_RECOVER_TIME 内存值为 3 秒（默认 60 秒），确保尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。
在故障恢复流程完成之前，再次执行Switchover 命令会报错，如果主库故障，备库接管将会报错；备库强制接管会引发守护进程组分裂。
