达梦数据库主备集群学习

一、概述

达梦主备集群就是一主一备（也可以一主多备）是一种集成化的高可靠性解决方案，同时满足用户对数据安全性和高可用性的要求。解决由于硬件故障、自然灾害等原因导致的数据库服务长时间中断问题，满足用户不间断提供数据库服务的要求，即实现系统的双机热备功能。在使用的过程中，如果是实时同步模式的话，主机和备机的数据保持完全一致。主机产生一条新的记录时，在记录写入数据库文件之前，会把新产生的Redo日志文件发送到备机，由备机重新执行接收到的Redo日志，来保证主备集群数据的一致性。

几个重要的概念：

1.主库：Primary 模式，提供完整数据库服务的实例，负责处理所有事务和数据更新操作。它生成联机 Redo 日志，并通过实时归档机制将 Redo 日志发送到备库，一般来说主库是用来直接支撑应用系统的生产库。

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

3.Redo 日志：Redo 日志记录物理数据页内容变动情况，是数据库十分重要的一个功能，在数据库系统故障（比如服务器掉电）重启时，利用 Redo 日志可以把数据恢复到故障前的状态。Redo 日志也是数据守护的实现基础，数据库中 Insert、Delete、Update 等 DML 操作以及 Create TABLE 等 DDL 操作最终都会体现为对某一个或者多个物理数据页的修改，因此备库通过重做 Redo 日志可以与主库数据保持一致。

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

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

6.守护进程：守护进程（dmwatcher）是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据同步情况，在出现故障时启动各种处理预案。守护进程是各种消息的中转站，接收数据库实例、其他守护进程、以及监视器发送的各种消息；同时，守护进程也会将收到的数据库实例消息转发给其他守护进程和监视器。守护进程必须和被守护的数据库实例部署在同一台机器上。

7.监视器：监视器（dmmonitor）用来监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等。监视器一般配置在数据库实例和守护进程以外的机器上。

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

9.OGUID：数据守护唯一标识码，配置数据守护时，需要由用户指定 OGUID 值。其中数据库的 OGUID 在 MOUNT 状态下由系统过程 SP_SET_OGUID(xxxxx); 设置，前后加上SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);和SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);，守护进程和监视器的 OGUID 值在配置文件中设定。

10.脑裂：脑裂是同一个守护进程组中同时出现两个或者多个活动主库，并且这些主库都接收用户请求，提供完整数据库服务。一旦发生脑裂，将无法保证数据一致性，对数据安全造成严重后果。DM 数据守护系统为预防脑裂做了大量工作，例如故障自动切换模式的数据守护必须配置确认监视器。确认监视器启动故障切换之前，会进行严格的条件检查，避免脑裂发生。守护进程一旦检测到脑裂发生，会马上强制退出所有活动主库，等待用户干预，避免数据差异进一步扩大。

二、数据库状态和模式

2.1DM 数据库包含以下几种状态：

Startup：系统刚启动时的状态。

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

MOUNT：不允许访问数据库对象，只能进行控制文件维护、归档配置、数据库模式修改等操作。

OPEN：不能进行控制文件维护、归档配置等操作，可以访问数据库对象，对外提供正常的数据库服务。

SUSPEND：与 OPEN 状态的唯一区别就是，限制磁盘写入功能；一旦修改了数据页，触发 REDO 日志、数据页刷盘，当前用户将被挂起。

Shutdown：数据库关闭状态。

OPEN 状态与 MOUNT 和 SUSPEND 能相互转换，但是 MOUNT 和 SUSPEND 之间不能相互转换。

切换数据库状态的 SQL 语句如下：

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

ALTER DATABASE OPEN [FORCE];

（2）将数据库修改为 Mount 状态。

ALTER DATABASE MOUNT;

（3）将数据库修改为 Suspend 状态。

ALTER DATABASE SUSPEND;

2.2DM 数据库包含以下几种模式：

普通模式（NORMAL）：用户可以正常访问数据库，操作没有限制；

主库模式（PRIMARY）：用户可以正常访问数据库，所有对数据库对象的修改强制
生成 REDO 日志，在归档有效时，发送 REDO 日志到备库；

备库模式（STANDBY）：接收主库发送过来的 REDO 日志并重做。数据对用户只读。

三种模式只能在 MOUNT 状态下设置模式之间可以相互转换。
 对于新初始化的库，首次启动不允许使用 mount 方式，需要先正常启动并正常退出，然后才允许 mount 方式启动。
 一般情况下，数据库为 NORMAL 模式，如果不指定 MOUNT 状态启动，则自动启动到 OPEN状态。
 在需要对数据库配置时（如配置数据守护、数据复制），服务器需要指定 MOUNT 状态启动。当数据库模式为非 NORMAL 模式（PRIMARY、STANDBY 模式），无论是否指定启动状态，服务器启动时自动启动到 MOUNT 状态。

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

（1）将数据库切换为 Primary 模式：

ALTER DATABASE PRIMARY;

（2）将数据库切换为 Standby 模式：

ALTER DATABASE STANDBY;

（3）将数据库切换为 Normal 模式：

ALTER DATABASE NORMAL;

（4）修改数据库模式前后要加上以下SQL语句：

SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

三、守护进程（dmwatcher）

上文中有简单提到守护进程是 DM 数据守护系统不可或缺的核心部件，是数据库实例和监视器之间信息流转的桥梁。现在再具体介绍一下。

3.1主要功能

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

（1）监控数据库实例

守护进程负责监控数据库运行状态，必要时重启数据库服务。守护进程和实例链路建立成功后，数据库实例定时发送信息到守护进程，守护进程更新本地记录的实例信息后，同时记录该时间戳。当检测到实例进程 ID 已经不存在或者超过一段时间没有收到实例消息（INST_ERROR_TIME），则会认定实例故障。如果配置了自动重启，则会将实例重新拉起。

（2）发送状态信息

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

（3）接收监视器消息

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

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

（4）主备库启动运行

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

（5）故障处理

故障处理又分为主库故障处理、备库故障处理、备库异常处理。

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

备库故障后，故障自动切换模式下，如果主备库之间的归档状态仍然有效，主库的守护进程会先切换为 Confirm 状态，等待确认监视器的确认消息，如果确认为符合故障处理条件，主库守护进程再切换至 Failover 状态，将故障备库的归档失效。故障手动切换模式下，如果主备库之间的归档状态仍然有效，会直接切换到 Failover 状态，并将故障备库的归档失效，不需要备库故障确认。如果备库的守护进程如果还处于活动状态且监控功能没有被关闭，则会切换到 Startup 状态下。

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

3.2 守护类型

守护进程支持两种守护类型：

本地守护

提供最基本的守护进程功能，监控本地数据库服务。如果实例使用 Mount 方式启动，守护进程会通知实例自动 Open，如果连续一段时间没有收到来自其监控数据库的消息，即认定数据库出现故障，根据配置（INST_AUTO_RESTART）确定是否使用配置的启动命令重启数据库服务。异步备库也是采用这种方式配置。

全局守护

实时主备、MPP 主备和读写分离集群系统中，需要将守护进程配置为全局守护类型；DMDSC 数据守护除了仅配置异步备库，也需要将守护进程配置为全局守护类型。守护进程根据数据库服务器配置的归档类型以及 MPP_INI 参数情况，自动识别具体的集群类型（实时主备、MPP 主备、读写分离集群或 DMDSC 数据守护），全局守护类型在本地守护类型的基础上，通过和远程守护进程的交互，增加了主备库切换、主备库故障检测、备库接管、数据库故障重加入等功能。

（注意：配置全局守护类型后，守护进程守护的数据库实例，必须配置实时或即时归档，否则dmwatcher会启动失败）

3.3 守护模式

守护进程支持两种故障切换模式：

故障自动切换

主库发生故障时，确认监视器自动选择一个备库，切换为主库对外提供服务。故障自动切换模式，要求必须且只能配置一个确认监视器。具体的实现机制和使用注意事项可参考 4.4 自动接管小节。

故障手动切换

主库发生故障时，由用户根据实际情况，通过监视器命令将备库切换为主库。在用户干预之前，备库可以继续提供只读服务和临时表的操作。

（注意：一个数据守护集群，只能配置一个确认监视器。）

3.4 守护状态

守护进程包括以下一些状态：

（1）Startup 守护进程启动状态，需要根据远程守护进程发送的状态信息，结合本地数据库的初始模式、状态和数据同步情况，确定本地数据库的启动模式和状态后，进入 Open 状态。

（2）Open 守护进程正常工作，监控数据库，并定时发送数据库的状态信息，接收其他守护进程发送的信息，接收监视器发送的用户请求。

（3）Shutdown 守护进程停止监控数据库状态，不再提供主备库切换、主备库故障处理和备库故障恢复等功能。

（4）Switchover 主备库正常情况下，手动主备切换过程中设置为 Switchover 状态。

（5）Failover 远程备库故障后，本地主库执行故障处理时，守护进程设置为 Failover 状态。

（6）Recovery 故障恢复同步历史数据过程中设置为 Recovery 状态。

（7）Confirm 通过监视器确认远程主（备）库是否活动的过程中，守护进程设置为 Confirm 状态。

（8）Takeover 主库确认故障后，备库手工接管或监视器通知自动接管过程中，守护进程设置为 Takeover 状态。

（9）Open force 借助监视器命令强制 Open 主库或备库实例时，守护进程设置为 Open force 状态。

（10）Error 超过一段时间（DW_ERROR_TIME）没有接收到远程守护进程消息，本地守护进程或监视器认定远程守护进程故障，修改远程守护进程为 Error 状态。

（11）Login check 监视器执行登录命令时，守护进程所处的状态。

（12）Mppctl update 修改主库 MPP 控制文件（dmmpp.ctl）时，守护进程所处的状态，只在 MPP 主备系统出现。

（13）Change arch 监视器执行 set arch invalid 命令时守护进程所处的状态。

（14）Standby check 主库守护进程监控到备库异常后，切换到此状态下通知主库修改此备库归档无效。

（15）Clear send info 清理主库上的归档发送信息时，守护进程所处的状态。

（16）Clear rapply stat 清理备库上的重演信息时，守护进程所处的状态。

（17）Unify ep 统一 DMDSC 集群各节点实例状态，或者各实例状态已经一致时，守护进程在 Startup 或 Open 状态下通知实例执行相关操作，都进入 Unify_ep 状态执行。

（18）Css process 监视器发起的对 DMDSC 集群的部分命令，比如启动、关闭、强杀 DMDSC 库，或者打开、关闭节点实例的自动拉起功能等命令，需要借助 dmcss 执行时，守护进程会切换到此状态下。

守护进程所有状态变换和它监控的数据库的状态变换都会生成相应的 LOG 信息，写入到../log 目录中以’dm_dmwatcher_实例名_当前年月.log’方式命名的日志文件中。用户可以通过查看日志文件，分析数据库和守护进程的运行状态、监控故障处理过程。

3.4守护进程命令

守护进程既能以控制台方式启动，也可以配置为服务方式启动。可以在守护进程的控制台上输入命令，关闭守护进程，显示守护进程组的状态信息等.

命令	含义
help	显示帮助信息
exit	退出守护进程
status	显示守护进程运行状态信息
show	显示所有守护进程组中的本地库信息
show group group_name	显示指定守护进程组中的本地库信息
show version	显示守护进程自身版本信息
show monitor config	帮助监视器配置 ini 文件的信息
show link	显示守护进程上的 tcp 连接信息

四、监视器（dmmonitor）

监视器是基于监视器接口（详见 9.2 监视器接口）实现的一个命令行工具，是 DM 数据守护系统的重要组成部分。

通过监视器，可以监控数据守护系统的运行情况，获取主备库状态、守护进程状态以及主备库数据同步情况等信息。同时，监视器（dmmonitor）还提供了一系列命令来管理数据守护系统。

4.1基本功能

（1）监控数据守护系统

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

（2）管理数据守护系统

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

（3）确认状态信息

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

（4）发起故障自动接管命令

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

4.2监视器类型

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

普通监视器和确认监视器可以在系统中同时存在，也可以只配置其中一种。故障自动切换模式下，必须配置确认监视器。

1.普通监视器（非确认监视器）

所有普通监视器都可以接收守护进程消息，获取守护系统状态，也可以执行各种监控命令。所有监视器都可以发起 Switchover 等命令，但守护进程一次只能接收一个监视器的命令，在一个监视器命令执行完成之前，守护进程收到其他监视器发起的请求，会直接报错返回。（一个数据守护系统中，最多允许同时启动 10 个普通监视器。多个普通监视器之间的关系为相互独立，互不干扰）

2.确认监视器

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

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

1）单实例

除了具备普通监视器的所有功能之外，单实例确认监视器具有状态确认和自动接管两个功能。相比于多实例确认监视器，单实例确认监视器出现故障就无法正常提供服务。

2）多实例

多实例确认监控器提供的功能与单实例确认监控器相同。多实例确认监视器采用 RAFT 协议实现。在多实例确认监视器中，只有一个实例作为确认监视器提供服务，其它实例作为备库存在而不提供服务。当确认监视器出现故障时，系统会从它的备库中选举一位作为新的确认监视器继续提供服务。

多实例确认监视器是基于 RAFT 协议实现的监视器集群，故在任意时刻，多实例确认监视器中的每一个实例节点也处于 Leader（主监视器）、Follower（备监视器） 或 Candidate（候选监视器） 的状态之一。

4.3状态确认

故障自动切换模式数据守护系统中，主库守护进程监测到备库故障时，需要向确认监视器求证，确认备库是真的故障了，再启动故障处理流程将归档失效，避免引发脑裂。

状态确认只对故障自动切换数据守护系统有效，主库守护进程在满足一定条件时，会切换到 Confirm 状态，向确认监视器进行求证，主库守护进程切换到 Confirm 之后，根据不同的场景决定是否切换为 Failover 状态并启动故障处理流程。

4.4自动接管

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

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

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

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

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