DM基本概念

基本概念归档

达梦数据库主备集群中主库与备库进行同步需要了解以下几点：
（1）主库
Primary 模式，提供完整数据库服务的实例，一般来说主库是用来直接支撑应用系统的生产库。

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

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

（4）Redo 日志
Redo 日志包含了所有物理数据页的修改内容，Insert/delete/update 等 DML 操作、Create Table 等 DDL 操作，最终都会转化为对物理数据页的修改，这些修改都会反映到 Redo 日志中。

（5）Redo 日志包（RLOG_PKG）
Redo 日志包（RLOG_PKG）是 DM 数据库批量保存物理事务产生的 Redo 日志的数据单元，以物理事务 PTX 为单位保存日志，一个日志包内可连续保存一个或多个 PTX。日志包具有自描述的特性，日志包大小不固定，采用固定包头和可变包头结合的方式，包头记录日志的控制信息，包括类型、长度、包序号、LSN 信息、产生日志的节点号、加密压缩信息、日志并行数等内容。

日志包生成时按照序号连续递增，相邻日志包的 LSN 顺序是总体递增的，但是在多节点集群的 DSC 环境下不一定连续。如果未开启并行日志，RLOG_PKG 包内日志的 LSN 是递增的。如果开启并行日志，一个 RLOG_PKG 包内包含多路并行产生的日志，每一路并行日志的 LSN 是递增的，但是各路之间并不能保证 LSN 有序，因此并行日志包内 LSN 具有局部有序，整体无序的特点。

物理事务提交时将 Redo 日志写入到日志包中，在数据库事务提交或日志包被写满时触发日志刷盘动作。日志刷盘线程负责将日志包中的 Redo 日志写入联机日志文件，如果配置了 Redo 日志归档，日志刷盘线程还将负责触发归档动作。DM 数据守护系统中，主库以RLOG_PKG 为最小单位发送 Redo 日志到备库。

RLOG_PKG 具有自描述、自校验特征，数据的组织形式更加灵活、高效，支持 HUGE 表操作产生 Redo 日志，并且支持以 RLOG_PKG 为单位进行日志加密和压缩。

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

（7）KEEP_PKG 介绍
主库的RLOG_PKG日志通过实时归档机制发送到备库后，备库将最新收到的RLOG_PKG保存在内存中，不马上启动重演，这个 RLOG_PKG 我们称之为 KEEP_PKG。

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

（9）本地归档
本地归档（Local），就是将 Redo 日志写入到本地归档日志文件的过程。本地归档在 REDO 日志写入联机日志文件后触发，由归档线程完成本地归档动作；与联机 Redo 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中的 Redo 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会自动删除最早生成的归档 Redo 日志文件，腾出空间。

配置本地归档情况下，Normal/Primary 模式库在 Redo 日志写入联机 Redo 日志文件后，将对应的 RLOG_PKG 由专门的归档线程写入本地归档日志文件中。Standby 模式库收到主库产生的 Redo 日志后，直接进行本地归档，写入本地归档日志文件中，同时启动 Redo 日 志重演。

Normal/Primary 模式库归档日志文件保存的是当前节点产生的 Redo 日志，归档日志文件内容与联机日志内容保持一致。Standby 模式库重演日志重新产生的 Redo 日志只写入联机日志文件，归档日志文件保存主库产生的 Redo 日志，因此备库联机日志文件内容和归档日志文件内容是不完全一致的。采用这种归档实现方式后，可以确保数据守护系统中所有节点的归档日志文件内容是完全一致的。

（6）实时归档
与本地归档写入保存在磁盘中的日志文件不同，实时归档（Realtime）将主库产生的Redo 日志通过 MAL 系统传递到备库，实时归档是实时主备和 MPP 主备的实现基础。实时 归档只在主库生效，一个主库可以配置 1~8 个实时备库。

（1）DDL和DML提交事务操作使主库产生Redo 信息，Redo 信息会存放在RLOG_PKG（Redo 日志包）中，在此过程中RLOG_PKG存放在内存当中，暂时不会写入联机日志中；
（2）MAL通讯系统将主库的RLOG_PKG包通过实时归档机制发送到备库B中，备库将最新收到的RLOG_PKG保存在内存中，然后进行校验是否合法，合法后标记为 KEEP_PKG，不会马上启动重演，但会将之前的KEEP_PKG通过APPLY线程队列加入日志重演任务系统，并马上响应主库，不需要等待之前的Redo日志重演结束后再响应主库；

为了防止备库上重演日志堆积太多、占用大量内存、备库重演无响应导致主库挂住不能提供服务等情况的发生 ，可通过适当调整 BUFFER 、REDOS_PRE_LOAD 、REDOS_BUF_SIZE、REDOS_BUF_NUM、REDOS_MAX_DELAY 这几个参数达到加快备库重演速度、达到设置的堆积上限后延迟响应主机 、 备库自动宕机等目的 。 其中REDOS_BUF_SIZE 和 REDOS_BUF_NUM 同时起作用，只要达到一个条件即延迟响应。

注意：备库确认收到主库发送的Redo 日志，并不保证备库已经完成重演这些 Redo 日志，因此主备库之间的数据同步存在一定的时间差。）

备库 KEEP_PKG 日志重演的时机包括：1.备库收到新的 RLOG_PKG

备库收到新的 RLOG_PKG 时，会将当前保存的 KEEP_PKG 日志重演，并将新收到的RLOG_PKG 再次放入KEEP_PKG 中。2. 收到主库的重演命令

主库会定时将 FILE_LSN 等信息发送到备库，当主库 FILE_LSN 等于备库 SLSN 时，表明主库已经将KEEP_PKG 对应的 Redo 日志写入联机日志文件中，此时备库会启动KEEP_PKG 的日志重演。3. 备库切换为新主库

在监视器执行 SWITCHOVER 或 TAKEOVER 命令，或者确认监视器通知备库自动接管时，备库会在切换为PRIMARY 模式之前，启动 KEEP_PKG 的日志重演。

（3）主库收到备库的响应消息，确认备库已经收到 Redo 日志后，主库再将 Redo 日志写入联机日志文件中。

 DMDSC 状态

DMDSC 状态标识 DMDSC 集群节点状态，和数据库的状态不同。包括以下几种：

n Startup

节点启动状态，需要通过 DMCSS 工具交互，确定控制节点，执行日 

志重做等相关步骤，进入到 OPEN 状态。

n Open

实例正常工作状态，当集群内发生节点故障或启动节点重加入步骤

时，可以进入 crash_recv 或者 err_ep_add 状态，处理完成后会再回到 Open 状态。

n Crash_recv

节点故障处理状态。

n Err_ep_add 故障节点重加入状态。

数据库模式

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

Normal 模式 

提供正常的数据库服务，操作没有限制。正常生成本地归档，但不发送实时归档

（Realtime）、即时归档（Timely）和异步归档（Async）。

Primary 模式

提供正常的数据库服务，操作有极少限制。该模式下部分功能受限，包括：不支持修改

表空间文件名、不支持修改 arch_ini 参数。正常生成本地归档，支持实时归档

（Realtime）、即时归档（Timely）和异步归档（Async）。Primary 模式下，对临时表DM 数据守护与读写分离集群 V4.0

15

空间以外的所有的数据库对象的修改操作都强制生成 Redo 日志。

Standby 模式 

可以执行数据库备份、查询等只读数据库操作。正常生成本地归档，正常发送异步归档

Redo 日志；但实时归档（Realtime）、即时归档（Timely）均强制失效。该模式下时间

触发器、事件触发器等都失效。

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

SQL 语句如下：

将数据库切换为 Primary 模式：

ALTER DATABASE PRIMARY;

将数据库切换为 Standby 模式：

ALTER DATABASE STANDBY;

将数据库切换为 Normal 模式：

ALTER DATABASE NORMAL;

修改 DMDSC 库的模式必须在 DMDSC 库所有实例都处于 MOUNT 状态下才能进

行，只需要在一个节点上执行以上语句即可。

数据库状态

DM 的数据库状态包括：

Startup 状态

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

After Redo 状态

系统启动过程中联机日志重做完成后，回滚活动事务前设置为 After Redo 状态。非

Standby 模式的实例在执行 alter database open 操作前，也会将系统设置为 After

Redo 状态。

Open 状态

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

Mount 状态

数据库在 Mount 状态下，不能修改数据，不能访问表、视图等数据库对象，但可以执DM 数据守护与读写分离集群 V4.0

行修改归档配置、控制文件和修改数据库模式等操作，也可以执行一些不修改数据库内容的

操作，比如查询动态视图或者一些只读的系统过程。由于 Mount 状态不生成 PWR 日志，因

此数据页可以正常刷盘，也正常推进检查点。

系统从 Open 状态切换为 Mount 状态时，会强制回滚所有活动事务，但不会强制清理

（Purge）已提交事务，不会强制断开用户连接，也不会强制 Buffer 中的脏页刷盘。

Suspend 状态

数据库在 Suspend 状态下，可以访问数据库对象，甚至可以修改数据，但限制 Redo

日志刷盘，一旦执行 COMMIT 等触发 Redo 日志刷盘的操作时，当前操作将被挂起。

相比 Open 到 Mount 的状态切换，Open 到 Suspend 的状态切换更加简单、高效，不

会回滚任何活动事务，在状态切换完成后，所有事务可以继续执行。

一般在修改归档状态之前将系统切换为 Suspend 状态，比如备库故障恢复后，在历史

数据（归档日志）同步完成后，需要重新启用实时归档功能时：

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

2. 修改归档状态为 Valid；

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

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

另外，实时归档失败时（比如网络故障导致），Primary 实例将试图切换成 Suspend

状态，防止后续的日志写入。因为一旦写入，主备切换时有可能备库没有收到最后那次的

RLOG_PKG，导致主库上多一段日志，很容易造成主备数据不一致。当实例成功切换为

SUSPEND 状态时，可直接退出，强制丢弃多余的日志，避免主备数据不一致。

修改 DMDSC 库的状态为 SUSPEND 时，库内所有实例都不能处于 MOUNT 状态，

只需要在一个节点上执行 ALTER DATABASE SUSPEND 语句即可。

Shutdown 状态

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

不同数据库状态之间的转换规则如图 2.2 所示。用户可以通过 SQL 语句进行数据库状

态切换：1. Open 状态与 Mount 状态可以相互切换；2. Open 状态与 Suspend 状态可

以相互切换；3. Mount 和 Suspend 状态不能直接转换；4. 其他状态为系统内部状态，

用户不能主动干预。

对 DMDSC 集群，除了修改 Suspend 是同步操作，只需要在一个节点执行外，

其他状态修改都需要在每个节点上各自单独执行。

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

1. 将数据库修改为 Open 状态。当系统处于 Primary/Standby 模式时，必须强制

加上 FORCE 子句。

ALTER DATABASE OPEN [FORCE];

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

ALTER DATABASE MOUNT;

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

ALTER DATABASE SUSPEND;

由于 dmwatcher 根据数据库模式、状态等信息作为故障处理、故障恢复的

依 据 ， 建 议 在 配 置 数 据 守 护 过 程 中 ， 修 改 dm.ini 参 数

ALTER_MODE_STATUS

为 0，限制用户直接通过 SQL 语句修改数据库状态、

模式以及 OGUID，避免 dmwatcher 做出错误的决策。

http://eco.dameng.com