前言
从 2020 年 10 月，基于 Amazon Graviton2 的数据库逐渐推出，您能够在应用 Amazon RDS for MySQL、Amazon RDS for PostgreSQL、Amazon RDS for MariaDB 以及兼容 PostgreSQL 和 MySQL 的 Amazon Aurora 时启动这些数据库实例。
Amazon Graviton2 处理器由 Amazon Web Services 应用 64 位 Arm Neoverse 内核定制，对第一代 Amazon Graviton 处理器进行了多种性能优化。这包含 7 倍的性能、4 倍的计算外围数量、每个内核 2 倍的公有内存、5 倍的内存速度和每个外围 2 倍的浮点性能。此外，Amazon Graviton2 处理器还具备全天候运行的全加密 DDR4 内存性能，并且每核加密性能进步 50%。这些性能晋升使 Graviton2 R6g 数据库实例成为数据库工作负载的上佳之选。
本文将向您展现 Graviton2 R6g 数据库实例对 R5 数据库实例的性能加强以及从自建或者托管数据库上迁徙到 Graviton2 R6g 数据库实例的办法流程。通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g 实例比之等同资源配置的 R5 实例性能均有显著的晋升，而每小时单价却有降落，因此 R6g 实例对客户来说，有更好的性价比。
环境筹备
1. 环境信息
留神：Aurora 的参数根本选用默认参数。因为 sysbench1.0.18 会有大量 prepared statement，所以要设置 max_prepared_stmt_count 为最大值 1048576 保障测试顺利进行，否则初始化时可能遇到谬误 FATAL: MySQL error: 1461“Can’t create more than max_prepared_stmt_count statements (current value: 16382)”
2. 装置和配置 sysbench
在测试客户端装置 sysbench1.0.18
从 git 中下载 sysbench
sudo yum install gcc gcc-c++ autoconf automake make libtool bzr mysql-devel git mysql
git clone https://github.com/akopytov/sysbench.git关上 sysbench 目录
cd sysbench
切换到 sysbench 1.0.18 版本，运行 autogen.sh
git checkout 1.0.18
sudo ./autogen.sh编译
sudo ./configure --prefix=/usr --mandir=/usr/share/man
sudo make
sudo make install3. 关上客户端资源限度
无论装置哪一种 sysbench 软件，都须要在 Sysbench 客户端执行 以下配置，通知 Linux kernel 能够用所有的 CPU cores 去解决 packets（默认只能够用两个）, 且缩小 cores 之间的 context switching. 这两个设置是为了用更少的 Sysbench 客户端达成吞吐指标.(ffffffff 示意应用 32 个核。请依据理论配置批改，例如理论只有 8 核，则输出 ff)
sudo sh -c 'for x in /sys/class/net/eth0/queues/rx-*; do echo ffffffff> $x/rps_cpus; done'
sudo sh -c "echo 32768 > /proc/sys/net/core/rps_sock_flow_entries"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt"
vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536测试
1. 只读负载测试
测试数据注入
首先通过 sysbench 客户端在测试数据库上生成测试表，这里生成 250 个表，每个表有行数 25000 条，您也能够依据您的指标，调整表的数目和大小，请替换 <> 之中的各种连贯信息，再执行命令，如果您间接从 blog 拷贝命令请留神格局。后续命令的注意事项雷同，将不再赘述
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_read_only prepare测试
在 sysbench client 执行命令模仿负载，每次继续 20 分钟，同时从 console 查看数据库 CPU，IO，网络等 metrics。在这里咱们将通过批改 num_threads 参数间断测试 32, 64, 128, 256 多种并发连贯的场景。
sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-user=<username> --mysql-password=<password> --mysql-port=<port> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=32 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-user=<username> --mysql-password=<password> --mysql-port=<port> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=64 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-user=<username> --mysql-password=<password> --mysql-port=<port> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=128 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log
sysbench --db-driver=mysql --mysql-host=<mysql host> --mysql-user=<username> --mysql-password=<password> --mysql-port=<port> --mysql-db=<dbname> --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=256 --percentile=95 --range_selects=0 --skip-trx=1 --report-interval=20 oltp_read_only run >> <dbname>_read.log革除测试数据
测试后革除数据命令如下：
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_read_only cleanup2. 只写负载测试
数据注入
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_write_only prepare测试
同样地，在 sysbench client 执行命令模仿只写负载，每次继续 20 分钟，同时从 console 查看数据库 CPU，IO，网络等 metrics。在这里咱们将通过批改 num_threads 参数间断测试 8,16,32 和 64 多种并发连贯的场景。
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=8 --percentile=95 --report-interval=20 oltp_write_only run >>_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=16 --percentile=95 --report-interval=20 oltp_write_only run >>_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=32 --percentile=95 --report-interval=20 oltp_write_only run >>_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=64 --percentile=95 --report-interval=20 oltp_write_only run >>_write.log革除测试数据
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_write_only cleanup3. 读 / 写混合压力测试
测试数据注入
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_read_write prepare测试
同样地，在 sysbench client 执行命令模仿读写混合负载，每次继续 20 分钟，同时从 console 查看数据库 CPU，IO，网络等 metrics。在这里咱们将通过批改 num_threads 参数间断测试 32、64、128 和 256 多种并发连贯的场景。
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=32 --percentile=95 --report-interval=20 oltp_read_write run >>_read_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=64 --percentile=95 --report-interval=20 oltp_read_write run >>_read_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=128--percentile=95 --report-interval=20 oltp_read_write run >>_read_write.log
sysbench --db-driver=mysql --mysql-host= --mysql-user=--mysql-password=--mysql-port= --mysql-db= --table_size=25000 --tables=250 --events=0 --max-time=1200 --threads=256 --percentile=95 --report-interval=20 oltp_read_write run >>_read_write.log革除测试数据
sysbench --db-driver=mysql --mysql-host=--mysql-port=--mysql-user=--mysql-password=--mysql-db=--table_size=25000 --tables=250 --events=0 --time=600 oltp_read_write cleanup后果剖析
1. 后果解读
数据库性能测试输入后果中的指标包含：
每秒执行事务数 TPS（Transactions Per Second）数据库每秒执行的事务数，以 COMMIT 胜利次数为准。
SysBench 规范 OLTP 读写混合场景中一个事务蕴含 18 个读写 SQL。
SysBench 规范 OLTP 只读场景中一个事务蕴含 14 个读 SQL（10 条主键查问、4 条范畴查问）。
SysBench 规范 OLTP 只写场景中一个事务蕴含 4 个写 SQL（2 条 UPDATE、1 条 DETELE、1 条 INSERT）。
每秒执行申请数 QPS（Queries Per Second）数据库每秒执行的 SQL 数。
2. 后果统计
在不同并发连接数下，应用雷同资源配置的 R6g 和 R5 实例的 Aurora MySQL5.7 只读负载测试数据如下：
在不同并发连接数下，应用雷同资源配置的 R6g 和 R5 实例的 Aurora MySQL5.7 只写负载测试数据如下：
在不同并发连接数下，应用雷同资源配置的 R6g 和 R5 实例的 Aurora MySQL5.7 读 / 写混合负载测试数据如下：
3. 论断
通过以上测试数据，咱们能够发现：
在只读负载测试中，R6g 实例比之等同资源配置的 R5 实例，QPS 晋升了 21%-37%。
在只写负载测试中，R6g 实例比之等同资源配置的 R5 实例，QPS 晋升了 79%-121%。
在读写混合负载测试中，R6g 实例比之等同资源配置的 R5 实例，QPS 晋升了 48%-60%。
在测试中无论是何种工作负载和并发条件，R6g 实例比之等同资源配置的 R5 实例性能均有显著的晋升。
在价格方面，咱们能够参考 Aurora 价格页面，以咱们测试的 r5.2xlarge 和 db.r6g.2xlarge 为例，db.r6g.2xlarge 每小时单价为 db.r5.2xlarge 每小时单价的 89.4%，联合之前性能测试后果，无疑 R6g 实例比之 R5 实例有更好的性价比。
留神：不同 region 不同实例类型的报价不同，下图为 2021-04-21 时截图，最新价格请见下面价格页面。
迁徙 MySQL 到 R6g 实例 Aurora
1. 迁徙到 R6g 实例 Aurora 的理由
绝对于在 EC2 上自建的 MySQL，应用 Aurora MySQL 能够带来很多好处，限于篇幅，现从四个方面简述如下：
高可用性
Aurora 将数据跨 3 个可用区同步复制到与集群卷关联的 6 个存储节点，提供 AZ（可用区）+ 1 的容错机制，即 1 个 AZ 解体仍旧能够写，一个 AZ+ 一个数据正本无法访问仍然可读。
更快的 failover 工夫，配合 RDS Proxy，通常 Aurora 均匀 failover 工夫为 3 秒左右。
集群终端节点为数据库集群的读取 / 写入连贯提供故障转移反对。如果数据库集群的以后主数据库实例失败，Aurora 将主动故障转移到新的主数据库实例。在故障转移期间，数据库集群将持续为从新的主数据库实例到集群终端节点的申请提供服务，对服务造成的中断起码。
Amazon Aurora 寰球数据库容许单个 Amazon Aurora 数据库逾越多个 Amazon 地区（region）。它在不影响数据库性能的状况下复制您的数据，在产生地区（region）级的中断时提供劫难恢复能力。
可扩展性
Aurora 最多能够创立 15 个只读 Aurora 正本对读取能力进行横向扩大，Aurora 数据库集群的读取器终端节点为数据库集群的只读连贯提供负载平衡反对。
只读 Aurora 正本与主实例共享雷同的底层存储，与 MySQL 的基于 binlog 复制不同，Aurora 集群上的正本通常比主实例滞后 10 毫秒。
Amazon Aurora 寰球数据库针对寰球分布式应用程序而设计，在每个 地区（region）中实现低提早的疾速本地读取，应用基于存储的复制，典型提早小于 1 秒。
性能
Amazon Aurora 通过将数据库引擎与为数据库工作负载构建的基于 SSD 的虚拟化存储层严密集成，缩小存储系统的写入操作，最大水平升高锁竞争并打消数据库过程线程所产生的提早，使性能大幅超过 MySQL。
Parallel Query 非常适合须要新数据和良好查问性能的剖析工作负载，可将剖析查问的运行速度进步多达 2 个数量级。而且不须要更改查问语法。查问优化器能够主动确定是否应用 PQ 来运行特定查问。
可管理性
Aurora 作为托管数据库服务，能够解决耗时型工作，如预置、修补、备份、复原、故障检测和修复，大大加重您的运维压力。
Aurora Serverless 数据库集群会依据您应用程序的需要主动启动、敞开以及扩大或缩减容量。Aurora Serverless 是简略且更具老本效益的抉择，实用于不频发的、间歇性的或不可预测的工作负载。
Aurora 克隆应用写入时复制协定。应用此机制，克隆在首次创立时只须要很少的额定空间。开始时，Aurora 保护数据的单个正本（由原始数据库集群和新数据库集群应用）。Aurora 仅在源集群或克隆集群上的数据产生更改时调配新的存储空间。借助克隆，咱们能够疾速经济地创立一个新的集群用于测试、审计等场景。
利用回溯性能您能够将数据库集群回溯到特定工夫，而无需从备份还原数据。尤其当您须要一直重置测试环境打消变更数据时，回溯性能比传统的工夫点复原要高效得多。
能够通过机器学习 (ML) 性能与 Amazon Aurora 的 联合应用，简化开发应用 Amazon SageMaker 和 Amazon Comprehend 服务执行预测的数据库应用程序的过程。此性能实用于多种疾速预测。包含低提早的实时用例，例如欺诈检测、广告定位和产品举荐。查问将客户资料、购物历史记录和产品目录数据传递给 SageMaker 模型。而后，您的应用程序将取得作为查问后果返回的产品举荐。
2. 从 EC2 自建 MySQL 迁徙到迁徙到 R6g 实例 Aurora 的办法
如果您在 EC2 上自建 MySQL5.6 或 5.7，您能够用以下四种方法迁徙到 R6g 实例的 Aurora MySQL：
通过 mysqldump 迁徙
因为 Amazon Aurora MySQL 是与 MySQL 兼容的数据库，所以您能够应用 mysqldump 实用程序从 MySQL 或 MariaDB 数据库中将数据复制到现有 Aurora MySQL 数据库集群。
无关如何为大型 MySQL 数据库执行该操作的探讨，请参阅将数据导入到 MySQL 或 MariaDB 数据库实例中，同时缩小停机工夫:
https://docs.aws.amazon.com/A…
对于具备较大量数据的 MySQL 数据库，请参阅将数据从 MySQL 或 MariaDB 数据库导入到 MySQL 或 MariaDB 数据库实例:
https://docs.aws.amazon.com/A…
通过 xtrbackup 迁徙
您能够将残缺备份文件和增量备份文件从源 MySQL 5.5、6 或 5.7 版数据库复制到 Amazon S3 存储桶，而后从这些文件还原 Amazon Aurora MySQL 数据库集群。具体步骤请见：将数据从内部 MySQL 数据库迁徙到 Amazon Aurora MySQL 数据库集群:
https://docs.aws.amazon.com/z…
该选项可能比应用 mysqldump 迁徙数据要快得多，因为应用 mysqldump 须要重放所有命令，以便在新的 Aurora MySQL 数据库集群中从源数据库从新创立架构和数据。通过复制源 MySQL 数据文件，Aurora MySQL 能够立刻将这些文件作为 Aurora MySQL 数据库集群的数据。
通过原生主从形式迁徙
创立用于复制的专用用户并授予权限
历史数据能够通过 xtrbackup 或 mysqldump 导入，在导出数据时通过增加参数在备份文件中记录日志点的地位信息
设置网络和平安组保障源 MySQL 和指标 Aurora 能够互连
通过运行 rds_set_external_master 存储过程，配置二进制日志复制。
通过运行 rds_start_replication 存储过程，启动二进制日志复制。
具体步骤请见将数据从内部 MySQL 数据库迁徙到 Amazon Aurora MySQL 数据库集群:
https://docs.aws.amazon.com/z…
通过 DMS 工作迁徙
Amazon Database Migration Service（DMS）服务能够帮忙客户在最小停机工夫的状况下，采纳在源库上捕捉变动数据，并在指标库上利用变动数据的模式，进行数据库的整体迁徙。DMS 不仅能够进行雷同数据库引擎的迁徙，同时还反对不同数据库引擎之间的迁徙。无关 DMS 的详细信息能够参考：https://aws.amazon.com/dms/。大抵步骤如下：
创立复制实例保障能够连贯到源和指标数据库，在源和指标数据库上创立复制数据专用用户并赋予相应权限
创立源 MySQL 和指标 Aurora 的 endpoint 并通过复制实例测试连贯
创立 Full load and CDC 工作，指定要复制的对象，能够是 schema 或者表的组合。
开启工作，Full load 工作负责迁徙历史数据。
Full load 实现后，CDC 工作会从 binlog 中捕捉变动并同步到 Aurora
在业务低谷的时间段，进行向源数据库写入，期待 CDC 工作复制提早为 0 后，确认数据统一切换应用程序向 Aurora 写入实现迁徙。
3. 从 RDS 迁徙到迁徙到 R6g 实例 Aurora 的办法
如果您曾经应用了 MySQL5.6 或 5.7 的 RDS，您能够用以下三种方法迁徙到 R6g 实例的 Aurora MYSQL：
通过只读正本迁徙
您能够为源 MySQL 数据库实例创立一个非凡类型的数据库集群，称为 Aurora 只读正本，这种办法能够将 RDS 数据迁徙到 Amazon Aurora 并要求最小停机工夫，通常咱们倡议抉择此种迁徙形式。具体步骤可见：通过 Aurora 只读正本迁徙:
https://docs.aws.amazon.com/z…
在创立 MySQL 数据库实例的 Aurora 只读正本时，Amazon RDS 为源 MySQL 数据库实例创立数据库快照（Amazon RDS 公有，不产生费用）。
而后，Amazon RDS 将数据从数据库快照迁徙到 Aurora 只读正本。
在将数据从数据库快照迁徙到新的 Aurora MySQL 数据库集群后，Amazon RDS 开始在 MySQL 数据库实例和 Aurora MySQL 数据库集群之间进行复制。
如果 MySQL 数据库实例中蕴含的表应用 InnoDB 之外的存储引擎，或者应用压缩行格局，您能够在创立 Aurora 只读正本之前批改这些表以应用 InnoDB 存储引擎和动静行格局，从而放慢 Aurora 只读正本的创立过程。
通过 RDS 快照迁徙
您能够迁徙 RDS for MySQL 数据库实例的数据库快照来创立 Aurora MySQL 数据库集群。将应用原始 RDS for MySQL 数据库实例中的数据填充新的 Aurora MySQL 数据库集群。这种办法无奈继续复制变更数据，如果心愿填充到 Aurora 的数据与 RDS 中统一，须要放弃 RDS 只读，通常用于有足够的停机工夫窗口的迁徙。具体步骤可见：将 RDS for MySQL 快照迁徙到 Aurora:
https://docs.aws.amazon.com/z…
如果 MySQL 数据库实例和 Aurora 数据库集群运行雷同版本的 MySQL，您能够将 MySQL 快照间接还原到 Aurora 数据库集群。
如果您要将 MySQL 5.6 版本快照迁徙到 Aurora MySQL 5.7 版本，能够应用以下一种办法执行迁徙：
将 MySQL 5.6 版快照迁徙到 Aurora MySQL 5.6 版，拍摄 Aurora MySQL 5.6 版数据库集群快照，而后将 Aurora MySQL 5.6 版快照还原到 Aurora MySQL 5.7 版。
将 MySQL 版本 6 快照降级到 MySQL 版本 5.7，拍摄 MySQL 版本 5.7 数据库实例的快照，而后将 MySQL 版本 5.7 快照还原到 Aurora MySQL 版本 5.7。
通过 DMS 工作迁徙
此办法在 2 节已叙述，故不再赘述。
总结
本文将向您展现 Graviton2 R6g 数据库实例对 R5 数据库实例的性能加强以及从自建或者托管数据库上迁徙到 Graviton2 R6g 数据库实例的办法流程。通过测试咱们能够分明地看到，无论是何种工作负载和并发条件，R6g 实例比之等同资源配置的 R5 实例性能均有显著的晋升，而每小时单价却有降落，因此 R6g 实例对客户来说，有更好的性价比。
当您按本文步骤进行测试的时候，随着资源配置、数据集、测试负载的不同，须要对命令参数进行微调，测试后果也会相应变动，但测试的思路以及测试后果变动的客观规律却是共通的。除了 sysbench，咱们还有其余的性能测试工具，譬如 mysqlslap 或 tpcc-mysql，本篇限于篇幅，没有介绍，在当前的 blog 中，咱们再做介绍。
参考资料
Amazon Aurora 用户指南：
https://docs.aws.amazon.com/z…
sysbench in github：
https://github.com/akopytov/s…
Amazon Graviton2：
https://aws.amazon.com/cn/ec2…
Amazon RDS for MySQL：
https://aws.amazon.com/cn/rds…
Amazon RDS for PostgreSQL：
https://aws.amazon.com/cn/rds…
Amazon RDS for MariaDB：
https://aws.amazon.com/cn/rds…
本篇作者
吕琳
亚马逊云科技数据库专家架构师
次要负责亚马逊云科技 (中国) 合作伙伴的技术支持工作，同时负责基于亚马逊云科技的云计算计划的征询与架构设计，同时致力于数据库和大数据方面的钻研和推广。在退出亚马逊云科技之前曾在 Oracle 负责高级讲师并在 Amazon 负责高级 DBA，在数据库设计运维调优、DR 解决方案、大数据以及企业应用等方面有丰盛的教训。