linux中mysql回滚重演_DM7 达梦 数据库 数据守护(Data Watch) (1) -- 基本概念

1 数据守护概念

DM 数据守护(Data Watch)是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。数据守护可以配置成实时主备、MPP主备、或读写分离集群,基本不受数据规模的影响,只需数秒时间就可以将备库切换为主库对外提供数据库服务。

DM 数据守护(Data Watch)的实现原理非常简单：将主库(生产库)产生的 Redo日志传输到备库，备库接收并重新应用 Redo 日志，从而实现备库与主库的数据同步。

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

相关组件说明：

主库：

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

备库：

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

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

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

Redo 日志

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

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

Redo 日志传输

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

Redo 日志重演

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

守护进程

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

监视器

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

2 DW理论概念说明

2.1 数据库模式

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;

2.2 数据库状态

DM 的数据库状态包括：

2.2.1 Startup 状态

系统刚启动时设置为 Startup 状态。 https://www.cndba.cn/dave/article/3665

2.2.2 After Redo 状态

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

2.2.3 Open 状态

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

2.2.4 Mount 状态

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

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

2.2.5 Suspend 状态

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

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

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

https://www.cndba.cn/dave/article/3665

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

修改归档状态为 Valid。

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

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

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

2.2.6 Shutdown 状态

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

数据库状态转换如下图：

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

切换数据库状态的 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 语句修改数据库状态、 模式，避免 dmwatcher 做出错误的决策。

2.3 LSN 介绍

LSN(Log Sequence Number)是由系统自动维护的 Bigint 类型数值，具有自动递增、全局唯一特性，每一个LSN 值代表着 DM 系统内部产生的一个物理事务。物理事务(Physical Transaction，简称 ptx)是数据库内部一系列修改物理数据页操作的集合，与数据库管理系统中事务(Transaction)概念相对应，具有原子性、有序性、无法撤销

等特性。

DM 数据库中与 LSN 相关的信息，可以通过查询 V$RLOG 表来获取。DM 主要包括以下几种类型的 LSN 值：

1)CUR_LSN 是系统已经分配的最大 LSN 值。物理事务提交时，系统会为其分配一个唯一的 LSN 值，大小等于 CUR_LSN + 1，然后再修改 CUR_LSN=CUR_LSN+1。

2) FILE_LSN 是已经写入联机 Redo 日志文件的最大 LSN 值。每次将 Redo 日志缓冲区 RLOG_BUF 写入联机 Redo 日志文件后，都要修改 FILE_LSN 值。

3)FLUSH_LSN 是已经发起日志刷盘请求，但还没有真正写入联机 Redo 日志文件的最大 LSN 值。

4)CKPT_LSN 是检查点 LSN，所有 LSN <= CKPT_LSN 的物理事务修改的数据页，都已经从 Buffer 缓冲区写入磁盘，CKPT_LSN 由检查点线程负责调整。

1)CLSN 与 CUR_LSN 保持一致，数据库已经分配的最大 LSN 值。

2)FLSN 与 FILE_LSN 保持一致，已写入联机日志文件的 LSN 值。

3)SLSN 是 Standby LSN 的缩写，是备库收到的最后一个 RLOG_BUF 的最大 LSN值，与主库的 FLUSH_LSN 保持一致。

4)SSLSN 是 Second Standby LSN 的缩写，实时主备或 MPP 主备中备库收到的倒数第二个 RLOG_BUF 的最大 LSN 值。在读写分离集群中 SLSN == SSLSN。

5)TAKEOVER_LSN 备库接管时的 SLSN 值，记录在 dmwatcher.ctl 文件中。同一守护进程组中故障库恢复时，根据是 TAKEOVER_LSN 和故障库的 FILE_LSN 值，来 判断故障库数据是否可以恢复。

2.4 Redo 日志

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

一个物理事务包含一个或者多个 Redo 记录(Redo Record)，每条 Redo 记录(RREC)都对应一个修改物理数据页的动作。根据记录内容的不同，RREC 可以分为两类：物理 RREC 和逻辑 RREC。 https://www.cndba.cn/dave/article/3665

1)物理 RREC 记录的是数据页的变化情况，内容包括：操作类型、修改数据页地址、页内偏移、数据页上的修改内容，如果是变长类型的 Redo 记录，在 RREC 记录头之后还会有一个两字节的长度信息。

2)逻辑 RREC 记录的是一些数据库逻辑操作步骤，主要包括：事务启动、事务提交、事务回滚、字典封锁、事务封锁、B 树封锁、字典淘汰等。

逻辑 RREC 记录是专门为数据守护增加的记录类型，用来解决备库重演 Redo 日志与用户访问备库之间的并发冲突，以及主库执行 DDL 后导致的主备数据库字典缓存不一致问题。

备数据库解析到逻辑 RREC 记录时，根据记录内容，生成相应的事务，封锁对应的数据库对象，并从字典缓存中淘汰过期的字典对象。

2.5 Redo 日志缓冲区

Redo 日志缓冲区 RLOG_BUF 是 DM 数据库内部的一个数据结构，用来优化、提升 Redo 日志刷盘效率。物理事务提交时将 Redo 日志写入到 RLOG_BUF 中，在数据库事务提交或 RLOG_BUF 缓冲区被写满时触发日志刷盘动作。日志刷盘线程负责将 RLOG_BUF 中的 Redo 日志写入联机日志文件，如果配置了 Redo 日志归档，日志刷盘线程还将负责触发归档动作。 https://www.cndba.cn/dave/article/3665

https://www.cndba.cn/dave/article/3665

DM 数据守护系统中，主库以 RLOG_BUF 缓冲区为最小单位，发送 Redo 日志到备库。

RLOG_BUF 由一系列的 RLOG_PAGE 组成，RLOG_PAGE 是物理事务的保存载体，一个 RLOG_PAGE 可以保存一个或多个物理事务信息，一个物理事务、甚至一条 Redo 记录也可 能需要存放到多个 RLOG_PAGE 中。

2.6 KEEP_BUF 介绍

主库的RLOG_BUF日志通过实时归档机制发送到备库后，备库将最新收到的RLOG_BUF 保存在内存中，不马上启动重演，这个 RLOG_BUF 我们称之为 KEEP_BUF。引入 KEEP_BUF 的主要目的是，避免下述场景中，主库故障重启后不必要的主备切换，减少用户干预。

场景说明(实时主备或 MPP 主备)：

1.用户登录主库 A 执行

create table tx(c1 int);

insert into tx values(1);

commit;

其中 commit 操作将触发实时归档，发送 RLOG_BUF 到备库 B。

2.备库 B 收到 RLOG_BUF，响应主库 A，并启动日志重演。

3.主库 A 在 RLOG_BUF 写入联机日志文件之前故障。

4.主库 A 重新启动后，由于 RLOG_BUF 没有写入联机日志文件，之前插入 tx 表的数据丢失；但此时备库 B 已经重演日志成功，tx 表中已经插入一行数据。

上述场景中，主备库数据不再保持一致，必须将备库 B 切换为主库，并重新从 B 同步 数据到 A。如果配置的是手动切换模式，则必须要有用户干预，进行备库接管后，才能恢复数据库服务。

引入 KEEP_BUF 后，备库 B 收到主库 A 发送的 RLOG_BUF，并不会马上启动日志重演，主库 A 重启后，守护进程 A 检测到备库 B 存在 KEEP_BUF，通知备库 B 丢弃 KEEP_BUF 后， 直接 Open 主库 A，就可以继续提供数据库服务。并且，这些操作是由守护进程自动完成， 不需要用户干预。

如果备库自动接管、或者用户发起备库接管命令，那么备库的 KEEP_BUF 将会启动重演，不管主库是否已经将 KEEP_BUF 对应的 Redo 日志写入联机日志文件中，备库接管时的 TAKEOVER_LSN 一定是大于等于主库的 FILE_LSN。当故障主库重启后，仍然可以作为备库，自动重新加入数据守护系统。

备库 KEEP_BUF 日志重演的时机包括：

收到主库的重演命令，并且备库的 SLSN 满足重演条件

主库会定时每 5 秒将 FILE_LSN 等信息发送到备库，当主库 FILE_LSN == 备库 SLSN 时，表明主库已经将 KEEP_BUF 对应的 Redo 日志写入联机日志文件中，此时备库会启动 KEEP_BUF 的日志重演。

备库收到新的 RLOG_BUF

备库收到新的 RLOG_BUF 时，会将当前保存的 KEEP_BUF 日志重演，并将新收到的 RLOG_BUF 再次放入 KEEP_BUF 中。https://www.cndba.cn/dave/article/3665

备库切换为新主库

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

即时归档在 RLOG_BUF 写入主库联机 Redo 日志文件后，再发送 RLOG_BUF 到备库，因此即时备库没有 KEEP_BUF。

2.7 联机 Redo 日志文件

DM 数据库默认包含两个联机 Redo 日志文件(如 DAMENG01.log、DAMENG02.log， 系统内部分别称为 0 号文件、1 号文件)，用来保存 Redo 日志，RLOG_BUF 顺序写入联机 Redo 日志文件中，当一个日志文件写满后，自动切换到另外一个 Redo 日志文件。其中 0 号文件是 Redo 日志主文件，在日志主文件头里保存了诸如 CKPT_LSN，CKPT_FILE，CKPT_OFFSET，FILE_LSN 等信息。系统故障重启时，从[CKPT_FILE, CKPT_OFFSET] 位置开始读取 Redo 日志，解析 RREC 记录，并重新修改对应数据页内容，确保将数据恢复 到系统故障前状态。

随着检查点(Checkpoint)的推进，对应产生 Redo 日志的数据页从数据缓冲区(DATA Buffer)写入磁盘后，联机 Redo 日志文件可以覆盖重用、循环使用，确保 Redo 日志文 件不会随着日志量的增加而增长。

任何数据页从 Buffer 缓冲区写入磁盘之前，必须确保修改数据页产生的 Redo 日志已经写入到联机 Redo 日志文件中。

在联机日志文件中，可以覆盖写入 Redo 日志的文件长度为可用日志空间；不能被覆盖， 系统故障重启需要重做部分，为有效 Redo 日志，有效 Redo 日志的 LSN 取值范围是 (CKPT_LSN,FILE_LSN]；已经被发起日志刷盘请求，但还没有真正写入联机 Redo 日志 文件的区间为(FILE_LSN,FLUSH_LSN]，称为待写入日志空间。

2.8 归档介绍

归档是实现数据守护系统的重要技术手段，根据功能与实现方式的不同，DM 数据库的归档可以分为 4 类：本地归档、实时归档、即时归档和异步归档。

2.8.1 本地归档

Redo 日志本地归档(LOCAL)，就是将 Redo 日志写入到本地归档日志文件的过程。

配置本地归档情况下，Redo 日志刷盘线程将 Redo 日志写入联机 Redo 日志文件后，对应的 RLOG_BUF 由专门的归档线程负责写入本地归档日志文件中。

与联机 Redo 日志文件可以被覆盖重用不同，本地归档日志文件不能被覆盖，写入其中 的 Redo 日志信息会一直保留，直到用户主动删除；如果配置了归档日志空间上限，系统会自动删除最早生成的归档 Redo 日志文件，腾出空间。

DM 提供了按指定的时间或指定的 LSN 删除归档日志的系统函数，但用户需要谨慎使用。

例如，在守护系统中，如果备库故障了，主库继续服务，主库的日志在继续增长。此时如果删除尚未同步到备库的主库归档日志，那么等待备库重启之后，会由于备库收到的日志缺失导致主备库无法正常同步数据。相关的系统函数分别为 SF_ARCHIVELOG_DELETE _BEFORE_TIME 和 SF_ARCHIVELOG_DELETE_BEFORE_LSN。

本地归档文件在配置的归档目录下生成并保存，文件命名规则为：日志归档名_年月日时分秒毫秒.log，如：ARCHIVE_LOCAL1_20151014153933458.log。如果磁盘空间不足，且没有配置归档日志空间上限(或者配置的上限超过实际空间)，系统将自动挂起，直到用户主动释放出足够的空间后继续运行。

为了最大限度的保护数据，当磁盘空间不足导致归档写入失败时，系统会挂起等待，直到用户释放出足够的磁盘空间。当磁盘损坏导致归档日志写入失败时，系统会强制 HALT。

2.8.2 实时归档

与本地归档写入本地磁盘不同，实时归档(Realtime)将主库产生的 Redo 日志和将Huge 表数据修改，通过 MAL 系统传递到备库，实时归档是实时主备和 MPP 主备的实现基础。实时归档只有在主库配置为 Primary 模式时才能生效，一个主库可以配置 1~8 个实时备库。

实时归档的执行流程是，主库在 Redo 日志(RLOG_BUF)写入联机 Redo 日志文件前，将 Redo 日志发送到配置为 Standby 模式的备库，备库收到 Redo 日志(RLOG_BUF)后放入 KEEP_BUF，并将原有的 KEEP_BUF 中的内容加入日志重演任务系统后，马上响应主库，而不是等待 Redo 日志重演结束再响应主库，主库收到响应消息，确认备库已经收到Redo 日志，再将 Redo 日志写入联机 Redo 日志文件中。

2.8.3 即时归档

即时归档(Timely)在主库将 Redo 日志写入联机 Redo 日志文件后，再通过 MAL 系统将 Redo 日志发送到备库。即时归档是读写分离集群的实现基础，与实时归档的主要区别是发送 Redo 日志的时机不同。一个主库可以配置 1~8 个即时备库。

根据备库重演 Redo 日志和响应主库时机的不同，即时归档分为两种模式：事务一致模式和高性能模式。即时归档模式根据配置文件 dmarch.ini 中的 ARCH_WAIT_APPLY 配置项来确定，配置为 1 就是事务一致模式，配置为 0 就是高性能模式，ARCH_WAIT_APPLY 缺省值是 1。

事务一致模式: 主库事务 commit 触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志要在重演完成后再响应主库，主库才能响应用户 commit 成功。事务一致模式下，同一个事务的 SELECT 语句不管是在主库执行，还是在备库执行，查询结果都满足Read Commit 隔离级要求。

高性能模式: 与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应主库再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时(一般情况下延迟时间非常短暂，用户几乎感觉不到)，不能严格保证事务一致性。

事务一致模式，主备库之间严格维护事务一致性，但主库要等备库 Redo 日志重演完成后，再响应用户的 commit 请求，事务 commit 时间会变长，存在一定的性能损失。高性能模式则通过牺牲事务一致性，来获得更高的性能和提升系统的吞吐量。用户应该根据实际情况，选择合适的即时归档模式。

2.8.4 异步归档

异步归档(Async)，由主、备库上配置的定时器触发，根据异步备库的 CUR_LSN 信息，扫描本地归档目录获取 Redo 日志，并通过 MAL 系统将 Redo 日志发送到异步备库。

异步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。

每个 Primary 或 Standby 模式的数据库，最多可以配置 8 个异步备库，Normal 模式下配置的异步备库会被自动失效。

异步备库可以级联配置，异步备库本身也可以作为源库配置异步备库。理论上守护系统中可配置的异步备库的总数目只受 MAL 系统最大节点数(2048)的限制。

2.8.5 归档状态

本地归档、实时归档和即时归档均包含两种状态：Valid 和 Invalid。异步归档只有一种归档状态：Valid。

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

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

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

主备库启动后，主库->所有备库的归档默认是 Valid 状态，守护进程 Open 主库前，将主库->所有备库的归档状态修改为 Invalid 状态。

备库故障恢复，同步主库数据完成后，守护进程先将主库修改为 Suspend 状态，并将主库->备库的归档状态从 Invalid 修改为 Valid。当守护进程再次 Open 主库后，主备库数据重新恢复为一致状态。

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

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

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

实时归档、即时归档只对 Primary 模式的主库有效，备库上配置的实时归档、 即时归档状态没有实际意义，始终保持 Valid 状态。

2.9 MAL 系统

MAL 系统是基于 TCP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。

DM 通过 MAL 系统实现 Redo 日志传输，以及其他一些实例间的消息通讯。

2.10 OGUID

数据守护唯一标识码，配置数据守护时，需要由用户指定 OGUID 值。其中数据库的OGUID 在 MOUNT 状态下由系统函数 SP_SET_OGUID 设置，守护进程和监视器的 OGUID 值在配置文件中设定。

同一守护进程组中的所有数据库、守护进程和监视器，都必须配置相同的 OGUID 值，取值范围为 0~2147483647。

OGUID 的查询方式：

select oguid from v$instance;

2.11 守护进程组

配置了相同 OGUID 的两个或多个守护进程，构成一个守护进程组。为方便管理，对每个守护进程组进行命名，守护进程组中的所有守护进程和监视器，必须配置相同的组名。

2.12 组分裂

同一守护进程组中，不同数据库实例的数据出现不一致，并且无法通过重演 Redo 日志， 重新同步数据的情况，我们称为组分裂。

即时归档中，主库在将 Redo 日志写入本地联机 Redo 日志文件之后，发送 Redo 日志到备库之前出现故障，导致主备库数据不一致，为了继续提供服务，执行备库强制接管。 此时，当故障主库重启后，就会引发组分裂。

故障备库重新完成数据同步之前，主库硬件故障，并且长时间无法恢复；在用户接受丢失部分数据情况下，为了尽快恢复数据库服务，执行备库强制接管，将备库切换为主库。 此时，如果故障主库重启，也会造成组分裂。

检测到组分裂后，守护进程会修改控制文件为分裂状态，被分裂出去的数据库需要通过备份还原等技术手段重新恢复，或者按照分裂库修复步骤重新将数据恢复到一致状态。

2.13 脑裂

脑裂是同一个守护进程组中，同时出现两个或者多个活动主库，并且这些主库都接收用户请求，提供完整数据库服务。一旦发生脑裂，将无法保证数据一致性，对数据安全造成严重后果。

DM 数据守护系统为预防脑裂做了大量工作，例如故障自动切换模式数据守护，必须配置确认监视器。确认监视器启动故障切换之前，会进行严格的条件检查，避免脑裂发生。守护进程一旦检测到脑裂发生，会马上强制退出主库，等待用户干预，避免数据差异进一步扩大。

设置 dm.ini 参数 ALTER_MODE_STATUS=0，限制用户进行直接通过 SQL 修改数据库模式和状态。

提供稳定、可靠的网络环境。

配置自动切换数据守护时，将确认监视器部署在独立的第三方机器上，不要与某一个数据库实例部署在一起，避免由于网络问题触发自动故障切换，导致脑裂发生。

通过人工干预，将备库切换为主库之前，一定要确认主库已经发生故障，避免主库活动情况下，备库强制接管，人为造成脑裂。

3 DW中术语定义

数据守护系统包含主库、备库、守护进程、监视器等诸多部件，在主备库切换、故障处理等场景下，仅以主库或者备库这些称谓，已经无法准确描述对应部件。为了更加清晰的描述数据守护系统，特别定义以下术语。

术语

含义

实时主备

配置实时归档的主备系统

MPP 主备

配置实时归档的 MPP 集群主备系统

读写分离集群

配置即时归档的主备系统

实时主库[实例名]

实时主备系统中 Primary 模式的库

实时备库[实例名]

实时主备系统中 Standby 模式的库

MPP 主库[实例名]

MPP 主备系统中 Primary 模式的库

MPP 备库[实例名]

MPP 主备系统中 Standby 模式的库

即时主库[实例名]

读写分离主备系统中 Primary 模式的库

即时备库[实例名]

读写分离主备系统中 Standby 模式的库

异步备库[实例名]

异步归档目标库，Standby 模式

异步源库[实例名]

异步归档源库，Primary/Standby 模式都可

故障主库[实例名]

发生故障的 Primary 模式实例

故障备库[实例名]

发生故障的 Standby 模式实例

数据一致备库[实例名]

主库到当前备库归档处于有效状态，备库与主库数据保持一致

可恢复备库[实例名]

主库到当前备库归档处于失效状态，备库与主库数据存在差异，但主库归档日志涵盖备库缺失的数据

分裂库[实例名]

与主库数据不一致，且无法通过重做归档日志将数据恢复到一致状态的库

守护进程组[组名]

配置了相同 OGUID 的两个或多个守护进程，构成一个守护进程组

监视器

基于监视器接口实现的命令行工具，用于监控、管理数据守护系统

确认监视器

运行在确认模式下的监视器

网络故障

指主备库之间网络断开，消息无法传递

网络异常

指主备库之间网络未断开，消息可以传递，但出现速度变慢等情形

备库故障

指备库出现软、硬件故障，导致数据库实例关闭

备库异常

指备库的数据库实例正常，但响应速度出现异常

配置数据守护时，数据库实例名不建议配置为 Primary/Standby，守护进程组名不建议配置成和实例名相同，避免在描述对象时产生歧义。