DM数据库主备守护集群原理

本文章根据概述、术语解释、LSN简介、数据库状态等方面，介绍了DM数据库DW集群的原理。

一、概述

DM 数据守护（Data Watch）是一种集成化的高可用、高性能数据库解决方案，是数据库异地容灾的首选方案。通过部署 DM 数据守护，可以在硬件故障（如磁盘损坏）、自然灾害（地震、火灾）等极端情况下，避免数据损坏、丢失，保障数据安全，并且可以快速恢复数据库服务，满足用户不间断提供数据库服务的要求。

二、实现原理

DM数据守护的实现原理：

将主库产生的Redo日志传输到备库，备库接收并重新应用Redo日志，从而实现备库与主库的数据同步

DM数据守护的核心思想：监控数据库状态，获取主备库数据同步状态，为Redo日志传输与重演过程中出现的各种异常情况提供一系列解决方案

三、集群架构图

DM数据守护系统结构参考图如下所示:由主库、备库、Redo日志、Redo日志传输、Redo日志重演、守护进程、监视器组成

四、术语解释

  4.1 主库

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

  4.2 备库

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

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

  4.3 Redo日志

Redo 日志记录物理数据页内容变动情况，在数据库系统故障重启时，利用 Redo 日志可以把数据恢复到故障前的状态。

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

  4.4 Redo日志传输

主备库之间Redo日志传输，以日志包RLOG_PKG为单位，主库通过MAL系统发送Redo日志到备库

  4.5 Redo日志重演

备库收到出库发送的Redo日志后，在数据页上，重新修改数据的过程，重演服务严格按照日志产生先后顺序，解析日志修改对应的物理数据页，重演过程备库生成自身的Redo日志写入联机日志文件。

  4.6 守护进程

守护进程是数据守护系统的核心工具，监控数据库实例的运行状态和主备库数据库同步情况。是各种消息的中转站，守护进程会接收数据库实例、其他守护进程、监视器发送的各种消息

注意：守护进程必须和被守护的数据库实例部署在同一台机器上

  4.7监视器

用于监控守护系统内守护进程、数据库实例信息，执行用户输入命令、监控实例故障、实现自动切换等

注意：监视器一般配置在数据库实例和守护进程以外的机器上，

五、系统特性

• 完整功能的主库
• 活动的备库
• 多重数据保护
• 高可用性
• 多种守护模式
• 多种守护类型
• 故障自动重连
• 故障库自动重加入
• 历史数据自动同步
• 自动负载均衡
• 滚动升级
• 灵活的搭建方式
• 完备的监控工具
• 完善的监控接口
• 丰富的守护命令
• 支持DMDSC守护

六、数据库模式

Normal模式：操作 没有限制，正常生成本地归档，不发送实时归档、即时归档和异步归档

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

Standby模式：可执行数据库联机备份、查询等只读数据库操作，正常生成本地归档，正常发送异步归档Redo日志，但实时归档、即时归档均强制失效

切换数据库模式：

ALTER DATABASE PRIMARY;  --切换为primary

ALTER DATABASE STANDBY; --切换为STandby

ALTER DATABASE NORMAL；--切换为Normal模式

七、数据库状态

（1）Startup   --系统刚启动时设置为Startup状态

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

（3）Open状态  --数据库处于正常提供服务状态，但不能进行归档配置等操作

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

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

//**********

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

1. 将系统切换为 Suspend 状态，限制 Redo 日志写入联机 Redo 日志文件；
2. 修改归档状态为 Valid；
3. 重新将数据库切换为 Open 状态，恢复 Redo 日志写入功能；
4. 备库与主库重新进入实时同步状态。***********************//

（6）Shutdown状态  --1. Open 状态与 Mount 状态可以相互切换；2. Open 状态与 Suspend 状态可以相互切换；3. Mount 和 Suspend 状态不能直接转换；4. 其他状态为系统内部状态，用户不能主动干预。

注意：当系统处于Primary/Standby模式时，必须强制加上FORCE子句

ALTER DATABASE OPEN [FORCE];    --加上FORCE改为强制性的

ALTER DATABASE MOUNT;   --将数据库修改为Mount状态

ALTER DATABASE SUSPEND;   --将数据库修改为Suspend状态

八、LSN简介

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

主要包含以下几种类型的LSN：

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

(2)FILE_LSN:是已经写入联机 Redo 日志文件的日志包的最大 LSN 值。每次将 Redo 日志包 RLOG_PKG 写入联机 Redo 日志文件后，都要修改 FILE_LSN 值。

(3)FLUSH_LSN:是已经发起日志刷盘请求，但还没有真正写入联机 Redo 日志文件的最大 LSN 值。
(4)CKPT_LSN:是检查点 LSN，所有 LSN <= CKPT_LSN 的物理事务修改的数据页，都已经从 Buffer 缓冲区写入磁盘，CKPT_LSN 由检查点线程负责调整。

(5)APPLY_LSN:是备库已写入联机 Redo 日志文件的日志包的原始最大 LSN 值，此 LSN 取自主库对应的原始日志包中的最大 LSN 值。如果主库是 DMDSC 集群，备库分别为主库每一个节点维护一个 APPLY_LSN。

(6)RPKG_LSN:是备库重演 LSN，表示备库已经重演完成的最大 LSN

注意：是DSC集群情况下，数据守护页定义了如下的LSN：

九、配置文件

• 数据库配置文件 dm.ini          --存放目录无限制
• 数据库控制文件 dm.ctl        
• MAL 配置文件 dmmal.ini     --所有站点dmmal.ini都需要保证严格一致
• Redo 日志归档配置文件 dmarch.ini  --在同一个守护进程组内，所有GLOBAL守护类型的实例dmarch.ini需要配置相同的arch_type
• 守护进程配置文件 dmwatcher.ini  --在用一个守护进程内，所有GLOABL守护类型的实例dmwatcher.ini配置相同的DW_TYPE、DW_MODE、DW_ERROR_TIME
• 监视器配置文件 dmmonitor.ini      
• 定时器配置文件 dmtimer.ini
• MPP 控制文件 dmmpp.ctl 等等

十、数据守护使用

10.1 正常运行状态

守护系统正常运行时，同一个守护进程组中，只有一个主库，其他的都是备库。

主库处于 Open 状态，主库守护进程也处于 Open 状态，本地没有守护进程控制文件，其内存值是 Valid 有效状态。

所有备库也处于 Open 状态，所有备库守护进程处于 Open 状态，本地没有守护进程控制文件，其内存值是 Valid 有效状态。

主库到所有备库的归档也都处于 Valid 有效状态。

MPP 主备系统中，所有主库的 dmmpp.ctl 都处于一致状态。

10.2 数据守护启动

（1）Normal模式下DM数据库默认以Open状态启动，可以利用前台方式+MOUNT方式启动到Mount状态。

（2）Primary/Standby模式的库启动后自动切换为Mount状态,因此数据守护系统启动时，所有实例为Mount状态

对于Local守护类型的守护进程：直接Open数据库实例，并修改守护进程状态为Open

对于Global守护类型的守护进程：对备库，如果可远程加入任意一个库，则允许将其Open，对主库，如果远程所有库都可加入自己，则允许将其Open

10.3 强制Open数据库

注意：强制主库Open容易产生守护进程组分裂

如果数据库 A 是 Standby 模式，强制 Open 的执行流程如下：

1. 通知 A 的守护进程切换为 Open Force 状态
2. 通知 A 执行 Open 操作
3. 通知守护进程切换 Open 状态

如果数据库 A 是 Primary 模式，强制 Open 的执行流程如下：

1. 通知 A 的守护进程切换为 Open Force 状态
2. 修改 A 到所有归档目标的实时归档/即时归档状态为无效
3. 通知 A 执行 Open 操作
4. 通知守护进程切换 Open 状态

  10.4 关闭数据守护系统

通过监视器执行stop group命令关闭数据守护系统：

1. 通知守护进程切换为 Shutdown 状态
2. 通知主库退出
3. 通知其他备库退出

手动方式关闭数据守护系统：严格顺序

1. 如果启动了确认监视器，先关闭确认监视器（防止自动接管）
2. 关闭备库守护进程（防止重启实例）
3. 关闭主库守护进程（防止重启实例）
4. Shutdown 主库
5. Shutdown 备库

更多有关达梦守护集群技术知识请移步达梦数据库官方地址： https://eco.dameng.com