一 简介

DM 数据守护（DM Data Watch）的实现原理非常简单：将主库（生产库）产生的 Redo 日志传输到备库，备库接收并重新应用 Redo 日志，从而实现备库与主库的数据同步。DM 数据守护的核心思想是监控数据库状态，获取主、备库数据同步情况，为 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_PKG 为单位，主库通过 MAL 系统发送 Redo 日志到备库。各种不同数据守护类型的区别，就在于主库日志包 RLOG_PKG 的发送时机，以及备库收到 Redo 日志后的处理策略。

Redo 日志重演

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

守护进程

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

监视器

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

二 归档模式

实时归档

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

实时归档的执行流程是，主库在 Redo 日志（RLOG_PKG）写入联机日志文件前，将 Redo 日志发送到备库，备库收到 Redo 日志（RLOG_PKG）后标记为 KEEP_RLOG_PKG，将原 KEEP_RLOG_PKG 加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。主库收到备库的响应消息，确认备库已经收到 Redo 日志后，再将 Redo 日志写入联机日志文件中。

另外，实时归档也可以支持读写分离集群，实时归档也分为两种模式：事务一致模式和高性能模式，可以通过 dmarch.ini 中的 ARCH_WAIT_APPLY 或 WAIT_APPLY 配置项来设置实时归档的模式。这两种模式的具体含义和下一小节 2.2.11.5 中的说明完全相同，区别仅在于配置为实时归档时，dmarch.ini 中的 ARCH_WAIT_APPLY 配置项默认值为 0，即采用高性能模式

即时归档

即时归档（Timely）在主库将 Redo 日志写入联机日志文件后，通过 MAL 系统将 Redo 日志发送到备库。即时归档与实时归档的主要区别是 Redo 日志的发送时机不同。一个主库可以配置 1~8 个即时备库。

根据备库重演 Redo 日志和响应主库时机的不同，即时归档分为两种模式：事务一致模式和高性能模式。即时归档模式可以通过 dmarch.ini 中的 ARCH_WAIT_APPLY 或 WAIT_APPLY 配置项来设置。其中，ARCH_WAIT_APPLY 配置项默认值为 1，表示事务一致模式。

• 事务一致模式 主库事务提交触发 Redo 日志刷盘和即时归档，备库收到主库发送的 Redo 日志，并重演完成后再响应主库。主库收到备库响应消息后，再响应用户的提交请求。事务一致模式下，同一个事务的 SELECT 语句无论是在主库执行，还是在备库执行，查询结果都满足 READ
  COMMIT 隔离级要求。
• 高性能模式 与实时归档一样，备库收到主库发送的 Redo 日志后，马上响应主库，再启动日志重演。高性能模式下，备库与主库的数据同步存在一定延时（一般情况下延迟时间非常短暂，用户几乎感觉不到），不能严格保证事务一致性。

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

异步归档

异步归档（Async）由主、备库上配置的定时器触发，根据异步备库的 KEEP LSN 信息，扫描本地归档目录获取 Redo 日志，并通过 MAL 系统将 Redo 日志发送到异步备库。异步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。

每个 Primary 或 Standby 模式的数据库最多可以配置 8 个异步备库，Normal 模式下配置的异步备库会自动失效。异步备库可以级联配置，异步备库本身也可以作为源库配置异步备库

同步归档

同步归档（Sync）在主库归档日志刷盘后，通过 MAL 系统将 Redo 日志发送到备库。同步备库的 Redo 日志重演过程与实时归档等其他类型的归档完全一致。一个主库可以配置 1~8 个同步备库。

同步归档的执行流程是，主库在归档日志刷盘后，将 Redo 日志发送到备库，备库收到 Redo 日志（RLOG_PKG）后将其加入日志重演任务系统，并马上响应主库，不需要等待 Redo 日志重演结束后再响应主库。

OGUID

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

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

OGUID 的查询方式：

SELECT OGUID FROM V$INSTANCE;

1 环境准备

删库（原命令行安装的单实例）

su - dmdba

cd /home/dmdba/dmdbms/bin

./uninstall.sh -i

使用root执行

su - root

/home/dmdba/dmdbms/root_uninstaller.sh

rm -rf /home/dmdba/dmdbms

rm -rf /dmdata/data/*

2.2 VMware 克隆2份。配置IP

主库：

IP1：192.168.157.11

IP2：10.10.10.1

port1：5236

port2：5336

port3：5436

port4：5536

备库：

IP1：192.168.157.11

IP2：10.10.10.1

port1：5236

port2：5336

port3：5436

port4：5536

监视器：

IP1：192.168.157.11

IP2：10.10.10.1

port1：5236

port2：5336

port3：5436

port4：5536

DM数据库搭建

初始化实例

cd /home/dmdba/dmdbms/bin

./dminit path=/dmdata/data extent_size=32 page_size=32 log_size=2048 charset=1 case_sensitive=1 SYSDBA_PWD=Sysdba@123 SYSAUDITOR_PWD=Sysauditor@123 BLANK_PAD_MODE=1 INSTANCE_NAME=DM1

./dminit path=/dmdata/data extent_size=32 page_size=32 log_size=2048 charset=1 case_sensitive=1 SYSDBA_PWD=Sysdba@123 SYSAUDITOR_PWD=Sysauditor@123 BLANK_PAD_MODE=1 INSTANCE_NAME=DM2

dminit path=/dmdata/data extent_size=32 page_size=32 log_size=2048 charset=1 case_sensitive=1 SYSDBA_PWD=Sysdba@123 SYSAUDITOR_PWD=Sysauditor@123 BLANK_PAD_MODE=1 INSTANCE_NAME=DM3

###命令行运行前台启动 ./dmserver /dmdata/data/DAMENG/dm.ini 尝试是否能启动成功，然后用exit退出即可，保持数据库关闭状态。

log参数修改

sqllog.ini

FILE_PATH = /dmdata/sqllog

FILE_NUM = 20/50 #默认5，文件个数依磁盘大小

SWITCH_LIMIT = 128/256 # 建议128m

如果内存>=32G

1.在sqllog.ini文件BUF_TOTAL_SIZE由10240修改为1024000

2.在sqllog.ini文件BUF_SIZE由1024修改为10240

3.在sqllog.ini文件BUF_KEEP_CNT由6修改为20

5 数据主备同步

5.1主库脱机备份

dmrman CTLSTMT="BACKUP DATABASE '/dmdata/data/DAMENG/dm.ini' FULL TO BACKUP_FILE1 BACKUPSET '/dmdata/dmbak/BACKUP_FILE_01'"

5.2 备份文件传输至备库

scp -r /dmdata/dmbak/BACKUP_FILE_01/ dmdba@192.168.157.16:/dmdata/dmbak/BACKUP_FILE_01/

5.3 执行脱机数据库还原与恢复

# 还原

dmrman CTLSTMT="RESTORE DATABASE '/dmdata/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/dmbak/BACKUP_FILE_01'"

# 恢复

dmrman CTLSTMT="RECOVER DATABASE '/dmdata/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/dmbak/BACKUP_FILE_01'"

# 更新 DB_MAGIC

dmrman CTLSTMT="RECOVER DATABASE '/dmdata/DAMENG/dm.ini' UPDATE DB_MAGIC"

配置主库

dm.ini

ALTER_MODE_STATUS = 0

ENABLE_OFFLINE_TS = 2

MAL_INI = 1

ARCH_INI = 1

SVR_LOG = 1

DW_ARCH_SPACE_CHECK = 1

DW_ARCH_HANG_CHECK = 1

REDOS_BUF_SIZE = 10240

REDOS_BUF_NUM= 0

REDOS_MAX_DELAY = 600

REDOS_PARALLEL_NUM = 32

grep -E "DW_ARCH_SPACE_CHECK|DW_ARCH_HANG_CHECK|REDOS_BUF_SIZE|REDOS_BUF_NUM|REDOS_MAX_DELAY|REDOS_PARALLEL_NUM|ALTER_MODE_STATUS|ENABLE_OFFLINE_TS|MAL_INI|ARCH_INI|SVR_LOG" dm.ini

dmmal.ini

配置 MAL 系统，各主备库的 dmmal.ini 配置必须完全一致，MAL_HOST 使用内部网络 IP，MAL_PORT 与 dm.ini 中 PORT_NUM 使用不同的端口值，MAL_DW_PORT 是各实例对应的守护进程之间，以及守护进程和监视器之间的通信端口，配置如下：

/dmdata/data/DAMENG

[dmdba@bingo1 DAMENG]$ vim dmmal.ini

MAL_CHECK_INTERVAL = 60 #MAL 链路检测时间间隔

MAL_CONN_FAIL_INTERVAL = 15 #判定 MAL 链路断开的时间

[MAL_INST1]

MAL_INST_NAME = DM1 #实例名，和 dm.ini 的 INSTANCE_NAME 一致

MAL_HOST = 10.10.10.2 #MAL 系统监听 TCP 连接的 IP 地址(心跳网)

MAL_PORT = 5336 #MAL 系统监听 TCP 连接的端口

MAL_INST_HOST = 192.168.157.11 #实例的对外服务 IP 地址

MAL_INST_PORT = 5236 #实例对外服务端口，和 dm.ini 的 PORT_NUM 一致

MAL_DW_PORT = 5436 #实例对应的守护进程监听 TCP 连接的端口

MAL_INST_DW_PORT = 5536 #实例监听守护进程 TCP 连接的端口

[MAL_INST2]

MAL_INST_NAME = DM2

MAL_HOST = 10.10.10.3

MAL_PORT = 5336

MAL_INST_HOST = 192.168.157.16

MAL_INST_PORT = 5236

MAL_DW_PORT = 5436

MAL_INST_DW_PORT = 5536

dmarch.ini

ARCH_WAIT_APPLY =0

[ARCHIVE_REALTIME1]

ARCH_TYPE = REALTIME #实时归档类型

ARCH_DEST = DM2 #实时归档目标实例名

[ARCHIVE_LOCAL]

ARCH_TYPE = LOCAL #本地归档类型

ARCH_DEST = /dmdata/arch/ #本地归档存放路径

ARCH_FILE_SIZE = 2048 #单个归档大小，单位 MB 512 / 1024

ARCH_SPACE_LIMIT = 102400 #归档上限，单位 MB

dmwatcher.ini

[dmdba@bingo1 DAMENG]$ vim dmarch.ini

[GRP1]

DW_TYPE = GLOBAL #全局守护类型

DW_MODE = AUTO #MANUAL：故障手切 AUTO：故障自切

DW_ERROR_TIME = 60 #远程守护进程故障认定时间

INST_ERROR_TIME = 60 #本地实例故障认定时间

INST_RECOVER_TIME = 60 #主库守护进程启动恢复的间隔时间

INST_OGUID = 150906 #守护系统唯一 OGUID 值

INST_INI = /dmdata/data/DAMENG/dm.ini

INST_AUTO_RESTART = 1 #打开实例的自动启动功能

INST_STARTUP_CMD = /home/dmdba/dmdbms/bin/DmServiceDM1 restart

INST_SERVICE_IP_CHECK=1

RLOG_SEND_THRESHOLD =100

RLOG_APPLY_THRESHOLD =100

DW_RECONNECT=2

DW_SUSPEND_CHECK=1

配置备库（对比主库需要修改）

dm.ini

INSTANCE_NAME = DM2

7.2 dmarch.ini

ARCH_DEST = DM1

7.3 dmwatcher.ini

/home/dmdba/dmdbms/bin/DmServiceDM2 restart

设置oguid

主库、备库启动到mount，必须前台启动

dmserver /dmdata/data/DAMENG/dm.ini mount

8.2 主库新会话disql登录

[dmdba@bingo1 ~]$ disql sysdba/'"Sysdba@123"'

服务器[LOCALHOST:5236]:处于普通配置状态

登录使用时间 : 21.147(ms)

disql V8

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

DMSQL 过程已成功完成

已用时间: 62.379(毫秒). 执行号:1.

SQL> sp_set_oguid(150906);

DMSQL 过程已成功完成

已用时间: 37.692(毫秒). 执行号:2.

SQL> alter database primary;

操作已执行

已用时间: 37.199(毫秒). 执行号:0.

SQL> SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

DMSQL 过程已成功完成

已用时间: 30.605(毫秒). 执行号:3.

8.3 备库新会话disql登录

[dmdba@bingo1 ~]$ disql sysdba/'"Sysdba@123"'

SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);

sp_set_oguid(150906);

alter database standby;

SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);

监视器安装

9.1 准备工作

./DMInstall.bin -i

dminit path=/dmdata/data extent_size=32 page_size=32 log_size=2048 charset=1 case_sensitive=1 SYSDBA_PWD=Sysdba@123 SYSAUDITOR_PWD=Sysauditor@123 BLANK_PAD_MODE=1 INSTANCE_NAME=DM3

9.2 配置dmmonitor.ini 文件（确认监视器模式）

由于主库和实时备库的守护进程配置为自动切换模式，因此这里必须配置确认监视器。和普通监视器相比，确认监视器除了相同的命令支持外，在主库发生故障时，能够自动通知实时备库接管为新的主库，具有自动故障处理的功能。

[dmdba@bingo3 DAMENG]$ cat dmmonitor.ini

MON_DW_CONFIRM = 1 ##确认监视器模式

MON_LOG_PATH = /dmdata/log ##监视器日志文件存放路径

MON_LOG_INTERVAL = 60 ##每隔60s定时记录系统信息到日志文件

MON_LOG_FILE_SIZE = 32 ##每个日志文件最大32M

MON_LOG_SPACE_LIMIT = o

[GRP1]

MON_INST_OGUID = 150906 ##组GRP1的唯一OGUID值

##以下配置为监视器到组GRP1的守护进程的连接信息，以“IP:PORT”的形式配置

##IP对应dmmal.ini中的MAL_HOST，PORT对应dmmal.ini中的 MAL_DW_PORT

MON_DW_IP = 10.10.10.2:5436

MON_DW_IP = 10.10.10.3:5436

复制一份监视器配置，MON_DW_CONFIRM = 0，非确认模式，用于监控。

cp dmmonitor.ini dmmonitor_0.ini

注册服务

主库：（root）

cd /home/dmdba/dmdbms/script/root/

./dm_service_installer.sh -t dmserver -m mount -dm_ini /dmdata/data/DAMENG/dm.ini -p DM1

./dm_service_installer.sh -t dmwatcher -p DMWATCHER1 -dm_ini /dmdata/data/DAMENG/dm.ini -watcher_ini /dmdata/data/DAMENG/dmwatcher.ini

备库：（root）

cd /home/dmdba/dmdbms/script/root/

./dm_service_installer.sh -t dmserver -m mount -dm_ini /dmdata/data/DAMENG/dm.ini -p DM2

./dm_service_installer.sh -t dmwatcher -p DMWATCHER2 -dm_ini /dmdata/data/DAMENG/dm.ini -watcher_ini /dmdata/data/DAMENG/dmwatcher.ini

监视器：(root)

cd /home/dmdba/dmdbms/script/root/

./dm_service_installer.sh -t dmmonitor -p DMMONITOR -monitor_ini /dmdata/data/DAMENG/dmmonitor.ini

cd /home/dmdba/dmdbms/bin

启停服务

cd /home/dmdba/dmdbms/bin

启停顺序

启动主备的操作顺序(主备主备)

(1) 启主实例dmserver ./DmServiceDM1 start

(2) 启备实例dmserver ./DmServiceDM2 start

(3) 启主守护进程 dmwatcher ./DmWatcherServiceDMWATCHER1 start

(4) 启备守护进程 dmwatcher ./DmWatcherServiceDMWATCHER2 start

(5) 启监视器DmMonitorServiceDMMONITOR start

停止主备的操作顺序(备主主备)

(1) 关监视器：DmMonitorServiceDMMONITOR stop

(2) 停备机dmwatcher ./DmWatcherServiceDMWATCHER2 stop

(3) 停主机dmwatcher ./DmWatcherServiceDMWATCHER1stop

(4) 停主机dmserver ./DmServiceDM1 stop

(5) 停备机dmserver ./DmServiceDM2 stop

守护进程状态

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

• Startup 守护进程启动状态，需要根据远程守护进程发送的状态信息，结合本地数据库的初始模式、状态和数据同步情况，确定本地数据库的启动模式和状态后，进入 Open 状态。
• Open 守护进程正常工作，监控数据库，并定时发送数据库的状态信息，接收其他守护进程发送的信息，接收监视器发送的用户请求。
• Shutdown 守护进程停止监控数据库状态，不再提供主备库切换、主备库故障处理和备库故障恢复等功能。
• Switchover 主备库正常情况下，手动主备切换过程中设置为 Switchover 状态。
• Failover 远程备库故障后，本地主库执行故障处理时，守护进程设置为 Failover 状态。
• Recovery 故障恢复同步历史数据过程中设置为 Recovery 状态。
• Confirm 通过监视器确认远程主（备）库是否活动的过程中，守护进程设置为 Confirm 状态。
• Takeover 主库确认故障后，备库手工接管或监视器通知自动接管过程中，守护进程设置为 Takeover 状态。
• Open force 借助监视器命令强制 Open 主库或备库实例时，守护进程设置为 Open force 状态。
• Error 超过一段时间（DW_ERROR_TIME）没有接收到远程守护进程消息，本地守护进程或监视器认定远程守护进程故障，修改远程守护进程为 Error 状态。
• Login check 监视器执行登录命令时，守护进程所处的状态。
• Mppctl update 修改主库 MPP 控制文件（dmmpp.ctl）时，守护进程所处的状态，只在 MPP 主备系统出现。
• Change arch 监视器执行 set arch invalid 命令时守护进程所处的状态。
• Standby check 主库守护进程监控到备库异常后，切换到此状态下通知主库修改此备库归档无效。
• Clear send info 清理主库上的归档发送信息时，守护进程所处的状态。
• Clear rapply stat 清理备库上的重演信息时，守护进程所处的状态。
• Unify ep 统一 DMDSC 集群各节点实例状态，或者各实例状态已经一致时，守护进程在 Startup 或 Open 状态下通知实例执行相关操作，都进入 Unify_ep 状态执行。
• Css process 监视器发起的对 DMDSC 集群的部分命令，比如启动、关闭、强杀 DMDSC 库，或者打开、关闭节点实例的自动拉起功能等命令，需要借助 dmcss 执行时，守护进程会切换到此状态下。

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

监视器命令

监视器手动切主备

dmmonitor /dmdata/data/DAMENG/dmmonitor_0.ini

将指定组中的指定备库切换为新的主库，将当前的主库切换为新的备库，此命令要求执行切换的主备库都是正常 Open 状态。执行此命令需要先登录监视器。

只有一组的情况下，可以不指定 group_name，组中只有一个备库的情况下，可以不指定 db_name，如果 group_name 和 db_name 同时指定，则需要用“.”符合分隔。

可以先执行 choose switchover 命令选出组中能够切换为主库的备库列表，选择其中一个备库切换为主库即可。可以指定 choose switchover 命令执行结果中备库对应的序号来选择备库。例如 switchover 1 表示将 choose switchover 命令执行结果中的第一个备库切换为主库。

14集群测试

14.1主库服务器关机

主库服务器直接关机，查看主备环境变化。多久发现异常？多久备库变为主库？备库变成主库有哪些过程？源主库起来了自动加入集群吗？数据会自动同步吗？

在监视器服务器，进入monitor 进行监控：

dmmonitor /dmdata/data/DAMENG/dmmonitor_0.ini

14.2大量数据插入，看备库延迟

查看日志应用情况

select TASK_NUM,TASK_MEM_USED/1024/1024 from v$rapply_sys;