Amazon Aurora MySQL 和 Amazon RDS for MySQL 不同数据量下的集群故障转移和实例扩容时间测试

1. 测试背景

在上一篇 Blog 里我们通过测试，总结了 Amazon Aurora MySQL 和 Amazon RDS for MySQL 在集群故障转移和只读实例扩容时的差异。在本篇文章里，我们测试在不同数据量的前提下，Amazon Aurora MySQL 和 Amazon RDS for MySQL 的集群故障转移时间和只读实例扩容时间的变化，也作为选型参考。

2. 测试环境

3. 测试前提

本次测试基于以下 3 个前提：

• 压测实例、Amazon Aurora MySQL 和 Amazon RDS for MySQL 均在一个 VPC
• Amazon Aurora MySQL 和 Amazon RDS for MySQL 均使用生产模板的默认配置
• 开启 Amazon CloudTrail 分别统计集群故障转移和只读实例扩容的开始、结束时间

4. 测试架构图

4.1 Amazon Aurora MySQL 测试架构图

4.2 Amazon RDS for MySQL 测试架构图

5. 测试用例

5.1 集群故障转移时间测试用例，测试基于以下 8 种配置模式，分别测试无工作负载和有工作负载两种情况下的集群故障转移时间

*工作负载场景：主节点 80% CPU 工作负载

5.2 只读实例扩容时间测试用例，测试基于以下 8 种配置模式，分别测试无工作负载和有工作负载两种情况下的只读实例扩容时间

*工作负载场景：主节点 80% CPU 工作负载

6. 测试方法

6.1 集群故障转移时间测试方法

1. 模拟工作负载的步骤如下：
   • 在压测实例上安装 sysbench（步骤参看 https://github.com/akopytov/sysbench）
   • 按照如下命令，向数据库写入 100GB 数据

     sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --threads=64 --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306 --mysql-db= bench _test --oltp-tables-count=100 --oltp-table-size=5000000 --db-driver=mysql prepare #300GB 和 500GB 数据生产使用此命令，并将 oltp-tables-count 或 oltp-table-size 成倍调大即可

• 按照如下命令，对主节点进行压力测试

  sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --mysql-host=bench-test.cluster-cum78jhrtci1.ap-south-1.rds.amazonaws.com --mysql-user=admin --mysql-password=xxxx --mysql-port=3306  --mysql-db= bench_test --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --time=3600 --oltp-read-only=on --threads=120 run #可以通过调整 threads 来控制工作负载，不同数据库实例类型线程数不一样

2. 对于 Amazon Aurora MySQL，在控制台上，选择目标集群的写入实例并点击下图中的“故障转移”按钮
   
3. 点击“日志和事件”，在下方的近期事件里查看故障转移开始和结束时间，计算出故障转移花费的时间
   
4. 对于 Amazon RDS for MySQL，在控制台上，选择目标集群的主实例并点击下图中的“重启”按钮，在下一个页面勾选“是否进行重启和故障转移”，点击确认
   
5. 点击“日志和事件”，在下方的近期事件里查看故障转移开始和结束时间，计算得出故障转移花费的时间
   

6.2 只读实例扩容时间测试方法

1. 对于 Amazon Aurora MySQL，在控制台上，选择目标集群并点击下图中的“添加读取器”按钮
   
2. 使用 CloudTrail 里 CreateDBInstance 事件的时间作为添加只读实例的开始时间
   
3. 回到控制台，在目标集群 “日志和事件”里使用最后一步的时间作为添加只读实例的结束时间
   
4. 对于 Amazon RDS for MySQL，在控制台上，选择目标集群并点击下图中的“创建只读副本”按钮
   
5. 使用 CloudTrail 里 CreateDBInstanceReadReplica 事件的时间作为添加只读实例的开始时间
   
6. 回到控制台，在目标集群“日志和事件”里使用最后一步的时间作为添加只读实例的结束时间
   

7. 测试数据

7.1 集群故障转移时间测试数据

表格记录时间均为 3 次测试的平均时间

7.2 只读实例扩容时间测试数据

表格记录时间均为  3  次测试的平均时间

8. 测试结论

1. Amazon Aurora MySQL 的集群故障转移时间整体分布在 31秒 – 38 秒之间，与数据库数据量和工作负载相关性较小。Amazon RDS for MySQL 的集群故障转移时间整体分布在 80秒 – 89 秒，与数据库数据量相关性较小，与有无工作负载相关较大，有工作负载时会增加 2 秒 – 9 秒。
2. Amazon Aurora MySQL 的只读实例扩容时间整体分布在 6 分 10 秒 – 6 分 29 秒之间，与数据库数据量和有无工作负载相关性较小，主要原因^[1]是 Amazon Aurora MySQL 是存储计算分离架构，数据平均分布于 3 个 AZ，共计 6 副本，实例之间共享存储，扩容只读实例时无需数据同步时间。Amazon RDS for MySQL 的只读实例扩容时间整体分布在 15 分 20 秒 – 16 分 22 秒直接，与数据库数据量相关性较大，数据库数据量越大所需时间就越长，从 100GB 增加到 1TB 时，时间会增加 1 分 01 秒，主要原因^[2]是 Amazon RDS for MySQL 是从主节点数据库的 Snapshot 恢复数据到只读实例上，数据库数据量越大恢复时间越长。

[1] 参看 Aurora 副本：https://docs.thinkwithwp.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html#Aurora.Replication.Replicas

[2] 参看 RDS for MySQL 只读副本的工作原理：https://docs.thinkwithwp.com/zh_cn/AmazonRDS/latest/UserGuide/USER_ReadRepl.html

9. 汇总结论

结合上一篇 Blog 的结论，汇总如下：

• Amazon Aurora MySQL 的集群故障转移时间和只读实例扩容时间与集群模式，机型大小，有无工作负载，数据库数据量大小相关性较小，时间都比较稳定且低于 Amazon RDS for MySQL。
• Amazon RDS for MySQL 的集群故障转移时间与集群模式，机型大小，有无工作负载相关性较小，与有无数据库数据量相关性较大，但故障转移时间不随着数据库数据量增加而增加。
• Amazon RDS for MySQL 的只读实例扩容时间与集群模式，机型大小，有无工作负载相关性较小，与有无数据库数据量相关性较大，且实例扩容时间随着数据库数据量增加而增加。

本篇作者