MySQL集群环境测试报告.docx
《MySQL集群环境测试报告.docx》由会员分享,可在线阅读,更多相关《MySQL集群环境测试报告.docx(16页珍藏版)》请在冰豆网上搜索。
MySQL集群环境测试报告
MySQL集群环境
测试报告
目录
1简介4
1.1目的4
1.2适用范围4
2测试环境4
2.1本部硬件环境4
2.2本部软件环境4
2.3拓扑图5
2.4数据环境6
3测试大纲8
4性能测试结果9
5稳定性测试16
6测试结论16
1简介
1.1目的
本文档描述测试MySQL性能及稳定性测试结果。
1.2适用范围
本测试只作为内部决策参考,不公开发布,不承担所有责任。
2测试环境
2.1本部硬件环境
主机:
5台
OS:
Redhat5.5
配置:
cpu:
8core
Mem:
32G
IP :
192.168.161.164
192.168.161.165
192.168.161.166
192.168.161.177
192.168.161.178
2.2本部软件环境
操作系统:
linux(Redhat5.5)
mysql5.5.30-ndb-7.2.12
2.3拓扑图
2.4数据环境
第一部分:
创建表和索引
createtableXACCT_ITEM_TEST
(
ACCT_ITEM_IDNUMBER(12)notnull,
SERV_IDNUMBER(12),
ACCT_IDNUMBER(12),
ACCT_ITEM_TYPE_IDNUMBER(6)notnull,
BILLING_CYCLE_IDNUMBER(6)notnull,
METER_DURATIONNUMBER(10),
SHEET_TOTALNUMBER(10),
CREATED_DATEDATEnotnull,
PARTNER_IDNUMBER(4),
BILL_SERIAL_NBRNUMBER(18),
STATECHAR(3)notnull,
TBILL_SERIAL_NBRVARCHAR2(10),
BUYER_FLAGVARCHAR2(6),
PAY_SERIAL_NBRVARCHAR2(10),
TPAY_SERIAL_NBRVARCHAR2(18),
CALLNUMBER(12),
COUNTSNUMBER(12),
CHARGENUMBER(10)notnull,
ACCT_ITEM_CODEVARCHAR2(10),
STATE_DATEDATEnotnull
)
1、主键:
primarykey:
acct_item_id
2、索引:
1)serv_id;2)acct_id
第二部分:
造基础数据
说明:
在以下的测试之前需要在表中插入500万条记录;如下:
insertintoXACCT_ITEM_TEST
(
ACCT_ITEM_ID,
SERV_ID,
ACCT_ID,
ACCT_ITEM_TYPE_ID,
BILLING_CYCLE_ID,
METER_DURATION,
SHEET_TOTAL,
CREATED_DATE,
PARTNER_ID,
BILL_SERIAL_NBR,
STATE,
TBILL_SERIAL_NBR,
BUYER_FLAG,
PAY_SERIAL_NBR,
TPAY_SERIAL_NBR,
CALL,
COUNTS,
CHARGE,
ACCT_ITEM_CODE,
STATE_DATE
)
values
(
acct_item_id.nextval,
acct_item_id+10000000,
acct_item_id+20000000,
mod(rownum,1000),
201401,
0,
0,
sysdate,1,1,'N0A','2014010000','000','PAY0000000','TPAY_SER_000',1000,20000,400000,'1111111','A01');
说明:
后续的insert\update\delete不动这500万数据。
3测试大纲
包含性能测试、并发测试、扩展性测试、各个节点异常影响、异常恢复。
分类
子类
测试条目
cluster
cluster
管理节点宕掉(是否影响DDL,DML)
数据节点宕掉(按冗余份数增加用例,用查询验证)
sql节点宕掉
mysqlproxy稳定性
主从模式
主从模式
纯数据文件导入(主从)
主节点宕掉
从节点宕掉
性能测试
1、测试单条提交的模式下:
10万条记录的耗时;(按有无索引情况增加用例)
2、测试每1万条提交的模式下:
10万条记录的耗时
update
1、测试单条提交模式下:
10万条记录的耗时;
2、测试每1万条提交的模式下:
10万条记录的耗时;
select
测试单结果集查询(无索引)
测试单结果集查询(有索引)
测试多结果集查询(千条结果)
千万级表关联汇总10条结果集情况(关联表数据)
百万级表关联汇总10条结果集情况(关联表数据)
大表(千万级)与小表(百条)关联
delete
测试每1万条提交的模式下:
10万条记录的耗时;
测试单条提交模式下:
10万条记录的耗时;
组合DML
实时计算场景定制
并发测试
并发测试
业务模拟,按并发用户数增加用例(现场定制)
4性能测试结果
单进程insert:
千条结果集select:
单结果集查询:
Update:
8个并发insert(每个SQL节点2个并发):
16个并发insert(每个SQL节点4个并发):
24个并发insert(每个SQL节点6个并发):
两千万记录的表关联查询:
测试类型
操作类型
模式
记录数
采用自增字段(类似SEQ)
无自增字段)
备注
耗时(秒)
效率(条/秒)
耗时(秒)
效率(条/秒)
单操作
insert
单条提交
10万
158.97
629
92.02
1087
每1万条提交一次
10万
111.36
897
52.97
1888
这种模式在交易性系统几乎不使用
update
单条提交
10万
105.3
950
93.69
1067
每1万条提交一次
10万
100.91
991
82.28
1246
这种模式在交易性系统几乎不使用
select
单表无索引
100次
430
0.23
单表有索引
10次
42
2381
多结果集有索引
1000次
24
42(次/秒)
delete
单条提交
10万
72.35
1382
每1万条提交一次
10万
48.02
2082
并行
insert+insert
单条提交(8个并发)
10万
296
2703
12.38
8078
8个进程同时向一张表insert数据
单条提交(16个并发)
10万
14.25
7017
16个进程同时向一张表insert数据
单条提交(24个并发)
10万
22.47
4450
24个进程同时向一张表insert数据
update+insert
insert
10万
993
101
93.35
1071
两个进程同时操作一张表,一个insert,一个update
update
10万
905
110
93.54
1069
update+update
update
10万
109.04
917
110.9
902
两个进程同时操作一张表,但更新的记录行范围不一样
update
10万
108.81
919
110.9
902
增加数据节点
insert/update/delete
需要验证select+update
select+delete,
......
本次没有测试
多表关联查询
测试用例
测试结果
表说明
无缓存
有缓存
家庭用户
0.39秒
0.29秒
PROD_INST_5511146万
ACCOUNT_551600万
OFFER_PROD_INST_REL_5512000万
PROD_OFFER_INST_5512000万
合肥工大用户
180.79秒
73.37秒
因为测试环境可能有外部影响,或者同样的测试用例在不同时间点性能略有差异,建议只看数量级方面的。
5稳定性测试
管理节点宕掉
不影响数据库的正常使用
数据节点宕掉
如果存在多份冗余,宕掉一个数据节点不影响数据库正常使用
SQL节点宕掉
SQL节点宕掉不影响正常使用
数据备份
Mysql可以设置副本数,如两个2副本,则实际是保存三份数据。
数据同步
恢复好的数据节点在启动的时候会自动同步数据,100万数据的同步时间为2分钟
主备互换
宕掉的主数据节点恢复之后,主数据节点会变成备数据节点,即互为主备
其他
1、存储过程函数问题:
存储过程函数不会自动同步到其它节点
2、锁问题:
必须根据索引来进行update或者delete,要不然不能并发
3、user表和其它系统表不是ndb引擎,每个节点需要单独赋权
4、innodb引擎加载2千万数据只要半个小时,ndb半个小时只能导入50万数据(解决方法:
把导入文件拆分成多份(会丢失几条记录),使用多个会话同时进行导入)
5、在扩充表空间的时候不能进行DDL操作和新的数据库连接
6、同一份数据在oracle里面是13G,磁盘表是61.38G(每个数据节点61.38G),占用内存2.6G
7、数据节点启动需要6分钟,目前数据量不到10个G,数据量越大启动越慢
8、执行DDL语句时(比如创建索引和truncate表等),会阻塞别的DDL语句,也会阻塞新的数据库连接
9、在一个两千万记录的磁盘表上创建索引,需要9个小时
6测试结论
不存在单点故障;并发性不是很高,到16个并发的时候就呈现性能下降趋势;有auto_increment字段的表并发性能很低。
在导入数据方面,性能远远低于innodb引擎。
执行DDL语句时(比如创建索引和truncate表等),会阻塞别的DDL语句,也会阻塞新的数据库连接。
mysqlcluster测试已经进行了一段时间,测试过程中也遇到一系列的难题,现在得出以下结论:
1.磁盘表完全不可用
2.并发性能不高,到十六个并发就呈现性能下降趋势,如使用auto_increment字段,性能更低
3.无论是磁盘表还是非磁盘表,创建索引的时候,整个数据库会HANG住
4.导入数据的速度远远低于innodb引擎表
5.数据节点启动慢,数据越大启动越慢
6.存储过程和user表等系统表是每个节点单独所有的
7.使用非磁盘表,数据全部存放在内存里面,开销昂贵
8.在使用过程中会遇到一些BUG,但是难以找到解决BUG的补丁