（6）主库故障、备库接管
当出现硬件故障（掉电、存储损坏等）原因导致主库无法启动，或者是主库内部网卡故障导致主库短期不能恢复正常的情况下，可使用备库接管功能，将备库切换为主库继续对外服务。
故障自动切换模式下，确认监视器会自动选择符合条件的备库进行接管。
故障手动切换模式下，可以先在监视器上执行 Choose Takeover 命令，选出守护进程组中可以接管的备库。
为了避免备库接管后，造成守护进程组分裂，执行 Takeover 必须满足下列条件：
- 主库是 Primary 模式、Open 状态时，发生故障
- 主库守护进程故障，故障前是 Startup/Open/Recovery 状态；或者主库守护进程正常
- 主库故障前到接管备库的归档状态为 Valid
- 接管备库是 Standby 模式、Open 状态
- 接管备库的守护进程控制文件状态为 Valid（内存值）
- 故障主库和接管备库的 Open 记录项内容相同
假设主库 A 故障时，在故障自动切换模式下确认监视器自动选出待接管备库 B 并通知备库 B 自动接管，或者在故障手动切换模式下，通过监视器上的 Choose Takeover 命令，选出待接管备库 B，在监视器上输入 Takeover 命令通知备库 B 执行接管，这两种方式的接管执行流程是一样的。
以备库 B 为例，接管的执行流程包括：
- 监视器通知守护进程(B)切换为 Takeover 状态
- 实时主备或 MPP 主备环境下，通知备库(B) APPLY KEEP_PKG
- 通知备库(B) Mount
- 通知(B) 切换为 Primary 模式
- 通知(B) 修改到所有归档目标的归档状态为 Invalid
- MPP 主备需要通知活动主库更新 dmmpp.ctl 文件(步骤参考 6.5 主备库切换）
- 通知新的主库(B) Open
- 通知守护进程(B)切换为 Open 状态
（7）备库强制接管
有些情况下，备库接管会失败，但主库不能启动或者及时恢复对外服务的情况下，可以使用 Takeover Force 命令，进行备库强制接管。强制接管具有一定的风险，可能导致备库和故障主库数据不一致，而造成部分数据的丢失，出现数据库分裂的情况，所以应该慎重使用。
例如主库和守护进程故障时，监视器未启动，用户启动监视器后，由于监视器并未收到故障主库任何信息，因此不满足 Takeover 条件，执行 Takeover 会报错。如果用户可确认主库故障时主备数据是一致的（如故障时主库未执行操作，主备库归档有效的，并且两者的 LSN 一致）、或者丢失小部分数据的影响可忽略、或者丢失小部分数据的影响小于主库持续宕机造成的影响，则可以考虑执行 takeover force 强制接管。
强制接管，先通过 Choose Takeover Force 选出符合强制接管条件的备库，再执行 Takeover Force 命令。
备库强制接管时，如果接管备库是处于 Mount 状态/Standby模式的库，则会自动 Open 备库，其他执行流程与备库接管一致。强制接管的条件包括：
- 不存在活动主库
- 备库守护进程处于 Open 或 Startup 状态
- 备库实例运行正常
- 备库是 Standby 模式
- 备库处于 Open 或 Mount 状态
- 备库的 KLSN 必须是所有备库中最大的
- 备库守护进程控制文件必须有效
（8）主库故障重启（备库接管前重启）
主库故障后立即重启，此时主库的守护进程变成 Startup 状态，重新进入守护进程的启动流程，将数据一致的备库归档设置为有效状态，其余备库归档设置成无效状态，并重新Open 主库。Open 成功后继续作为主库，当检测到归档状态无效的备库正常时会启动Recovery 处理流程，重新同步主备库数据。
（9）备库故障处理
备库产生故障（硬件故障或者内部网卡故障）时，主库的处理流程对手动切换、自动切换模式处理上有些差异。
①手动切换模式
对于手动切换模式，检测到备库故障，满足 Failover 条件时，主库的守护进程立即切换到 Failover 状态，执行对应的故障处理，如果不满足切换 Failover 条件，则保持当前状态不变。
手动切换模式下，主库守护进程切换 Failover 条件：
- 备库实例故障，或者主备库之间出现网络故障，或者备库重演时校验 LSN 不匹配，这三种场景下引发主库
- 同步日志到备库失败挂起，主库实例处于 Suspend 状态
- 主库到此备库的归档状态是 Valid（读写分离集群没有此限制）
- 主库的守护进程处于 Startup、Open 或 Recovery 状态
- 当前没有监视器命令正在执行
②自动切换模式
对于自动切换模式，主库的守护进程会自动判断切换到 Failover 状态或者 Confirm确认状态，如果两种状态切换条件都不满足，则保持当前状态不变。
自动切换模式下，主库守护进程不进入 Confirm 确认状态，直接切换到 Failover 条件：
- 前四项条件，和上面列出的手动切换条件相同
- 备库实例故障，备库守护进程正常
如果只满足条件 1，不满足条件 2，则主库守护进程会先进入 Confirm 确认状态，等待确认监视器的确认消息。主库的守护进程进入 Confirm 确认状态后，会有下面几种不同的处理：
1、主库和确认监视器之间网络连接正常
主库的守护进程收到了确认监视器返回的确认消息，如果确认监视器认定可以执行 Failover，则主库的守护进程会切换为 Failover 状态并执行对应的处理；如果确认监视器认定不满足执行 Failover 条件，则主库的守护进程会一直保持在 Confirm 状态。确认监视器认定主库可以执行 Failover 条件：
1）主库守护进程处于 Confirm 状态
2）主库实例正常，处于 Suspend 状态
3）主库没有被接管，不存在其他主库
4）没有 takeover/switchover 命令在执行
5）当前所有归档有效的备库均可以加入主库
2、主库和确认监视器之间网络连接异常，或者没有启动确认监视器。满足下面条件后
主库允许切换至 Failover 状态执行故障处理：
1）主库实例正常，处于 Suspend 状态
2）备库守护进程正常
3）主库没有被接管，不存在其他主库
4）没有 takeover/switchover 命令正在执行
5）备库故障前可以加入主库
3、主库和确认监视器网络恢复正常后，主库已经被接管。老主库的守护进程切换为Startup 状态，重新判断是否可加入新主库。
主库守护进程进入 Failover 状态后的执行流程（自动或手动切换模式下执行流程相同）：
1）对实时主备或 MPP 主备，通知主库修改发送归档失败的备库归档状态无效
2）通知主库重新 Open。
3）将主库的守护进程切换为 Open 状态
（10）确认监视器未启动
故障自动切换模式下，确认监视器必须一直处于启动状态，并且要确保确认监视器的配置正确（否则无法和守护进程通信，相当于确认监视器没有启动）。若确认监视器未启动或者配置错误的，在主库或备库发生故障时，无法通过确认监视器执行正常的故障处理。
在没有确认监视器或确认监视器配置错误的情况下：
- 如果主库故障，则备库无法自动接管为新主库。
- 如果备库实例和备库的守护进程都出现故障，或者主备库之间出现网络故障，则主库的守护进程无法通过确认监视器来确认备库状态，主库守护进程会处于Confirm 确认状态，实例处于 Suspend 挂起状态。
对于第 2 种情况，当备库实例和备库守护进程重新恢复正常，或者主备库之间的网络恢复正常后，即使没有确认监视器，主库的守护进程也会切换至 Failover 状态，将主库重新 Open，后续进行正常的备库恢复处理，而不会一直处于 Confirm 确认状态。可以通过监视器的 show monitor 命令查看连接到指定守护进程的所有监视器信息，以此可以检查守护系统中是否启动有确认监视器以及确认监视器和守护进程的通信是否正常，也可以尝试再启动一个新的确认监视器，如果守护系统中已经启动有确认监视器，则不允许再启动第二个。
