-
- 阅读对象
- 架构管理人员、架构设计人员
- 项目需求分析、设计开发人员
- 数据架构师、DBA
- 开发人员
-
- 定义、缩写和分类
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会进行裁定,并从集群中踢出一个节点,保证集群环境正常运行。
- DMDSC
#DMDCR_ASM_RESTART_INTERVAL =30 #CSS认定ASM故障重启的时间
#DMDCR_DB_RESTART_INTERVAL =60 #CSS认定DSC故障重启的时间
-
- 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需要手工启动。 |
测试人员签字 |
|
测试审核员签字 |
|
-
- 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. 不管是控制节点还是非控制节点,在数据库主机宕机时应用都会受到短暂影响,时长在60秒至270秒之间(参数可调,最低5秒)。如果本地归档未放在本地磁盘,文件系统只读不会对应用造成影响。
2. 数据库(DSC)核心进程异常崩溃(类似于Kill)或者夯住,一般都会造成对应用的影响,时长是60秒(参数可调,最低5秒)。
3. ASM核心进程异常通常不会造成应用停顿。一个例外是,在CSS/ASM/DB的控制节点分布在不同主机上时,“ASM非控制节点核心进程被Kill”会造成127秒的数据库不可用。该问题是DMDSC的一个缺陷,达梦厂商已确认并在修复中。
4. 停启DMCSS服务,以及CSS核心进程异常,都不会造成应用停顿。
综上,DMCSS和DMASM通常不会对应用造成影响。当出现数据库核心进程异常或者数据库主机宕机时,需要重点关注。