达梦8 DMDSC集群高可用验证手册

1. 1. 阅读对象
2. 架构管理人员、架构设计人员
3. 项目需求分析、设计开发人员
4. 数据架构师、DBA
5. 开发人员

1. 1. 定义、缩写和分类

DM：DM8为达梦公司自研数据库。

DMDSC：DM Data Shared CLuster，简称DMDSC。共享存储数据库集群。手册中个别章节DMDSC专指DM DB。

DMCSS：DM集群同步服务（DM Cluster Synchronization Services）的简称，是DMDSC集群应用的基础，使用DMDSC集群或者DMASM集群都必须要配置DMCSS。

DMCSSM：是DM集群监视器（DM Cluster Synchronization Services Monitor）的简称。DMCSSM与DMCSS相互通信，获取并监控整个集群系统的状态信息。DMCSSM还提供了一系列的命令来管理、维护集群。一般建议将监视器放在独立的第三方机器上。

DMASM：达梦专用的分布式文件系统。支持多个节点同时访问、修改数据文件，并减少直接使用裸设备存在的诸多限制。它不是一个通用的文件系统，只能通过dmasmapi接口访问。

DCR：DM集群注册表（DM Clusterware Registry）的简称，用于存储、维护集群配置的详细信息，整个集群环境共享DCR配置信息。它必须存储在集群中所有节点都可以访问到的共享存储中，并且只支持裸设备。在一个集群环境中只能配置一个DCR磁盘。

Voting：表决磁盘（Voting Disk）记录了集群成员信息，DM集群通过Voting Disk进行心跳检测，确定集群中节点的状态，判断节点是否出现故障。它必须存储在集群中所有节点都可以访问到的共享存储中，并且只支持裸设备。在一个集群环境中只能配置一个表决磁盘。

MAL链路：MAL系统是达梦数据库基于TCP协议实现的一种内部通信机制，DMDSC集群中存在两套MAL系统，DMASM服务器之间配置一套MAL系统，dmserver服务器之间配置一套MAL系统。一旦MAL链路出现异常，DMCSS会进行裁定，并从集群中踢出一个节点，保证集群环境正常运行。

1. DMDSC

#DMDCR_ASM_RESTART_INTERVAL =30  #CSS认定ASM故障重启的时间

#DMDCR_DB_RESTART_INTERVAL  =60  #CSS认定DSC故障重启的时间

1. 1. DMCSS控制节点核心进程被kill

用例编号	5_5
测试目的	在控制节点杀掉dmcss进程，对DMASM、DMDSC以及应用连接的影响
测试步骤	1. 通过CSSM识别CSS控制节点（CSS1/ASM1/CCDC0是控制节点） 2. 发起Jmeter压力 3. (root)# kill -9 <PID_of_dmcss>
测试预期	杀掉CSS控制节点会造成控制节点切换，不会造成应用停机。
测试结果	08:38:11，杀掉DMCSS控制节点CSS1核心进程（在主机节点2上）。 08:40:22，存活CSS节点监测到控制节点关闭，并设置EP CSS0为控制节点。CSS控制节点切换。 08:40:29，新控制节点CSS0设置EP CCDC1[1]为故障EP；同时设置EP ASM1[1]为故障EP。故障节点上的应用重新连接到存活节点。 08:40:32，设置EP ASM0[0]为控制节点。ASM控制节点切换。CCDC0本来就是控制节点，不需要切换。 08:46:11，手工启动CSS。 08:46:18，确认EP CSS0[0]为控制节点。 08:46:48，CSS1重启本地ASM实例，并设置EP ASM1[1]为故障重加入EP。 08:47:18，CSS1重启本地DB实例。 08:47:39，故障EP重新加入DSC结束，故障EP恢复结束。 08:47:42，完成故障处理。
测试结论	杀掉CSS控制节点会造成CSS/ASM控制节点切换，本地CSS/ASM/DB服务会被终止，但不会影响其他存活节点。没有造成应用Outage。被杀掉的CSS需要手工启动。
测试人员签字		测试审核员签字

1. 1. DMCSS控制节点核心进程hang

用例编号	5_6
测试目的	在控制节点hang住dmcss进程，对DMASM、DMDSC以及应用连接的影响
测试步骤	1. 通过CSSM识别CSS控制节点（CSS0\ASM0\CCDC0为控制节点） 2. 发起Jmeter压力 3. (root)# kill -19 <PID_of_dmcss> 4. Hang 20分钟 5.解除hang状态 (root)# kill -18 <PID_of_dmcss>
测试结果	09:21:57，CSS控制节点核心进程hang。 09:23:51，CSS存活节点监测到控制节点关闭，设置EP CSS1[1]为控制节点。CSS控制节点发生切换。 09:23:59，设置EP CCDC0[0]为故障EP，并设置EP CCDC1[1]为控制节点。 09:24:00，设置EP ASM0[0]为故障EP，设置EP ASM1[1]为控制节点。此时，故障节点上的应用重新连接到存活DB节点。 09:40:43，手工解除CSS0夯状态。 09:40:50，确认EP CSS1[1]为控制节点。 等待30分钟，未发现重启ASM0和CCDC0数据库服务。手工启动ASM和DB。 10:11:09，设置EP ASM0[0]为故障重加入EP。 10:11:36，设置EP CCDC0[0]为故障重加入EP。 10:11:41，设置EP CCDC0[0]为控制节点。 10:11:46，完成故障处理。
测试结论	CSS控制节点核心进程hang，会造成本地ASM/DB服务宕机，对其他节点服务没有影响。没有造成应用Outage。 Hang住的CSS进程需要手工解除hang状态，但ASM/DB不会自动重启，需要手工启动，这是与5.4场景的区别。
测试人员签字		测试审核员签字

1. 高可用场景影响分析与说明

1. 影响分析总结：

1. 不管是控制节点还是非控制节点，在数据库主机宕机时应用都会受到短暂影响，时长在60秒至270秒之间（参数可调，最低5秒）。如果本地归档未放在本地磁盘，文件系统只读不会对应用造成影响。

2. 数据库（DSC）核心进程异常崩溃（类似于Kill）或者夯住，一般都会造成对应用的影响，时长是60秒（参数可调，最低5秒）。

3. ASM核心进程异常通常不会造成应用停顿。一个例外是，在CSS/ASM/DB的控制节点分布在不同主机上时，“ASM非控制节点核心进程被Kill”会造成127秒的数据库不可用。该问题是DMDSC的一个缺陷，达梦厂商已确认并在修复中。

4. 停启DMCSS服务，以及CSS核心进程异常，都不会造成应用停顿。

综上，DMCSS和DMASM通常不会对应用造成影响。当出现数据库核心进程异常或者数据库主机宕机时，需要重点关注。