达梦守护集群原理介绍

1主备架构

1.1主备架构图

DM 数据守护（DM Data Watch）的实现原理：将主库（生产库）产生的Redo日志传输到备库，备库接收并重新应用Redo日志，从而实现备库与主库的数据同步。DM数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为Redo日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。

DM 数据守护系统结构参考下图。主要由主库、备库、Redo 日志、Redo 日志传输、Redo 日志重演、MAL系统、守护进程（dmwatcher）、监视器（dmmonitor）组成。

1.2 DM数据库概念

主库

Primary 模式，提供完整数据库服务的实例，一般来说主库是用来直接支撑应用系统的生产库。

备库

Standby 模式，提供只读数据库服务的实例。备库除了用于容灾，还可以提供备份、查询等只读功能，并且备库还支持临时表的 Insert/Delete/Update 操作。

备库支持临时表修改主要基于两个因素：1.临时表数据的修改不会产生 Redo 日志，主库对临时表的修改无法同步到备库；2.可以提供更大灵活性，适应更多应用场景。

根据数据同步情况，备库又可以分为可切换备库和不可切换备库。可切换备库是指，主备库之间数据完全同步，主库发生故障、备库切换为主库后，不会造成任何数据丢失的备库。

Redo日志

Redo 日志记录物理数据页内容变动情况，是数据库十分重要的一个功能，在数据库系统故障（比如服务器掉电）重启时，利用 Redo 日志可以把数据恢复到故障前的状态。

Redo日志也是数据守护的实现基础，数据库中 Insert、Delete、Update 等 DML 操作以及 Create TABLE 等 DDL 操作最终都会体现为对某一个或者多个物理数据页的修改，因此备库通过重做 Redo 日志可以与主库数据保持一致。

Redo日志传输

主备库之间的 Redo 日志传输，以日志包 RLOG_PKG 为单位，主库通过 MAL 系统发送 Redo 日志到备库。各种不同数据守护类型的区别，就在于主库日志包 RLOG_PKG 的发送时机，以及备库收到 Redo 日志后的处理策略。

Redo日志重演

Redo 日志重演的过程，就是备库收到主库发送的 Redo 日志后，在物理数据页上，重新修改数据的过程。Redo日志重演由专门的Redo日志重演服务完成，重演服务严格按照Redo日志产生的先后顺序，解析Redo日志、修改相应的物理数据页，并且重演过程中备库会生成自身的 Redo 日志写入联机日志文件。

MAL系统

MAL 系统是基于 TCP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。DM 通过 MAL 系统实现 Redo 日志传输，以及其他一些实例间的消息通讯。

守护进程

守护进程（dmwatcher）是数据守护系统的核心工具：

1.监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。

2.守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；

3.同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上。

监视器

监视器的基本作用如下：

1.监控数据守护系统

接收守护进程发送的消息，显示主、备数据库状态变化，以及故障切换过程中，数据库模式、状态变化的完整过程。

2.管理数据守护系统

用户可以在监视器上输入命令，启动、停止守护进程的监控功能，执行主备库切换、备库故障接管等操作。

3.确认状态信息

用于故障自动切换的数据守护系统中，主、备库进行故障处理之前，需要通过监视器进行信息确认，确保对应的备库或者主库是真的产生异常了，避免主备库之间网络故障引发脑裂。

4.发起故障自动接管命令

用于故障自动切换的数据守护系统中，主库发生故障时，挑选符合接管条件的备库，并通知备库执行接管操作。

1.3 数据库模式

DM 支持 3 种数据库模式：Normal 模式、Primary 模式和 Standby 模式。

Normal模式

提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。

Primary模式

提供正常的数据库服务，操作有极少限制。该模式下部分功能受限，包括：不支持修改表空间文件名、不支持修改 arch_ini 参数。正常生成本地归档，支持实时归档（Realtime）、即时归档（Timely）和异步归档（Async）。Primary 模式下，对临时表空间以外的所有的数据库对象的修改操作都强制生成 Redo 日志。

Standby模式

可以执行数据库备份、查询等只读数据库操作。正常生成本地归档，正常发送异步归档 Redo 日志；但实时归档（Realtime）、即时归档（Timely）均强制失效。该模式下时间触发器、事件触发器等都失效。

可以通过 SQL 语句切换数据库模式，模式切换必须在 Mount 状态下执行。切换模式 SQL 语句如下：

将数据库切换为 Primary 模式：

ALTER DATABASE PRIMARY;

将数据库切换为 Standby 模式：

ALTER DATABASE STANDBY;

将数据库切换为 Normal 模式：

ALTER DATABASE NORMAL;

1.4 数据库状态

Startup状态

系统刚启动时设置为 Startup 状态。

After Redo状态

系统启动过程中联机日志重做完成后，回滚活动事务前设置为 After Redo 状态。非 Standby 模式的实例在执行 alter database open 操作前，也会将系统设置为 After Redo 状态。

Open状态

数据库处于正常提供服务的状态，但不能进行归档配置等操作。

Mount状态

数据库在 Mount 状态下，不能修改数据，不能访问表、视图等数据库对象，但可以执行修改归档配置、控制文件和修改数据库模式等操作，也可以执行一些不修改数据库内容的操作，比如查询动态视图或者一些只读的系统过程。由于 Mount 状态不生成 PWR 日志，因此数据页可以正常刷盘，也正常推进检查点。

系统从Open状态切换为 Mount 状态时，会强制回滚所有活动事务，但不会强制清理（Purge）已提交事务，不会强制断开用户连接，也不会强制 Buffer 中的脏页刷盘。

Suspend 状态

数据库在 Suspend 状态下，可以访问数据库对象，甚至可以修改数据，但限制Redo日志刷盘，一旦执行 COMMIT 等触发 Redo 日志刷盘的操作时，当前操作将被挂起。

相比 Open 到 Mount 的状态切换，Open 到 Suspend 的状态切换更加简单、高效，不会回滚任何活动事务，在状态切换完成后，所有事务可以继续执行。

一般在修改归档状态之前将系统切换为 Suspend 状态，比如备库故障恢复后，在历史数据（归档日志）同步完成后，需要重新启用实时归档功能时：

将系统切换为 Suspend 状态，限制 Redo 日志写入联机 Redo 日志文件；

修改归档状态为 Valid；

重新将数据库切换为 Open 状态，恢复 Redo 日志写入功能；

备库与主库重新进入实时同步状态。

另外，实时归档失败时（比如网络故障导致），Primary 实例将试图切换成 Suspend 状态，防止后续的日志写入。因为一旦写入，主备切换时有可能备库没有收到最后那次的 RLOG_PKG，导致主库上多一段日志，很容易造成主备数据不一致。当实例成功切换为 SUSPEND 状态时，可直接退出，强制丢弃多余的日志，避免主备数据不一致。

Shutdown 状态

实例正常退出时设置为 Shutdown 状态。

用户可以通过 SQL 语句进行数据库状态切换：1. Open 状态与 Mount 状态可以相互切换；2. Open 状态与 Suspend 状态可以相互切换；3. Mount 和 Suspend 状态不能直接转换；4. 其他状态为系统内部状态，用户不能主动干预。

将数据库修改为 Open 状态。当系统处于 Primary/Standby 模式时，必须强制加上 FORCE 子句。

ALTER DATABASE OPEN [FORCE];

将数据库修改为 Mount 状态。

ALTER DATABASE MOUNT;

将数据库修改为 Suspend 状态。

ALTER DATABASE SUSPEND;

2 日志归档

实时归档流程

实时归档是实时主备数据同步的基础，其流程如下图所示：

实时归档流程：

1.主库生成联机 Redo 日志。

2.当触发日志写文件操作后，日志线程先将 RLOG_PKG 发送到备库。

3.备库接收后进行合法性校验（包括日志是否连续、备库状态是否 Open 等），不合

法则返回错误信息。

4.合法则作为 KEEP_RLOG_PKG 保留在内存中。

5.原有 KEEP_RLOG_PKG的 Redo 日志加入 Apply 任务队列进行 Redo 日志重演，并响应主库日志接收成功。当有多个备库时，主库需要收到所有备库的响应消息才继续后续操作。

实时主备系统由主库、实时备库、守护进程和监视器组成。通过部署实时主备系统，可以及时检测并处理各种硬件故障、数据库实例异常，确保持续提供数据库服务。

实时主备系统主要功能包括：

实时数据同步

主备库通过实时归档完成数据同步，实时归档要求主库将 RLOG_PKG 发送到备库后，再将 RLOG_PKG 写入本地联机 Redo 日志文件。但要注意的是，备库确认收到主库发送的 Redo 日志，并不保证备库已经完成重演这些 Redo 日志，因此主备库之间的数据同步存在一定的时间差。

主备库切换

主备库正常运行过程中，可以通过监视器的 Switchover 命令，一键完成主备库角色转换。主备库切换功能可以确保在软、硬件升级，或系统维护时，提供不间断的数据库服务。

自动故障处理

备库故障，不影响主库正常提供数据库服务，守护进程自动通知主库修改实时归档为 Invalid 状态，将实时备库失效。

 自动数据同步

备库故障恢复后，守护进程自动通知主库发送归档 Redo 日志，重新进行主备库数据同步。并在历史数据同步后，修改主库的实时归档状态为 Valid，恢复实时备库功能。

备库接管后，原主库故障恢复，守护进程自动修改原主库的模式为 Standby，并重新作为备库加入主备系统。

 备库接管

主库发生故障后，可以通过监视器的 Takeover 命令，将备库切换为主库，继续对外提供服务。如果配置为自动切换模式，确认监视器可以自动检测主库故障，并通知备库接管，这个过程不需要人工干预。

备库强制接管

如果执行 Takeover 命令不成功，但主库可能由于硬件损坏等原因无法马上恢复，为了及时恢复数据库服务，DM 提供了 Takeover Force 命令，强制将备库切换为主库。但需要由用户确认主库故障前，主库与接管备库的数据是一致的（主库到备库的归档是 Valid 状态），避免引发守护进程组分裂。

读写分离访问

在备库查询的实时性要求不高的条件下，实时主备也可以配置接口的读写分离属性访问，实现读写分离功能特性。

3 归档状态

本地归档、实时归档和即时归档均包含两种状态：Valid 和 Invalid。异步归档只有一种归档状态：Valid。而同步备库有三种归档状态，分别是 Valid，Invalid 和 Async_send。

Valid 归档有效，正常执行各种数据库归档操作。

Invalid 归档无效，主数据库不发送联机 Redo 日志到备数据库。

Async_send 归档无效，但主库正在同步历史数据到同步备库。

在不同的归档类型中，归档状态转换时机不同。具体转换时机描述如下：

1.主备库启动后，主库到所有备库的归档默认为 Valid 状态，守护进程 Open 主库前，根据主备库日志同步情况，将数据不一致备库的归档修改为 Invalid 状态。

2.实时备库和即时备库故障恢复，从主库同步历史数据后，守护进程将主库修改为 Suspend 状态，并将主库到备库的归档状态从 Invalid 修改为 Valid。当守护进程再次 Open 主库后，主备库数据重新恢复为一致状态。

3.同步备库故障恢复，主库开始同步历史数据时，将备库归档状态从 Invalid 修改为 Async_send，中间会将日志刷盘线程挂起确保备库能够追到和主库数据完全一致，并将主库到备库的归档状态从 Async_send 修改为 Valid，然后唤醒日志刷盘线程，主备库数据重新恢复为一致状态。

4.主库发送日志到实时备库失败挂起，守护进程处理 Failover 过程中，将主库到备库的归档状态修改为 Invalid。

5.主库发送即时归档失败后，直接将主库到备库的归档改为 Invalid 状态。

6.主库发送同步归档失败后，直接将主库到备库的归档改为 Invalid 状态，并且不会有主库切换到 Suspend 状态的过程。

7.异步归档始终保持 Valid 状态，一旦归档失败马上返回，等待下一次触发再继续发送。

8.主库发现同步备库归档状态为 Invalid，且满足同步备库故障恢复的条件时，将主库到备库的归档状态从 Invalid 改为 Async_send，并开始同步历史数据到备库，同步完成后会将备库归档状态从 Async_send 修改为 Valid 有效状态。

4 守护进程

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

监控数据库实例

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

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

发送状态信息

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

监控其他守护进程

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

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

5 监视器

监视器分为两种类型：普通监视器和确认监视器。监视器类型由配置文件（dmmonitor.ini）的 MON_DW_CONFIRM 参数来确定。MON_DW_CONFIRM 参数的默认值是 0，表示普通监视器；MON_DW_CONFIRM 参数值为 1 时，表示确认监视器。

用户可根据实际需要，选择是否配置监视器或配置多少个监视器。普通监视器和确认监视器可以在系统中同时存在，也可以只配置其中一种。故障自动切换模式下，必须配置确认监视器。

为了防止单实例确认监视器出现故障，建议用户将确认监视器配置多实例形式。

普通监视器

一个数据守护系统中，最多允许同时启动 10 个普通监视器。多个普通监视器之间的关系为相互独立，互不干扰。

所有普通监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。

确认监视器

确认监视器和普通监视器的区别在于，除了具备普通监视器所有功能之外，确认监视器还具有状态确认和自动接管两个功能。在数据守护系统的故障自动切换模式下，必须部署一个确认监视器，否则在出现数据库故障时，会导致数据库服务中断。DM 提供了两种确认监视器的配置形式，分别为单实例和多实例。

一个数据守护集群中，最多只能配置一个确认监视器。

当单实例确认监视器故障时，无法继续进行集群的故障自动接管和备库故障确认，影响正常使用，故 DM 提供了多实例确认监控器来进一步提高集群的高可用性。

状态确认

故障自动切换模式数据守护系统中，主库守护进程监测到备库故障时，需要向确认监视器求证，确认备库是真的故障了，再启动故障处理流程将归档失效，避免引发脑裂。比如，主库网络故障，主库直接将归档失效继续以 Primary 模式提供服务；同时，确认监视器认为主库故障，将备库切换为 Primary 模式，守护进程组中同时出现多个主库，引发脑裂。

状态确认只对故障自动切换数据守护系统有效，主库守护进程在满足一定条件时，会切换到 Confirm状态，向确认监视器进行求证。

主库守护进程切换到 Confirm 之后，根据不同的场景决定是否切换为 Failover 状态并启动故障处理流程，这里列举出几种常见的场景处理（注意前提是主库的守护进程已经处于 Confirm 状态）：

1.主库网络故障，主库到备库、主库到确认监视器的连接异常。这种情况下主库守护进程一直保持 Confirm 状态，不会启动故障处理流程。

2.备库故障或者备库网络故障，主库守护进程会切换为 Failover 状态，启动故障处理流程。

3.主备库之间网络故障，但与确认监视器之间的网络正常，确认监视器确认主库满足 Failover 执行条件，主库守护进程会切换为 Failover 状态，启动故障处理流程，否则主库守护进程一直保持在 Confirm 状态。

自动接管

故障自动切换模式下，确认监视器检测到主库故障后，根据收到的主备库 LSN、归档状态、MAL 链路状态等信息，确定一个接管备库，并将其切换为主库。确认监视器启动自动接管流程的主要场景有三种，任何一种都会导致备库自动接管。场景如下：

1.主库数据库实例异常终止，主库守护进程正常。

2.主库硬件故障、或者数据库实例和守护进程同时故障。

3.主库网络故障，主备库之间、主库与监视器之间连接异常。

若想实现备库自动接管，主库、归档状态、备库都必须符合一定条件才行。条件如下：

主库

主库是 Primary 模式、Open 状态时，产生故障。

主库守护进程故障，故障前是 Open/Recovery 状态。

故障主库与接管备库和确认监视器之间的 MAL 链路断开。

归档状态

故障主库到接管备库的归档状态为 Valid。

备库

接管备库是 Standby 模式、Open 状态。

达梦社区地址：https://eco.dameng.com