aws mysql 多区_Amazon RDS多区域高可用测试

最近在AWS上面需要部署一组多区域RDS集群，AWS的多区域简单理解就是RDS一主一从分别在当地的两个机房(两个区域)。所以就有了下面各方面的测试。

我们需要测试什么？

Primary挂掉时，Secondary是否会自动升级为Primary提供服务，切换期间中断多久？

发生切换后，数据是否有丢失？

TPS&QPS分别是多少(配置不同得到的值会不同)。

测试的基础环境？

RDS服务类db.m4.2xlarge(8核32G，通用SSD)。

RDS因为是MySQL，版本MySQL 5.7.21。

由于购买的AWS多区域RDS服务，所以我们会得到一个RDS集群(Primary & Secondary)，分别在两个区域。

EC2一台，用以连接RDS服务，EC2与RDS之间需要使用同一个VPC，以保证通讯正常。

RDS安全组更改以允许从EC2实例的内部IP地址访问传入端口3000(我的RDS设置端口)。

确定的RDS主次区域？

在具有多可用区的Amazon RDS中，详情部分呈现了主要可用区(称为可用区)和辅助可用区(称为辅助区)。

上图中已经显示

可用区(主节点)：ap-northeast-1c

辅助区(从节点)：ap-northeast-1d

终端节点：mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com

终端节点是AWS提供给应用访问RDS实例的域名，该节点是一个DNS CNAME，它一次指向TTL为5秒的不同可用区(Primary＆Secondary)中可用的两个实例之一。默认CNAME到主节点。

测试主从故障切换是否正常？

我们将使用mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com测试RDS主从故障切换。在EC2主机上执行如下命令：

1

$whiletrue;dohost mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com|grepalias;sleep1;done

现在让我们通过重新启动模拟一个场景，我们将使辅助区域成为可用区。选择重启实例，通过重启故障转移来测试。

可以看到我们的终端节点从刚开始CNAME可用区 到 后面 CNAME辅助区域，完成了一次切换。

再次打开实例详情，可以看到可用区跟辅助区域已经更改了，可用区变为辅助区域，辅助区域变为可用区，完成了切换【整个切换时间在40s左右，后面有更详细的证明】。

如果看AWS提供的事件信息，会有如下切换过程：

测试主从故障切换时间？

我们将继续连接到数据库并持续在数据库中插入记录，目的是检查发生故障转移需要多长时间？

先在EC2上连接到RDS，创建一个表。

1

$mysql-hmysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com-P3000-uroot-proot1234

创建表的语句，自动加了一个记录创建时间。

1

2

3

4

5

6

7

CREATE TABLE`failover_test`(

`id`int(10)unsignedNOTNULLAUTO_INCREMENT,

`cycle`varchar(50)DEFAULTNULL,

`counter`int(10)unsignedNOTNULL,

`failover_date`datetime NOTNULLdefaultcurrent_timestamp,

PRIMARY KEY(`id`)

)ENGINE=InnoDB AUTO_INCREMENT=1COMMENT='AWS RDS Failover Testing';

然后让我们创建一个测试脚本(这里使用Python)。

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

$catfailover_test.py

#!/usr/bin/env python

#coding:utf-8

from __future__ import print_function

import pymysql

import sys

cycle=sys.argv[1]

count=sys.argv[2]

conn=pymysql.connect(

host='mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com',

port=3000,

user='root',

password='root1234',

database='sbtest',

charset='utf8',

connect_timeout=1

)

cursor=conn.cursor()

try:

conn.begin()

sql="insert into failover_test(cycle, counter) values('%s', %s);"%(cycle,count)

cursor.execute(sql)

conn.commit()

print(count,'',end='')

except Exception ase:

conn.rollback()

cursor.close()

conn.close()

测试计划：

1. 我们将在EC2终端开启一个循环执行Python脚本。

2. 当脚本在执行时，在我们将使用“重启故障转移？”选项重启数据库。

3. 我们将监测Python脚本并注意缺失的任何数字，缺少数字的计数会以秒为单位给你提供总宕机时间(大约)。

我遵循这个步骤得到的结果如下：

请注意数据插入暂停在92并且不显示数字的持续时间，这意味着主区域的服务器已关闭，并且EC2实例无法连接到任何RDS服务器。当数字开始显示为140时，证明主从已经切换完成，新的主区域服务器开始提供服务。这个中间的间隔时间就可以认为是整个集群的宕机时间。这个我们从查看数据库表插入记录时间也是可以做一个对比。

数据库中插入记录间隔时间与脚本输出几乎一致。

测试主从故障切换数据一致性？

这个测试在AWS上面，其实不是很好测试，因为我们无法登录到辅助区域主机来对比可用区数据。还有一点就是我们是通过AWS提供的“重启故障转移”来测试高可用切换，对于它背后做什么我们是不知道的。比如它是软重启还是硬重启，这些对于数据一致性的测试都是非常重要的。还有一些断电情况下的测试。

所以在这个测试中，我们只会连接主区域实例端点持续插入数据。然后，我们将重新启动并使辅助区域实例成为主区域实例。

测试计划：

1. 我们将打开4个终端窗口并执行上述脚本4次，并使用不同的名称进行区分。

2. 在执行脚本时，我们将通过“重新启动故障转移？”选项重新启动数据库实例。

3. 一旦脚本停止添加更多数据，我们将输出的最大数字与数据库记录进行匹配。

在EC2上面执行脚本，开多个窗口(使用tmux)，运行如下命令：

然后启动故障转移，此时所有命令执行界面都应该为停止状态，最后一个数字就是我们插入到主库的的数据条数。

当切换完成后，我们就可以来数据库查一下数据，看看是否正确。

可以看到，cycle0-3对应的数据都存在在我们新的主区域实例中，证明数据一致性有保障。

这个测试数据量太小，其实也无法证明什么，但目前还没有其他可靠方法。

TPS&QPS各是多少？

通过查询变量我们知道，RDS默认是“双1”配置，缓冲区为内存的75%，隔离级别为RR，行格式为MIXED，事务日志2个128M。

我这里在EC2上使用sysbench简单压测了一下，使用的命令如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

$sysbench/usr/share/sysbench/oltp_read_write.lua\

--mysql-host=mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com\

--mysql-port=3000\

--mysql-user=root\

--mysql-password='root1234'\

--mysql-db=sbtest\

--db-driver=mysql\

--tables=4\

--table-size=3000000\

--report-interval=10\

--threads=16\

--time=120\

run

结果如下图所示(配置为8核32G，通用SSD)：

然后又使用64线程压测了一下，结果如下图：

虽然TPS&QPS翻了一倍，但是CPU使用率也到了100%，磁盘IOPS大约在3500左右。

这里只是简单的对AWS RDS多区域部署能压测的方面进行了压测，仅供参考。另外，对于RDS增缩配置，或者参数修改之类的操作都是通过故障转移来做的。

https://exain.wordpress.com/2017/07/12/amazon-rds-multi-az-setup-failover-simulation/#jp-carousel-450