达梦数据守护集群原理及使用

一、达梦守护集群介绍

主库： 提供读写服务，写操作会产生REDO日志，通过MAL系统将日志同步至备库重演。

主库守护进程： 在主库、备库守护进程 和 监视器之间中转信息，对故障情况进行检测，在条件允许的前提下进行故障处理。

备库： 提供只读服务，通过重演日志和主库保持数据同步。

备库守护进程： 在备库、主库守护进程 和 监视器之间中转信息，对故障情况进行检测，在条件允许的前提下进行故障处理。

监视器： 用于监控整套集群的运行情况，并提供一系列集群管理命令，对故障情况进行检测，在条件允许的前提下进行故障处理。

消息1： 主库、备库定时1s1次收集服务器信息发送至守护进程，守护进程再1s1次转发给监视器，消息内容主要包括mode、stat、seq/lsn、ohis、arch info、apply info、dsc info、dseq/code等。

消息2： 守护进程之间互相发送各自所守护的dmserver信息，内容在消息1的基础上稍作精简、并附带守护进程所认定的本地库OK/ERROR状态信息。

消息3： 主库和备库之间的MAL通信消息，走MAL通信系统，传递日志包、日志包响应消息、以及若干定时消息（主、备库之间也会通过MAL系统定时广播一些信息，用于自动接管判断、备库可用性判断等）。

消息4-1： （1）监视器命令执行消息。 （2）监视器confirm确认消息（确认监视器）。

消息4-2： （1）转发监视器执行命令。 （2）dmwatcher定时1s1次向dmserver发送的广播消息，内容主要是watcher和monitor的一些统计信息，登记到dmserver上以供查询和部分逻辑判断使用，比如v$dmwatcher和v$dmmonitor。

Redo日志包含了所有物理数据页的修改内容。 Insert/delete/update等DML操作、Create Table等DDL操作，最终都会转化为对物理数据页的修改，这些修改都会反映到Redo日志中。 一般来说一条Insert等SQL语句，在系统内部会转化为多个相互独立的物理事务来完成，物理事务提交时会将产生的Redo日志写入缓冲区RLOG_PKG中。 一个物理事务包含一条或者多条Redo记录（Redo Record），每条Redo记录（RREC）都对应一个修改物理数据页的动作。

日志包是一个自描述结构，包括日志包头、日志包体和包尾附加信息3个部分。 日志包头：存放日志包的自描述信息，包括日志包序号、包长度、LSN信息、加密压缩信息等。 日志包体：存放若干条PTX日志。 包尾附加信息：存放包内的日志并行度信息、DSC的依赖信息、HASH校验值，属于变长的自描述信息。 主库以日志包为单位向备库发送日志。 备库在收到日志后，需要进行一系列的连续性校验，因此目前一条消息中仅包含一个日志包（系统内部会尽可能的将已产生的日志合并成一个体积较大的日志包，而非N个日志包，以减少通信代价和日志刷盘代价）。

REALTIME归档流程

1. 日志需要先同步给REALTIME备库

2. 如果到所有REALTIME备库都同步失败，则暂缓写入本地联机日志，需要先等故障处理完成后，再将pkg写入本地；如果是部分备库失败、部分备库成功，则还是正常写入本地联机日志。

3. 存在同步失败情况时，需要根据ARCH_FAILOVER决定是否切换Suspend状态。

4. 主库一旦切换Suspend，则需要等待主库守护进程进入Failover流程将其重新Open。

同步失败情况包括：

1》发送失败

2》备库校验失败，拒收日志

3》超时仍未收到响应消息，也认为同步失败。

目前最新的超时计算方法： 单机主库、DSC主库（n_ok_ep=1）：IO_TIMEOUT DSC主库（n_ok_ep > 1）：MAX(15, MIN(IO_TIMEOUT/2, DSC_SLOT_WAIT_TIMEOUT/2))

KEEP_PKG缓存机制： 由于PKG先发送到备库，再写入主库联机日志，主库有可能在PKG发送成功后、写入本地日志之前发生故障，如果备库收到PKG后直接重演，主库故障重启后就会少数据，因此引入KEEP_PKG机制，备库收到PKG1后先放入KEEP_PKG缓存、再接收到下一个PKG2后，将KEEP_PKG中的PKG1放入重演队列，并将PKG2放入KEEP_PKG，以此类推。

REALTIME事务一致模式条件限制：

1. 仅自动切换模式支持 受KEEP_PKG缓存机制限制，非自动切换模式目前无法支持。

2. DSC主备不支持 备库需要接收并重演DSC主库多个节点日志，在某些特殊场景下，直接重演日志有可能会引发主备数据不一致（bug631236）。

二、故障处理

2.1日志同步失败

日志同步失败后，主库的处理流程：

1. 判断是否需要切换Suspend，否：进入步骤2；是：进入步骤3；

2. 将备库归档失效，主库不再做任何处理，后续守护进程会进入步骤5。

3. 主库需要切换Suspend

1》realtime：主库切换suspend状态

2》timely：将备库归档失效、主库切换suspend状态

3》等待守护进程发起Failover流程，进入步骤4。

4. 守护进程切换到Failover状态，处理完成后，切回Open状态

1》realtime：先通知主库将备库归档失效、再通知主库Open

2》timely：直接通知主库Open

5. 守护进程切换到Recovery状态，处理完成后，切回Open状态

对备库发起异步恢复流程，备库日志追平后，归档恢复有效状态，重新恢复实时同步。 （为了确保备库追平日志，recovery到最后，主库会短暂进入Suspend状态，让主库暂时不再写入新日志）

2.2备库故障

1. 备库实例故障

主库的故障处理流程和场景1基本是相同的，除了最后的Recovery步骤。

要等备库故障恢复后，才可以发起Recovery。

2. 备库守护进程故障

在备库归档有效的情况下，不影响主、备库之间同步日志。

在备库归档无效的情况下，主库守护进程无法发起Recovery，主备同步会中断。

3. 备库实例和守护进程同时故障

包括进程异常退出、机器故障、内网网卡故障等，表现都是备库整体失联。

主备之间的日志同步中断，主库的故障处理流程和场景1相同，除了无法发起Recovery。

4. 外网网卡故障

备库对外的读业务会受影响，守护系统内部不会触发故障处理。

2.3主库故障

1. 主库实例故障

1》dmserver进程故障（自动切换模式）

确认监视器会发起自动接管（要求确认监视器必须在故障前启动）。

如果没有如期接管，可以先在确认监视器的运行日志中找下原因，此类日志一般带有“[!!!”和“!!!]”标签，比如： [!!! 实例RT01故障前的守护进程是ERROR状态，不符合被其他实例自动接管的条件 !!!]

2》dmserver进程故障（非自动切换模式）

不会触发自动接管。

可根据需要在监视器上执行手动接管。

2. 主库守护进程故障

在备库归档有效的情况下，不影响主、备库之间同步日志。

在备库归档无效的情况下，主库守护进程无法发起Recovery，主备同步会中断。

3. 主库实例和守护进程同时故障

包括进程异常退出、机器故障、内网网卡故障等，表现都是主库整体失联。

1》自动切换模式

确认监视器会发起自动接管（要求确认监视器必须在故障前启动）。

如果没有如期接管，可以先在确认监视器的运行日志中找下原因，此类日志一般带有“[!!!”和“!!!]”标签，比如： [!!! 实例RT01故障前的守护进程是ERROR状态，不符合被其他实例自动接管的条件 !!!]

2》非自动切换模式

不会触发自动接管。

可根据需要在监视器上执行手动接管。

4. 外网网卡故障

主库对外业务会受影响，INST_SERVICE_IP_CHECK=1时，会对Open状态的主库外网网卡进行检测。 如果检测到异常，会强制将主库退出，以便备库能及时接管，继续对外提供服务。

三、常见问题分析

1. 系统启动后没有open

（1）环境搭建步骤是否正确。        

 对于新初始化库，仅在首次启动时不需要指定mount，后续都需要以mount方式启动。

（2）检查集群配置是否正确，ip、端口等。

（3）节点间通信是否正常，防火墙是否关闭。

（4）是否主、备库所有节点都已经启动。      

  1》主库需要等所有备库启动后才会自动Open，避免出现多主。        

  2》备库只要等主库启动，并且和主库数据一致，就可以自动Open。

（5）监视器上执行check open命令，查看无法自动Open原因。

（6）必要时，可通过监视器open database命令，将库强制Open。

2. 主库运行过程中，发生Suspend状态切换。

（1）如果是Recovery中的Suspend，则是正常现象。

（2）否则就是主库向备库发送日志失败，主动转入Suspend，需要再去主、备日志中查找失败原因。          

 1》可能是网络波动        

 2》或者系统压力过大，mal心跳消息检测超时，主动关闭链路。        

 3》也可能备库有日志堆积导致延迟响应，主库等待超时后，主动关闭链路等（超时计算方式见前文）。

3. 主库切换Suspend状态后，未自动Open（守护进程未切换Failover）

（1）监视器执行show命令，查看集群整体运行状况。

（2）主库守护进程如果是Recovery状态，则是正常现象，Recovery结束后会自动Open。

（3）否则，监视器执行check open命令、结合运行日志，确认无法自动Open原因。

（4）自动切换模式下，主库守护进程如果是confirm状态，可在确认监视器日志中搜索“failover”关键字，查看无法failover原因，比如：          Self monitor is in confirm mode, but current group(%s) is doing takeover or switchover now, not allowed to failover!

（5）必要时，可通过监视器open database命令，将主库强制Open。

4.主备日志差值较大，可能是主库发送慢、也可能是备库重演慢。

（1）先看下集群配置，是事务一致还是高性能模式，事务一致模式不会有堆积情况。

（2）确认主备库之间的网络延迟情况。

（3）确认主库是否开启了批量日志发送（RLOG_PKG_SEND_NUM）。

（4）确认主库平均日志发送速度，是否存在明显异常：        

  1》在主库上查询 V$ARCH_SEND_INFO，如果主库是DSC集群，需要每个节点都查下，取最大值。            

  2》计算方法：(RECNT_SEND_TIME / RECNT_SEND_CNT / 1000000)，单位s。

（5）确认备库平均日志重演速度，是否存在明显异常：      

  1》在备库上查询V$RAPPLY_STAT，如果备库是DSC集群，仅需要查询控制节点。          

  2》计算方法：((RECNT_WAIT_TIME + RECNT_APPLY_TIME)/RECNT_APPLY_NUM) / 1000000，单位s。

（6）确认备库是否达到日志堆积上限。      

  1》select TASK_NUM, TASK_MEM_USED from V$RAPPLY_SYS;          

  2》或者查看show命令中的 N_TSK 和 TSK_MEM_USE 字段        

  3》TASK_NUM/N_TSK对应REDOS_BUF_NUM，TASK_MEM_USED/TSK_MEM_USE对应REDOS_BUF_SIZE，任意一个超出上限，都会触发日志堆积等待，延迟响应主库。

 欢迎访问达梦社区： https://eco.dameng.com/