DM 数据守护(Data Watch)是一种集成化的高可用、高性能数据库解决方案,数据守护可以配置成实时主备集群、读写分离集群,基本不受数据规模的影响,只需数秒时间就可以将备库切换为主库对外提供数据库服务。
DM 数据守护的实现原理非常简单:将主库(生产库)产生的 Redo日志传输到备库,备库接收并重新应用 Redo 日志,从而实现备库与主库的数据同步。DM数据守护的核心思想是监控数据库状态,获取主、备库数据同步情况,为 Redo 日志传输与重演过程中出现的各种异常情况提供一系列的解决方案。
达梦数据守护集群和读写分离集群搭建过程基本一致,区别在于:
数据守护集群=实时或即时归档+ARCH_WAIT_APPLY=0(高性能)
读写分离集群:实时或即时归档+ARCH_WAIT_APPLY=1(强一致性)+客户端读写分离+百分比配置。
生产建议使用数据守护集群,使用实时归档方式部署
配置环境说明
主机类型 | IP | 实例名 | 操作系统 |
主库 | 10.10.10.7(外网) | TEST1 | Kylin Linux Advanced Server V10 |
100.0.0.7(内网) | |||
备库 | 10.10.10.8(外网) | TEST2 | Kylin Linux Advanced Server V10 |
100.0.0.8(内网) | |||
监视器 | 10.10.10.9(外网) |
| Kylin Linux Advanced Server V10 |
100.0.0.9(内网) |
端口规划:
名称 | 节点1 | 节点2 | 参数说明 |
MAL_INST_NAME | TEST1 | TEST2 | 数据库实例名,和 dm.ini 中的INSTANCE_NAME 一致 |
MAL_INST_HOST | 10.10.10.7 | 10.10.10.8 | 实例的对外服务 IP 地址 |
MAL_HOST | 100.0.0.7 | 100.0.0.8 | MAL 系统监听 TCP 连接的 IP 地址 |
MAL_INST_PORT | 5236 | 5236 | 实例的对外服·务端口,和 dm.ini 中的 PORT_NUM 一致 |
MAL_INST_DW_PORT | 5237 | 5237 | 实例监听守护进程TCP连接的端口 |
MAL_PORT | 5238 | 5238 | MAL 系统监听 TCP 连接的端口 |
MAL_DW_PORT | 5239 | 5239 | 实例对应的守护进程监听 TCP 连接的端口 |
创建数据库实例
dminit PATH=/dm8/dmdbms/data DB_NAME=TEST INSTANCE_NAME=TEST1 PORT_NUM=5236 /dm8/script/root/dm_service_installer.sh -t dmserver -dm_ini /dm8/dmdbms/data/TEST/dm.ini -p TEST |
启动数据库
dmserver /dm8/dmdbms/data/TEST/dm.ini |
主库开启归档
|
备份数据库后退出数据库
|
修改dm.ini参数
|
修改dmarch.ini参数 ,两个节点都配置,ARCH_DEST分写写对方的实例。比如当前实例 TEST1 是主库,则ARCH_DEST 配置为 TEST2。
|
配置 dmmal.ini文件,2节点配置配置一样。具体如下:
|
配置 dmwatcher.ini ,2节点都配置。守护进程使用AUTO,自动切换模式。
|
注册主库守护进程
|
复制主库所有文件,传输到2节点中,2节点不需要再创建数据库实例
|
恢复备份文件
|
修改dm.ini文件中的实例
|
修改dmarch.ini参数,将实时归档路径改为1节点
|
注册数据库和守护进程
|
在监控节点的/dm/dmdbms/data/TEST/目录下创建并修改 dmmonitor.ini 配置确认监视器,其中 MON_DW_IP 中的 IP 和 PORT 和dmmal.ini 中的 MAL_HOST 和 MAL_DW_PORT 配置项保持一致。
|
注册监视器
|
在配置完确认监视器后,还需要配置一个非确认监视器,来手工调用
|
将两个数据库启动到mount模式
|
设置 OGUID,在主备库分别执行:
|
修改数据库模式
主库:
alter database primary; |
备库:
alter database standby; |
修改完成后,停止数据库
|
启动两台数据库,此时数据库应该是mount状态
|
检查数据库状态
|
启动守护服务
|
启动监视器
|
进入监视器
|
查询命令
|
命令 | 含义 |
list | 查看守护进程的配置信息 |
show global info | 查看所有实例组的信息 |
tip | 查看系统当前运行状态 |
login | 登录监视器 |
logout | 退出登录 |
choose switchoverGRP1 | 主机正常:查看可切换为主机的实例列表 |
switchoverGRP1.实例名 | 主机正常:使用指定组的指定实例,切换为主机 |
choose takeoverGRP1 | 主机故障:查看可切换为主机的实例列表 |
takeoverGRP1.实例名 | 主机故障:使用指定组的指定实例,切换为主机 |
choose takeover force GRP1 | 强制切换:查看可切换为主机的实例列表 |
takeover force GRP1.实例名 | 强制切换:使用指定组的指定实例,切换为主机 |
服务名配置
|
集群功能测试分为数据同步测试、自动同步测试和手动同步测试,测试集群为实时同步集群。
检查集群主从状态,可以看到目前实例test2为主库
1
、连接主库
创建测试表
2
、连接备库,检查表是否生成
3
、主库删除t1表
4、备库检查表行数,报表不存在。
上述测试证实集群同步正常。
自动切换不需要人工干预,可以直接模拟主从库故障,并从非确认监视器中检查数据库状态。
切换前信息检查,实例2为主库
模拟主库故障,停止主库网络服务
非确认监视器输出信息,主库网络服务中断后,监视器takeover ,将备库切换为主库
此时检查数据库状态,实例1已经成为主库,实例2状态为error
实例2启动网络服务
从非确认监视器中可以看到,实例2的状态转变。逐渐加入到集群中。
检查集群状态
手动切换分为守护进程配置文件dmwatcher.ini
中DW_MODE 参数为 MANUAL,或者通过非确认监视器中切换,本次使用非确认监视器中的切换命令。
Auto
模式,switch切换测试
Choose Switchover 命令选择可切换备库的条件如下:
1. 主库守护进程是 Open 状态
2. 备库守护进程是 Open 状态
3. 主、备库的 OPEN 记录项内容相同,并且守护进程控制文件是 Valid 有效状态(内
存值)
4. 主库正常运行
5. 备库正常运行
6. 主库处于 Open 状态
7. 备库处于 Open 状态
8. 主库到备库的归档是 Valid 状态
切换前检查,守护文件中配置为自动切换
确认test1为主库
正常切换,确认是否有备库可以切换
执行切换前,需要先登录
登录
执行切换命令
切换成功
manual
模式,switch切换测试
检查集群守护模式
TEST2为主库
检查组内备库
正常切换
切换成功,TEST1变为主库。
manual
模式,takeover切换测试
故障手动切换模式下,可以先在监视器上执行 Choose Takeover 命令,选出守护进程
组中可以接管的备库。
为了避免备库接管后,造成守护进程组分裂,执行 Takeover 必须满足下列条件:
1. 主库是 Primary 模式、Open 状态时,发生故障
2. 主库守护进程故障,故障前是 Open/Recovery 状态;或者主库守护进程正常
3. 主库故障前到接管备库的归档状态为 Valid
4. 接管备库是 Standby 模式、Open 状态
5. 接管备库的守护进程控制文件状态为 Valid(内存值)
6. 故障主库和接管备库的 Open 记录项内容相同
kill 主库进程
监视器查看,主库状态正常,由于是手动模式,备库并没有接管。
Takeover 检查
Takeover 故障接管
实例2接管成功
启动备库
备库启动成功后,会自动加入集群变为备库。
manual
模式,takeover force 切换测试
如果执行 Takeover 命令不成功,但主库可能由于硬件损坏等原因无法马上恢复,为了及时恢复数据库服务,DM 提供了 Takeover Force 命令,强制将备库切换为主库。但需要由用户确认主库故障前,主库与接管备库的数据是一致的(主库到备库的归档是 Valid 状态),避免引发守护进程组分裂。
检查实例状态,TEST2为主库
检查组内是否存在主库
KILL 主库进程
监视器中,数据库状态,TEST2为ERROR
强制备库接管,
检查集群状态,主库已经变为TEST1
关闭步骤
1) 如果启动了确认监视器,先关闭确认监视器(防止自动接管)
2) 关闭主库守护进程(防止重启实例)
3) 关闭备库守护进程(防止重启实例)
启动步骤
1) 启动备库守护进程(会自动拉起实例)
2) 启动主库守护进程(会自动拉起实例)
3) 启动监视器
配置环境说明
主机类型 | IP | 实例名 | 操作系统 |
主库 | 10.10.10.7(外网) | TEST1 | Kylin Linux Advanced Server V10 |
100.0.0.7(内网) | |||
备库 | 10.10.10.8(外网) | TEST2 | Kylin Linux Advanced Server V10 |
100.0.0.8(内网) | |||
监视器 | 10.10.10.9(外网) |
| Kylin Linux Advanced Server V10 |
100.0.0.9(内网) |
端口规划:
名称 | 节点1 | 节点2 | 参数说明 |
MAL_INST_NAME | TEST1 | TEST2 | 数据库实例名,和 dm.ini 中的INSTANCE_NAME 一致 |
MAL_INST_HOST | 10.10.10.7 | 10.10.10.8 | 实例的对外服务 IP 地址 |
MAL_HOST | 100.0.0.7 | 100.0.0.8 | MAL 系统监听 TCP 连接的 IP 地址 |
MAL_INST_PORT | 5236 | 5236 | 实例的对外服·务端口,和 dm.ini 中的 PORT_NUM 一致 |
MAL_INST_DW_PORT | 5237 | 5237 | 实例监听守护进程TCP连接的端口 |
MAL_PORT | 5238 | 5238 | MAL 系统监听 TCP 连接的端口 |
MAL_DW_PORT | 5239 | 5239 | 实例对应的守护进程监听 TCP 连接的端口 |
在数据守护集群的基础上,通过修改ARCH_WAIT_APPLY参数和客户端配置文件来实现读写分离。
在dmarch.ini配置文件中,将ARCH_WAIT_APPLY参数修改为1,该参数值为要求主备强一致性,在生产环境中,对性能会有一定影响。
客户端配置文件dm_svc.conf中的配置信息,配置文件中:
RW_SEPARATE=(1)代表开启读写分离,
RW_PERCENT=(50)代表读写分离百分比。
cat /etc/dm_svc.conf TIME_ZONE=(480) LANGUAGE=(cn) DMRW=(10.10.10.7:5236,10.10.10.8:5236) ##服务配置 [DMRW] RW_SEPARATE=(1) RW_PERCENT=(50) SWITCH_TIMES=(60) SWITCH_INTERVAL=(1000) |
检查客户端配置
检查主备库,目前TEST2为主库,
通过服务名连接到数据库,查询实例名,目前连接的是备库
在一个未提交的事务中,先执行DML操作,在执行查询操作,发现是在主库操作。
提交后,再执行查询操作,发现又回到了备库。
官方文档中,对于读写分离的分发流程解释如下:
读写分离集群语句分发流程:
1. 接口收到用户的请求。
2. 接口优先将 SQL 发送到备库执行。
3. 备库执行并返回执行结果。如果接口收到的是备库执行成功消息,则转到第 6 步,
如果接口收到的是备库执行失败消息,则转到第 4 步。
4. 重新将执行失败的 SQL 发送到主库执行。只要第 3 步中的 SQL 在备库执行失败,
则同一个事务后续的所有操作(包括只读操作)都会直接发送到主库执行。
5. 主库执行并返回执行结果给接口。一旦主库上执行的写事务提交,则下次继续从第
1 步开始执行。
6. 接口响应用户并将执行结果返回给用户。