MySQL集群环境测试报告.docx

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的补丁