最近在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
|
$ while true; do host mysql-01.cw9unlnqm15o.ap-northeast-1.rds.amazonaws.com | grep alias ; sleep 1; done
|
现在让我们通过重新启动模拟一个场景，我们将使辅助区域成为可用区。选择重启实例，通过重启故障转移来测试。
可以看到我们的终端节点从刚开始CNAME可用区 到 后面 CNAME辅助区域，完成了一次切换。
再次打开实例详情，可以看到可用区跟辅助区域已经更改了，可用区变为辅助区域，辅助区域变为可用区，完成了切换【整个切换时间在40s左右，后面有更详细的证明】。
如果看AWS提供的事件信息，会有如下切换过程：
测试主从故障切换时间？
我们将继续连接到数据库并持续在数据库中插入记录，目的是检查发生故障转移需要多长时间？
先在EC2上连接到RDS，创建一个表。
|
1
|
$ mysql -h mysql-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) unsigned NOT NULL AUTO_INCREMENT,
`cycle` varchar(50) DEFAULT NULL,
`counter` int(10) unsigned NOT NULL,
`failover_date` datetime NOT NULL default current_timestamp,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 COMMENT='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
|
$ cat failover_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 as e:
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