3、集群故障处理
（1）备库故障处理
故障自动切换模式下，备库故障后，如果主备库之间的归档状态仍然有效，主库的守护进程会先切换为 Confirm 状态，等待确认监视器的确认消息，如果确认为符合故障处理条件，主库守护进程再切换至 Failover 状态，将故障备库的归档失效。
故障手动切换模式下，备库故障后，如果主备库之间的归档状态仍然有效，会直接切换到 Failover 状态，并将故障备库的归档失效，不需要备库故障确认。备库故障后，备库的守护进程如果还处于活动状态且监控功能没有被关闭，则会切换到Startup 状态下。
备库故障重启后，如果存在活动主库，主库守护进程根据备库实例的模式、状态、备库守护进程状态、守护进程控制文件状态、备库已经同步到的 Open 记录以及备库的恢复间隔等信息判断是否可以进行故障恢复，在满足故障恢复条件的情况下，主库守护进程启动Recovery 流程，重新恢复主备库到一致状态。如果一直没有观察到主库守护进程发起 Recovery 流程，可以借助监视器的 check recover 命令查找备库不满足条件的原因，并做对应的处理。
（2）备库异常处理
备库异常，指备库的数据库实例正常，但响应速度出现异常，这里的响应速度可能受主备库之间的网络影响，比如网络不稳定、网速大幅下降，也可能受备库自身的软硬件影响，比如操作系统原因或磁盘读写速度异常降低等异常情况导致响应主库的速度变慢，这种情况下会极大拖慢主库性能，影响主库正常处理对外的业务请求。
守护进程提供 RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度，此参数应配置为大于 0 的值，否则守护进程不会打开监控功能。主库守护进程在 Open 状态下对日志发送速度进行检测，一旦检测到异常，主库守护进程会切换到 Standby check 状态，并通知主库将异常备库的归档失效，暂停到此备库的数据同步，避免拖慢主库性能。
完整的备库异常处理流程如下（Standby check 状态处理）：
- 收集所有的异常备库。
- 将主库守护进程上记录的这些异常备库的最近一次恢复时间修改为当前时间。恢复间隔仍然为 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值。这一步骤的目的是为了防止修改备库归档为 Invalid 无效状态后，主库立马启动 recovery，但是还未取到备库最新的 LSN 信息，导致 recovery 无法正确执行的情况发生。
- 通知主库修改这些异常备库的归档为 Invalid 无效状态。
- 守护进程切回 Open 状态。
（3）主库故障处理
故障自动切换模式下，主库故障后，确认监视器会捕获到故障信息，自动选出可接管的备库，并通知备库进行接管。备库接管由确认监视器自动触发，无需用户干预。故障手动切换模式下，主库故障后，需要人工干预，通过监视器执行接管命令，将可接管备库切换为主库。
故障自动切换模式下，可以实时处理故障，但对网络稳定性要求更高，需要确保主备库之间，主备库与守护进程、确认监视器之间的网络稳定可靠，否则可能会误判主库故障，备库自动接管后，出现多个 Open 状态的主库，引发脑裂。故障手动切换模式下，备库不会自动接管，出现节点故障或者网络故障时，由用户根据各种故障情况，进行人工干预。
主库故障重启后，守护进程根据本地和远程库的 Open 记录、LSN 信息以及模式和状态信息来判定重启后的恢复策略，可能继续作为主库加入守护系统，也可能修改为 Standby模式，以备库身份重新加入守护系统，如果出现分裂，则需要用户干预。
（4）故障恢复处理
故障恢复状态（Recovery）由守护进程自行判断是否切换，和监视器无关。如果符合以下条件，主库的守护进程可自动进入 Recovery 状态，进行数据恢复：
- 本地主库 [Primary,Open]，守护进程 Open 状态；
- 远程备库[Standby,Open]，归档状态 Invalid，守护进程 Open 状态；
- 远程备库[Standby,Open]的ASEQ/ALSN和SSEQ/SLSN相等，没有待重做日志；
- 根据 Open 记录等信息判断备库可加入；
- 远程备库[Standby,Open]达到了设置的启动恢复的时间间隔。
对于前 4 点，只是概括说明，详细的条件比较多，这里不再逐一列出，如果某个备库一直没有被恢复，可以借助监视器的 check recover 命令来查找备库无法进行恢复的原因。
对于第 5 点，可通过配置主库守护进程 dmwatcher.ini 的 INST_RECOVER_TIME来控制，取值(3s~ 86400 s)，该值对所有备库有效，可通过监视器的 show arch send info 命令查看当前设置的到指定备库的恢复时间间隔。也可以使用监视器的 set recover time 命令来动态设置指定备库的恢复间隔，该命令只会修改命令中指定的备库的恢复间隔，并且只保存在主库的守护进程内存中，不会写入到 dmwatcher.ini 文件。
在主备库运行正常，不需要执行备库故障恢复的情况下，主库守护进程内存中对备库的恢复间隔值和 dmwatcher.ini 中配置的 INST_RECOVER_TIME 值是一致的，在某些场景下会被设置为不同的值，下面分别进行说明：
①主库守护进程主动设置恢复间隔为 3s
在以下场景中，主库的守护进程会重置内存中的 INST_RECOVER_TIME 为 3s，对满足前述前 4 个条件的备库在 3s 后会立即启动恢复流程：
- 数据守护系统启动完成之后；
- 守护系统运行过程中，主库手动重启或者守护进程自动启动 Open 之后；
- 监视器执行Switchover 主备切换/Takeover 备库接管/强制 Open 主库的操作之后。
②使用监视器命令动态设置恢复间隔
监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值：
- set database [group_name.]db_name recover time time_value动态修改指定备库实例的恢复间隔 ，只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
- set group [group_name] recover time time_value，动态修改指定组或所有组中所有备库的恢复间隔，只修改对应主库守护进程内存中的INST_RECOVER_TIME 值。
- set group [group_name] para_name para_value，动态修改指定组或所有组中所有守护进程的配置参数值，para_name 允许指定为 INST_RECOVER_TIME ， 同时修改dmwatcher.ini 文件和主库内存中的INST_RECOVER_TIME 值。
以上 3 个命令都可以用来修改 INST_RECOVER_TIME 值，修改完成后，一旦主库对指定备库执行过恢复操作，不管恢复执行成功或失败，通过监视器动态修改的内存值都不再有效，主库守护进程在恢复完成后，会根据恢复结果重置内存中的恢复间隔值（对dmwatcher.ini 中的值没有影响）。
③主库守护进程根据恢复结果设置恢复间隔
如果备库恢复成功，会重置此备库的恢复间隔为主库 dmwatcher.ini 中配置的值。如果备库恢复失败，会根据失败 code 区分设置为不同的值，比如 1800s，一般是在主备库日志校验不连续的情况下设置，其他还可能设置为 3s、30s、300s 或者dmwatcher.ini 中设置的值，这里不再详细说明，具体可通过服务器和守护进程的 log日志查看详细的设置信息，也可以通过监视器的 show arch send info 命令查看相关code 信息。
完整的故障恢复流程如下：
- 通知备库丢弃 KEEP_PKG；
- 通知主库发送归档日志，同步历史数据；
- 通知主库切换为 Suspend 状态；
- 再次通知主库发送归档日志；
- 通知主库设置备库归档为 Valid 状态；
- 通知主库切换为 Open 状态。
整个恢复过程中最耗时的是发送归档日志，当存在多个备库需要恢复时，为了提高恢复的效率，采用多备库并行发送归档的方式进行。守护进程每次搜集一个可恢复备库到恢复列表，按照上述故障恢复流程执行单个步骤，在等待发送归档日志的过程中，继续检测是否有备库可以恢复，如果有则加入恢复列表，也对其开始进行恢复流程处理；如果没有则检查恢复列表中是否有归档日志发送完成的备库，有则对其进行后续步骤处理，直至归档变成有效状态后从恢复列表中删除。对于恢复过程中出错的备库，也从恢复列表中删除。当恢复列表为空时，恢复流程执行结束，守护进程恢复为 OPEN 状态。
恢复过程中，守护进程会继续检测是否有恢复列表之外的备库需要恢复，如果有则可以动态加入恢复列表，实现动态并行恢复。
注意：以下情况会导致 Recovery 过程中断：
- Recovery 过程中收到监视器的命令。
- 存在多个备库时，Recovery过程中发现其他正常备库故障，且符合failover 条件，则守护进程主动中断 Recovery，先做 failover 处理。
- 存在多个备库时，Recovery 过程中发现到其他正常备库归档发送异常，则守护进程主动中断 Recovery，先做异常处理。
- Recovery 过程中，当前正在被恢复的备库出现异常。 ⑤正在执行 Recovery 的主库或备库是 DMDSC集群，Recovery 过程中 DMDSC 集群启动故障处理或者故障重加入，也会中断当前的 Recovery动作。
在守护进程打开备库异常监控的情况下，对于异常备库的恢复处理需要注意下面两点：
- 如果主备库的 LSN 已经相等，但是根据统计出来的时间信息判断主库的归档发送时间或备库的日志重演时间仍然大于设置的阈值，则不会再进入Recovery状态，直到主库上有新的日志产生需要同步到备库，可以对统计的历史时间信息进行更新的情况下才会再进入 Recovery 状态尝试恢复。
- 在进入 Recovery 状态后，通知主库 Suspend之前（主备库数据已经同步一致），会对主库的归档发送时间和备库的日志重演时间进行检查，在两者都小于或等于设置的阈值的情况下，才允许继续执行Suspend，并恢复备库归档为有效状态，否则不允许再往下执行，本次 Recovery 执行失败。
