查看信息

dmmonitor /dmdb/dmmonitor.ini
help
show
exit

启停数据库

通过监视器启停

login
username:SYSDBA
password:XXX
stop group DMDB03
startup group DMDB03

通过监视器启停数据守护系统，是最简单、安全的方式。
停止后，数据库实例正常关闭，但操作系统中的守护进程并没有真正退出，而是将状态切换为 SHUTDOWN 状态。

手动启动

启动主备集群对数据库实例、守护进程、监管进程的启动顺序没有特殊要求，只要进程能正常启动即可。
如下启动顺序可供参考：
1.启动数据库（主备顺序没要求） DmServiceDM start
2.启动守护进程（主备顺序没要求） DmWatcherServiceDM start
3.启动确认监视器（普通监视器按需启动） DmMonitorServiceDM start

Primary/Standby 模式的库启动后，自动进入 Mount 状态。
守护进程启动后，会自动将 MOUNT 状态的实例启动到 OPEN 状态。
守护进程只能将 MOUNT 启动到 OPEN，如果实例还未启动到 Mount 状态，守护进程不会通知实例 Open。
但如果守护进程配置了 INST_AUTO_RESTART，那么守护进程启动后会直接启动实例而不关心实例状态。
读写分离集群，在 Timely 或 Realtime 归档变为 Valid 之前，不会在备库上创建数据库连接，只读操作也无法分流到对应的备库。

手动关闭

严格按照以下顺序执行：

1. 关闭确认监视器：DmMonitorServiceDM stop <--- 防止自动接管
2. 备、主依次关闭守护进程：DmWatcherServiceDM stop <--- 防止重启实例
3. 主、备依次关闭数据库：DmServiceDM stop

关闭守护系统时，必须按照一定的顺序来关闭守护进程和数据库实例。
关闭整个数据守护系统时，先关闭主库再关闭备库，顺序一定不能错。
对于本地守护类型的库，在关闭数据守护系统时，不受此顺序限制。
因为主库 Shutdown 过程中，需要 Purge 所有已提交事务，会修改数据，并产生 Redo 日志。
如果先 Shutdown 备库，会导致主库发送归档日志失败，并且由于主库已经处于 Shutdown 状态，会导致主库异常关闭。
特别是自动切换模式，如果退出守护进程或主备库的顺序不正确，可能会引起主备切换，甚至造成守护进程组分裂。

只关闭主库

自动模式下，如果是只关闭主库，并且不想引发备库自动接管，有以下两种方法：

方法一：
1.通过 Detach database 命令将所有备库分离
2.通过 Stop database 命令退出主库

方法二：严格按照以下顺序执行：
1.通过 Stop dmwatcher 命令关闭所有守护进程监控
2.手动正常退出主库

只关闭备库

如果是只关闭备库，并且不想引发主库发送日志失败进入 Suspend 状态，请严格按照以下顺序执行：
1.通过 Detach database 命令将备库分离出数据守护系统
2.正常退出备库（手动退出或者通过 Stop database 命令退出）

正常切换

login
username:SYSDBA
password:
show
choose switchover [DMDB03]
switchover [DMDB03.DMDBSTD] <--- 将 MDB03.DMDBSTD 作为新主库
Be careful to do so, this operation will cause switching of primary database, continue use DMDB03.DMDBSTD to do SWITCHOVER or not(YES/NO/Y/N)?
YES

Switchover 不会导致数据丢失，或者数据库分裂等情况。
Switchover 在实现逻辑上等同于主备库正常状态下用户主动发起的 Takeover 操作。
如果想了解其底层逻辑，可以参考手册："DM8 - Data Watch And Read Write Shunt V4.0.pdf" > 6 数据守护使用说明 > 6.5 主备库切换

故障切换

主库故障可恢复

主库故障后，
非确认模式，备库不会自动接管，故障主库恢复后会重新加入集群正常工作。
确认模式下，如果能在备库接管前重启完成，主库会重新加入集群正常工作。如果备库已经自动接管，原主库会以备库的身份加入集群。

主库故障不可恢复

数据守护在正常运行的情况下，是不能执行故障切换的(takeover)。
自动模式下，备库会自动接管。手动模式下，需要管理员进行切换。

故障切换：
choose takeover [force] [DMDB03]
takeover [force] [DMDB03.DMDBSTD]

关于 force 强制切换

加了 force 就是强制切换，与正常 takeover 命令相比，强制接管时系统不会对故障主库与待接管备库的数据一致性进行检查，而是将这一点交给用户预判。
强制接管具有一定的风险，可能因为备库和故障主库数据不一致，而造成部分数据的丢失，出现数据库分裂的情况，所以应该慎重使用。
若接管前主备库的数据是一致的，则强制接管与正常 takeover 效果相同，接管成功后不会出现数据丢失的情况，故障主库重启后也能正常加回集群。
若接管前主备库的数据不一致，则强制接管后会存在数据丢失，故障主库重启后无法加回集群，出现集群分裂。
在主备库之间的数据不一致的情况下，如果用户认为丢失小部分数据的影响可以忽略，或者该影响小于主库持续宕机造成的影响，则可以考虑进行 takeover force 强制接管。

下面列举了几种典型的主备库数据不一致的场景，在这些场景下执行强制接管后，可能会出现数据丢失。
场景一，主库故障前到备库的归档状态为 INVALID，此时主库和备库之间已经存在日志差。该备库强制接管后会出现数据丢失。
场景二，主库故障前到备库的归档状态为 VALID，但该备库处于 Timely 即时归档模式下。若主库在将日志写入本地联机日志文件之后立即发生故障，尚未将该日志发送给备库。则备库强制接管后会丢失这条日志的内容。

典型的主备库数据一致的场景：REALTIME 归档模式，主库故障前到备库的归档状态为 VALID。由于 REALTIME 归档流程为主库先发送日志到备库，等待收到所有备库的响应消息后再将该日志写入本地的联机日志文件中，所以在主库故障后其联机日志文件中已经写入的日志一定不会备库收到的日志更多。这种场景下执行强制接管后不会出现数据丢失，故障主库重启后也能够作为备库重新加入集群，不会发生集群分裂。

对于强制接管并且引发分裂的场景，故障主库重启恢复后，只有当新接管的主库处于 Primary & Open，并且实例是活动情况下，才会主动设置原来的主库为 Split 分裂状态。如果新接管主库也被重启到 Mount 状态，由于两个主库互相不可加入，守护进程无法在两个 Mount 主库之间选出有效主库，需要用户干预。

强制 open 数据库

正常情况下，守护进程 dmwatcher 可以自动 Open 数据库实例。
但某些情况下（比如备库硬件故障无法启动），数据守护系统不满足启动条件。
我们可以通过监视器执行 Open database 命令强制 Open 数据库实例。
假设需要强制 Open 数据库 A，只需要启动一个监视器，登录后输入 Open database A 即可完成强制启动。
主备库都可以强制 Open，其底层执行流程如下：
如果数据库 A 是 Standby 模式，强制 Open 的执行流程如下：

1. 通知 A 的守护进程切换为 Open Force 状态
2. 通知 A 执行 Open 操作
3. 通知守护进程切换 Open 状态
   如果数据库 A 是 Primary 模式，强制 Open 的执行流程如下：
4. 通知 A 的守护进程切换为 Open Force 状态
5. 修改 A 到所有归档目标的实时归档/即时归档状态为无效
6. 通知 A 执行 Open 操作
7. 通知守护进程切换 Open 状态
   Primary 模式数据库实例切换为 Open 状态时，需要回滚活动事务、Purge 已提交事务，并重构回滚段，会引发数据变化、LSN 增长。因此，这个操作可能会引发守护进程组分裂，比如下面的场景：
8. 主库 A 故障
9. 备库 B 接管，成为主库
10. B 故障
11. A 重启，并强制 Open
12. A 和 B 数据不一致，并且无法恢复到一致状态。此时，B 重启，就会产生守护进程组分裂。

强制 Open 主库前，会设置主库到所有归档目标的实时归档/即时归档为 Invalid 状态。
强制 Open 主库命令，会修改主库守护进程 INST_RECOVER_TIME 内存值为3 秒（默认 60 秒），确保主库 Open 后，尽快启动故障恢复流程，同步主库数据完成后，重新将归档设置为 Valid 状态。
如果在故障恢复流程完成之前，主库故障，将无法执行备库接管；备库强制接管会引发守护进程组分裂。