首页 > 数据库 > 国内数据库 > 达梦数据库主机链路冗余、DSC集群相关测试
一、 主机链路冗余测试
主要测试在单链路环境下和冗余链路环境下达梦数据库的部署和运行状况:
n 鲲鹏环境采取单链路,软硬件信息如下:
|
用途 |
类别 |
配置 |
数量 |
|
数据库服务器 |
硬件 |
处理器架构:ARM 处理器规格:Kunpeng920 2*48 内存规格:512G 硬盘规格:400G |
2 |
|
软件 |
操作系统:银河麒麟V10 数据库:达梦V8.1 DMHS :V4.1.1 | ||
|
其他硬件 万兆交换机 |
磁盘整列 |
共享存储,2台数据库服务器都能连接,硬盘4块,1G+1G+40G+500G |
1 |
|
万兆交换机 |
心跳网络为万兆网,单链路心跳,未做冗余 |
1 | |
|
HBA 卡 |
4 台数据库服务各为2个,未做冗余和负载均衡 |
8 |
n 海光环境采取双链路,软硬件信息如下:
|
用途 |
类别 |
配置 |
数量 |
|
数据库服务器 |
硬件 |
处理器架构:x86 处理器规格:Hygon C86 7280 32core 2*32 内存规格:512G 硬盘规格:400G |
2 |
|
软件 |
操作系统:银河麒麟V10 数据库:达梦V8.1 DMHS :V4.1.1 | ||
|
其他硬件 万兆交换机 |
磁盘整列 |
共享存储,2台数据库服务器都能连接,硬盘4块,1G+2G+40G+500G |
1 |
|
万兆交换机 |
心跳网络为万兆网,双链路心跳,平衡负载模式 |
2 | |
|
HBA 卡 |
4 台数据库服务各为2个,双链路 |
8 |
测试结果:
1 、网络链路在单链路下和捆绑双链路下,达梦数据库运行情况一致,达梦数据库通过和操作系统进行交互,不直接和底层硬件交互,数据库运行日志未体现出差异。
2 、存储HBA卡在单链路下和捆绑双链路下,达梦数据库对磁盘读写情况一致,达梦数据库识别到的是操作系统链路聚合后的逻辑磁盘分区,不直接对裸盘进行链路读写,数据库运行日志未体现出差异。
3 、达梦数据库运行在在网络链路冗余情况下,断开任一网络链路,数据库运行正常,未感知到网络链路单点故障。
4 、达梦数据库运行在在存储链路冗余情况下,断开任一存储链路,数据库运行正常,未感知到存储链路单点故障。
二、 DSC 集群仲裁原理和实现方式测试
主要对达梦DSC集群如何自行判断节点状态,如何在发生节点故障时仲裁判断故障节点和正常节点,保障数据一致性和高可用性进行测试。
达梦DSC共享集群主要通过其DMCSS(Dameng Cluster Synchronization Services)达梦集群同步服务来进行集群的管理,由DMCSS 控制节点故障选举和切换。
DMCSS 工作的基本原理是:在 Voting disk 中,为每个被监控对象(dmasmsvr、dmserver、DMCSS)分配一片独立的存储区域,被监控对象定时向 Voting Disk 写入信息(包括时间戳、状态、命令、以及命令执行结果等);DMCSS 控制节点定时从 Voting Disk 读取信息,检查被监控对象的状态变化,启动相应的处理流程;被监控对象只会被动的接收DMCSS 控制节点命令,执行并响应。
DMCSS 主要功能包括:写入心跳信息、选举 DMCSS 控制节点、选取 DMASM/DMDSC 控制节点、管理被监控对象的启动流程、集群状态监控、节点故障处理、节点重加入等,DMCSS还可以接收并执行 DMCSSM 指令。
测试结果:
1 、单个节点DMCSS服务故障,模拟了DMCSS服务进程故障,主机故障、磁盘心跳故障下达梦DSC集群DMCSS控制节点切换选取机制。经测试达梦与Oracle不同的地方在于达梦有主控节点的概念,Oracle每个节点的优先级一致无主控节点的概念。测试过程将主控节点的DMCSS服务直接杀掉,存活节点通过读取Voting Disk盘中的心跳选举信息,判断节点存活情况,并在存活节点中选取节点号最小的节点作为主控节点,在这个过程当中故障节点上的连接会话中断,正常节点的数据库会话服务正常。
2 、私有网络故障
达梦数据库不通过私有网络进行判断节点是否正常,仅通过私有网络进行节点间内存块的交换以确保数据一致性,保障多节点数据一致的机制是通过数据锁的方式实现的。经测试当一个节点对目标数据块进行修改但不提交,就会把这个数据块加锁,另一节点对相同数据块的修改会话就拿不到资源处于等待锁的状态。当私有网络发生故障,集群间不能进行数据块通讯的时候,各个节点会把信息写入Voting Disk盘中,并触发心跳选举,优先节点号小的节点会继续存活,节点号大的节点将主动关闭服务。
3 、故障模拟过程中,通过达梦数据库客户端连接数据库进行增删改查操作,经测试,如果会话建联在故障节点,会话会中断,未完成的dml操作会回滚;如果会话建联在正常节点上,会话可以正常进行增删改查操作,集群切换选举过程中正在执行未完成的sql会有短暂的等待过程。
4 、模拟的各类节点故障在恢复后,经测试能够通过达梦DMCSS服务自动恢复到集群中进行服务,恢复过程中正常节点上得sql会话正常执行,未产生影响。加入集群的恢复节点新建连接正常,故障期间发生的数据变化查询正常。
三、 集群间数据交互对sql的影响
达梦数据库DSC共享集群之间与Oracle RAC集群类似,也采用私有网络进行内存数据块同步校验机制,确保数据一致性,数据块在节点间同步的时间花销计入sql执行的全部时间内。
测试结果:
构造一张多数据类型大表,进行不同数据量的数据插入操作,对比在DSC集群环境下和在单节点数据库环境下sql执行时间的差异。为模拟真实情况测试结果如下:
|
场景 |
DSC 单节点+DW单机 |
DSC 两节点+DW单机 |
DSC 两节点+DW单机 其中DSC的A节点插入数据,B节点每秒读取插入的数据记录 |
|
一共100万条数据 每插入1条数据,然后进行提交 |
6min 5s |
6min 16s 324ms |
8min 31s 971ms |
|
一共100万条数据 每插入5000条数据,然后进行提交 |
46s 824ms |
50s 549ms |
1min 5s 784ms |
|
一次性提交100万条数据 |
46s 177ms |
1min 8s 14ms |
1min 17s 296 |
|
备注 |
海光环境,主要性能参数:512G内存,Hygon C86 7280 32core 2*32 测试插入的表覆盖全部数据类型,填充值为近极限值,测试过程未经过任何优化 | ||
经测试,当数据块在不被反复读取的情况下,两节点集群的集群间交互大概比单节点 多出10%左右的执行时间用于集群的交互等待,不同的数据块提交频次,没有直接的区别;当数据块在被反复读取的情况下,两节点集群的集群间交互大概比单节点 多出15%-25%左右的执行时间用于集群的交互等待,且数据块提交频次越高,集群间交互等待时间越长。
四、 ARM 及X86环境下的性能差异
为测试ARM架构鲲鹏920CPU环境和X86架构海光7280CPU环境下达梦数据库的处理性能差异,设计了在不同数据量下计算型创建表和创建索引操作的处理性能。
|
环境 |
鲲鹏环境 |
海光环境 | |||||||
|
操作 |
创建表 |
创建索引 |
创建表 |
创建索引 | |||||
|
耗时 |
表 大小 |
唯一 索引 |
函数 索引 |
耗时 |
表 大小 |
唯一 索引 |
函数 索引 | ||
|
数 据 量 |
100 万 |
41s |
2.77G |
910ms |
917ms |
61s 620ms |
2.77G |
946ms |
961ms |
|
500 万 |
3min 26s |
13.8G |
4s 217ms |
4s 539ms |
4min 48s 586ms |
13.8G |
4s 184ms |
5s 43ms | |
|
1000 万 |
7min 12s |
27.76 G |
8s 2ms |
9s 67ms |
9min 30s 624ms |
27.76 G |
8s 197ms |
10s 436ms | |
|
备注 |
1、 鲲鹏环境,主要性能参数:512G内存,Kunpeng920 2*48 2、 海光环境,主要性能参数:512G内存, Hygon C86 7280 32core 2*32 3、 鲲鹏环境和海光环境DSC集群挂载的共享存储为同一设备 4、 测试插入的表覆盖全部数据类型,填充值为近极限值,测试过程未经过任何优化 | ||||||||
经测试,海光环境比鲲鹏环境处理 性能下降20%-30%左右,且性能下降程度和处理数据量成正比。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/20599341/viewspace-2917818/ ,如需转载,请注明出处,否则将追究法律责任。