DM8-数据守护守护进程

守护进程是管理数据守护系统的核心部件，监视器dmmonitor负责发起命令，守护进程负责解析、处理、转发命令。守护进程提供了数据库监控、故障检测、故障处理、故障恢复等各种功能。

守护进程负责监控数据库运行状态，必要时重启数据库服务。守护进程和实例链路建立成功后，数据库实例定时发送信息到守护进程，发送到守护进程的内容包括：实例进程ID、实例名、数据库模式、数据库状态、FILE_SEQ、FILE_LSN、CUR_SEQ、CUR_LSN、MAL链路状态、归档状态、公钥、MPP控制文件等信息。

守护进程更新本地记录的实例信息后，同时记录该时间戳。当检测到实例进程ID已经不存在或者超过一段时间没有收到实例信息，则会认定实例故障。如果配置了自动重启，则会将实例重新拉起。

！！！！！！！！DMDSC集群的自动重启由dmcss检测执行，单机的自动重启由守护进程检测执行。

守护进程采用超时机制判断实例是否故障，即当前时间和上次收到消息的时间差是否超过故障认定时间INST_ERROR_TIME，因此不建议在数据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判实例故障。

守护进程将监控的数据库实例信息和守护进程自身的信息（包括守护类型、守护模式、守护状态、守护日志、监视器执行序列号、执行返回码等）捆绑在一起，定时发送给其他守护进程和所有监视器。

接收并解析其他守护进程发送的消息。如果超过一段时间DW_ERROR_TIME没有收到远程守护进程消息，会将远程守护进程状态认定为ERROR状态。另外还会结合本地数据库信息和守护进程自身状态，切换数据库的运行模式和系统状态。

！！！！！！！守护进程采用超时机制判断远程守护进程是否故障，即当前时间和上次收到 消息的时间差是否超过故障认定时间（DW_ERROR_TIME），因此不建议在数 据守护系统运行过程中调整操作系统时间，避免导致这个差值很大，误判远 程守护进程故障。

主备切换，备库接管等操作都是通过监视器命令进行，监视器将操作命令分解成多个步骤顺序执行，守护进程接收这些消息并通知实例进行相应操作，例如执行SQL语句修改实例模式、状态、INI参数、设置归档状态等一系列动作，这些步骤依次执行完成后，即可完成主备库的切换或备库的接管等操作。

例如，主备切换操作，监视器首先通知待切换主备库的守护进程修改为switchover状态。设置成功后，其他监视器不能再进行命令操作。守护进程收到监视器将实例mount命令，转发到本地实例执行，实例执行完成后返回结果。执行结果包含在实例向守护进程发送的消息中，守护进程根据消息中的执行码判断是否执行成功，并响应监视器。

!!!!!!!!监视器和守护进程之间也是采用超时机制判断对方是否故障，即当前时间和 上 次 收 到 消 息 的 时 间 差 是 否 超 过 故 障 认 定 时 间 （ 守 护 进 程 配 置 的 DW_ERROR_TIME），因此不建议在数据守护系统运行过程中调整操作系统时 间，避免导致这个差值很大，误判监视器故障。

数据守护系统刚启动时，所有实例处于Mount状态，守护进程处于Startup状态，启动时需要将实例转换到Open状态，守护进程也切换到Open状态，对外提供服务。

故障自动切换模式下，备库故障后，如果主备库之间的归档状态任然有效，主库的守护进程会先切换为Confirm状态，等待确认监视器的确认消息，如果确认为符合故障处理条 件，主库守护进程再切换至 Failover 状态，将故障备库的归档失效

故障手动切换模式下，备库故障后，如果主备库之间的归档状态仍然有效，会直接切换 到 Failover 状态，并将故障备库的归档失效，不需要备库故障确认。

备库故障后，备库的守护进程如果还处于活动状态且监控功能没有被关闭，则会切换到Startup状态下。

备库故障重启后，如果存在活动主库，主库守护进程根据备库实例的模式、状态、备库守护进程状态、守护进程控制文件状态、备库已经同步到Open记录以及备库的恢复间隔等信息判断是否可以进行故障恢复，在满足故障恢复条件的情况下，主库守护进程启动Recovery流程，重新恢复主备库到一致状态。

如果一直没有观察到主库守护进程发起Recovery流程，可以借助监视器的check recover命令查找备库不满足条件的原因，并做对应的处理。

读写分离集群下，主库向即时备库发送归档失败后，会直接修改归档状态无 效，并将数据库修改为 Suspend 状态。

如果主备库之间出现网络故障，并且在网络故障期间，主库没有修改操作触 发归档日志发送，则主库会一直保持 Open 状态。

如果网络故障期间备库接管，网络恢复后，dmwatcher 会通知主库强制关闭。

备库异常，指备库的数据库实例正常，但相应速度出现异常，这里的响应速度可能受主备库之间的网络影响，比如网络不稳定、网速大幅下降，也可能受备库自身的软硬件影响，比如操作系统原因或磁盘读写速度异常降低等异常情况导致响应主库的速度变慢，这种情况下会极大拖慢主库性能，影响主库正常处理对外的业务请求。

守护进程提供 RLOG_SEND_THRESHOLD 参数用于监控主备之间的日志发送速度，此参 数应配置为大于 0 的值，否则守护进程不会打开监控功能。

主库守护进程在Open状态下对日志发送速度进行检测，一旦检测到异常，主库守护进程会切换到standby check状态，并通知主库将异常备库的归档失效，暂停到此备库的数据同步，避免拖慢主库性能。

完整的备库异常处理流程如下（Standby check状态处理）：

1、收集所有的异常备库。

2、将主库守护进程上记录的这些异常备库的最近一次回复时间修改为当前时间。恢复间隔仍然为dmwatcher.ini中配置的INST_RECOVER_TIME值。这一步骤的目的是为了防止修改备库归档为Invalid无效状态后，主库立马启动recovery，但是还未取到备库最新的LSN信息，导致recovery无法正确执行的情况发生。

3、通知主库修改这些异常备库的归档为Invalid无效状态。

4、守护进程切回Open状态。

！！！！！！下面情况会导致 Standby check 过程中断：

1. 在此状态下发现其他备库故障，且符合 failover 条件，则守护进程主 动中断 Standby check 异常处理，先做 failover 故障处理。

2. 主库是 DSC 集群，在此期间启动故障处理或者故障重加入，则守护进程 会主动中断 Standby check 异常处理。

故障自动切换模式下，主库故障后，确认监视器会捕获到故障信息，自动选出可接管的备库，并通知备库进行接管。备库接管由监视器自动触发，无需用户干预。

故障手动切换模式下，主库故障后，需要人工干预，通过监视器执行接管命令，将可接管备库切换为主库。

故障自动切换模式下，可以实时处理故障，但对网络稳定性要求更高，需要确保主备库之间，主备库与守护进程、确认监视器之间的网络稳定可靠，否则可能会误判主库故障，备库自动接管后，出现过个Open状态的主库，引发脑裂。

故障手动切换模式下，备库不会自动接管，出现节点故障或者网络故障时，由用户根据各种故障情况，进行人工干预。

主库故障重启后，守护进程根据本地和远程库的 Open 记录、LSN 信息以及模式和状态 信息来判定重启后的恢复策略，可能继续作为主库加入守护系统，也可能修改为 Standby 模式，以备库身份重新加入守护系统，如果出现分裂，则需要用户干预。

故障恢复状态（Recovery）由守护进程自行判断是否切换，和监视器无关。如果符合 以下条件，主库的守护进程可自动进入 Recovery 状态，进行数据恢复：

1、本地主库【primary，Open】，守护进程Open状态。

2、远程备库[Standby,Open]，归档状态 Invalid，守护进程 Open 状态；

3. 远程备库[Standby,Open]的ASEQ/ALSN和SSEQ/SLSN相等，没有待重做日志；

4. 根据 Open 记录等信息判断备库可加入；

5. 远程备库[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 值是一致的，在某些场景 下会被设置为不同的值，下面分别进行说明：

1. 主库守护进程主动设置恢复间隔为 3s

在以下场景中，主库的守护进程会重置内存中的 INST_RECOVER_TIME 为 3s，对满 足前述前 4 个条件的备库在 3s 后会立即启动恢复流程：

1) 数据守护系统启动完成之后；

2) 守护系统运行过程中，主库手动重启或者守护进程自动启动 Open 之后；

3) 监视器执行 Switchover 主备切换/Takeover 备库接管/强制 Open 主库的操作 之后。

2. 使用监视器命令动态设置恢复间隔

监视器提供有以下命令可动态修改 INST_RECOVER_TIME 值：

1) set database [group_name.]db_name recover time time_value 动 态 修 改 指 定 备 库 实 例 的 恢 复 间 隔 ， 只 修 改 对 应 主 库 守 护 进 程 内 存 中 的 INST_RECOVER_TIME 值。

2) set group [group_name] recover time time_value 动态修改指定组或所有组中所有备库的恢复间隔，只修改对应主库守护进程内存中的 INST_RECOVER_TIME 值。

3) set group [group_name] para_name para_value 动态修改指定组或所有组中所有守护进程的配置参数值，para_name 允许指定为 INST_RECOVER_TIME ， 同 时 修 改 dmwatcher.ini 文 件 和 主 库 内 存 中 的 INST_RECOVER_TIME 值。

以上 3 个命令都可以用来修改 INST_RECOVER_TIME 值，修改完成后，一旦主库对指 定备库执行过恢复操作，不管恢复执行成功或失败，通过监视器动态修改的内存值都不再有 效，主库守护进程在恢复完成后，会根据恢复结果重置内存中的恢复间隔值（对 dmwatcher.ini 中的值没有影响）。

3. 主库守护进程根据恢复结果设置恢复间隔

如果备库恢复成功，会重置此备库的恢复间隔为主库dmwatcher.ini中配置的值。

如果备库恢复失败，会根据失败code区分设置为不同的值，比如1800s，一般是在主备库日志校验不连续的情况下设置，其他还可能设置为 3s、30s、300s 或者 dmwatcher.ini 中设置的值，这里不再详细说明，具体可通过服务器和守护进程的 log 日志查看详细的设置信息，也可以通过监视器的 show arch send info 命令查看相关 code 信息。

完整的故障恢复流程：

1、通知备库丢弃KEEP_PKG。

2、通知主库发送归档日志，同步历史数据；

3、通知主库切换为suspend状态。

4、在次通知主库发送归档日志。

5、通知主库设置备库归档为valid状态。

6、通知主库切换为Open状态。

整个恢复过程中最耗时的是发送归档日志，当存在多个备库需要恢复时，为了提高恢复的效率，采用多备库并行发送归档的方式进行。守护进程每次搜集一个可恢复备库到恢复列表，按照上述故障恢复流程执行单个步骤，在等待发送归档日志的过程中，继续监测是否有备库可以恢复，如果有则加入恢复列表，也对其开始进行恢复流程处理；如果没有则检查恢复列表中是否有归档日志发送完成的备库，有则对其进行后续步骤处理，直至归档变成有效状态后从恢复列表删除。对于恢复过程中出错的备库，也从恢复列表中删除。当恢复列表为空时，恢复流程执行结束，守护进程恢复我OPEN状态。

恢复过程中，守护进程会继续检测是否有恢复列表之外的备库需要恢复，如果有则可以 动态加入恢复列表，实现动态并行恢复。

1、recovery过程中收到监视器的命令。

2、存在多个备库时，recovery过程中发现其他正常备库故障，且符合failover条件，则守护进程主动中断recovery，先做failover处理。

3、存在多个备库时，recovery过程中发现到其他正常备库归档发送异常，则守护进程主动中断recovery，先做异常处理。

4、recovery过程中，当前正在被恢复的备库出现异常。

5、正在执行recovery的主库或备库是DMDSC集群，recovery过程中DMDSC集群启动故障处理或者故障重加入，也会中断当前recovery动作。

1、如果主备库的LSN已经相等，但是根据统计出来的时间信息判断主库的归档发送时间或备库的日志重演时间仍然大于设置的阀值，则不会再进入recovery状态，直到主库上有新的日志需要同步到备库，可以对统计的历史时间信息进行更新的情况下才会在进入recovery状态尝试恢复。

2、在进入recovery状态后，通知主库suspend之前（主备库数据已经同步一致），会对主库的归档发送时间和备库的日志重演时间进行检查，在两者都小于或等于设置的阀值的情况下，才允许继续执行suspend，并恢复备库归档为有效状态，否则不允许在往下执行，本次recovery执行失败。