性能测试 MySQL 迁移环境：查询回放和流量镜像
性能测试MySQL迁移环境：查询回放与流量镜像 第二部分
关键要点
在这一系列文章中，我们深入探讨了从本地环境迁移的MySQL数据库的性能测试。第二部分将重点介绍如何设置和配置查询回放，并将与第一部分和第三部分相呼应，提供整体解决方案。
这是关于测试MySQL环境性能的系列文章的第二篇，重点是从本地迁移过程中进行性能测试。在第一部分中，我们对查询回放和流量镜像方式进行了高层次的比较。在本篇文章中，我们聚焦于查询回放的设置和配置。在第三部分中，我们将讨论流量镜像的设置和配置。
解决方案概述
对于我们的第一种解决方案，我们将讨论使用Percona ptupgrade 工具的查询回放方法。ptupgrade依赖于捕捉特定时间段的流量，例如繁忙的周末或高峰事件，然后在团队选择的时间对捕捉到的流量进行回放。如果您的应用程序工作负载变化很大，您可能希望从一天的不同时间段捕获慢查询日志输出，以覆盖更广泛的查询类型。
这种解决方案提供了更多的控制权，方便团队在合适的时间进行测试。通过多次回放捕获的流量，该方案还支持一致和可重复的负载测试，有利于对迁移环境进行优化迭代测试。
以下图表展示了使用Percona ptupgrade工具的查询回放架构。
前提条件
完成以下前提条件：
使用Percona XtraBackup创建本地数据库的备份，并恢复该备份以创建本地测试环境。将备份复制到您的Amazon简单存储服务 (Amazon S3) 存储桶。恢复备份，以创建Aurora MySQL兼容数据库。确保在恢复过程中创建的RDS主用户不与当前存储在数据库中的任何用户发生冲突。如果需要测试更新的Aurora MySQL版本，请恢复备份，以建立您的Aurora MySQL数据库，并进行从Aurora MySQL 2兼容57到Aurora MySQL 3兼容80的就地升级。恢复完成后，拍摄数据库集群快照，以便更轻松地重建。实现查询回放
要设置解决方案，请完成以下步骤如解决方案图所示：
步骤13已在前提条件部分中覆盖。
在本地生产MySQL数据库上启用慢查询日志。设置合适的 longquerytime。将值设置为0可以确保捕获所有查询，但可能会对生产数据库增加更大的开销。将慢查询日志复制到具有适当权限和网络访问Aurora MySQL数据库以及本地测试数据库实例的Amazon EC2 实例。在EC2实例上安装ptupgrade，并针对本地测试环境和您想要测试的RDS实例本次为Aurora MySQL 2兼容57运行ptupgrade。为确保MySQL缓冲池足够预热，建议至少运行两次ptupgrade只读测试。为减少测试中的方差，使用的EC2 MySQL生产环境和测试实例在MySQL配置参数方面类似于Amazon RDS for MySQL 57实例。现有环境已完全配置，可以反复执行测试，以验证工程级参数调整后的性能特征。接下来的部分将介绍我们用于测试解决方案的命令及其对应的输出。
场景1：回放完整的慢查询日志
在本次测试中，我们运行了一个持续10分钟的 sysbench oltpreadwritelua 测试，使用16个线程、10个表和100000的表大小，没有使用预编译语句。以下代码显示生成的慢日志的大小：
bash[ec2user@ip100018 ] ls lah grep slowrwr 1 ec2user ec2user 20G Jul 8 1920 ptupgradeslowlog
要运行ptupgrade，请使用只读命令和完整的慢查询日志：
bashptupgrade h=ltendpoint1gt h=ltendpoint2gt u ltusernamegt pltpasswordgt type slowlog ltnameofslowloggtlog 1gtltreportnamegtout 2gtlterrorlognamegtout amp
监控其进展：
bash[ec2user@ip100018 ] tail f auroraprewarmederrout/home/ec2user/ptupgradeslowlog 98 0435 remain/home/ec2user/ptupgradeslowlog 98 0404 remain/home/ec2user/ptupgradeslowlog 98 0333 remain/home/ec2user/ptupgradeslowlog 99 0302 remain/home/ec2user/ptupgradeslowlog 99 0233 remain/home/ec2user/ptupgradeslowlog 99 0203 remain/home/ec2user/ptupgradeslowlog 99 0133 remain/home/ec2user/ptupgradeslowlog 99 0103 remain/home/ec2user/ptupgradeslowlog 99 0033 remain/home/ec2user/ptupgradeslowlog 99 0003 remain
以下是输出报告的一些摘录：
plaintext
主机
host1 DSN h=10039 hostname ip10039euwest2computeinternal MySQL MySQL Community Server (GPL) 5744
host2 DSN h=aurorarestoreclusterc5h2nrbsz4eaeuwest2rdsamazonawscom hostname ip172160131 MySQL MySQL Community Server (GPL) 5744
查询类别 558CAEF5F387E929
由于存在3个查询差异，因此报告该类。
总查询数 3唯一查询数 3丢弃的查询数 0
select c from sbtest where id=
查询时间差：3
10000188 vs 0004073秒 (增幅217倍)
SELECT c FROM sbtest9 WHERE id=37974
20000147 vs 0002020秒 (增幅137倍)
SELECT c FROM sbtest6 WHERE id=50306
30000135 vs 0001403秒 (增幅104倍)
SELECT c FROM sbtest3 WHERE id=51957
统计信息
failedqueries 0notquery 11notselect 2572593queriesfiltered 0queriesnodiffs 5923221queriesread 8575328querieswithdiffs 79503querieswitherrors 0
运行以下命令将使用完整的慢查询日志读/写：
bashptupgrade noreadonly h=ltendpoint1gt h=ltendpoint2gt u ltusernamegt pltpasswordgt ltnameofslowloggtlog 1gtltreportnamegtout 2gtlterrorlognamegtout amp
性能考虑在前面的输出中，我们看到Aurora MySQL 兼容版的延迟性能有时高于社区版MySQL。虽然在测试期间知道这一点是有好处的，但对于Aurora而言，这并不是理想的情况，因为ptupgrade工作负载是在单个数据库连接上回放的，并未生成Aurora擅长的并发工作负载。
从前面的只读输出来看，共有5923221个查询没有性能差异或输出结果，而79503个查询的结果则有不同。根据先前的测试，没有查询被报告为错误，例如对相同查询的不同输出。如果遇到不同输出或错误的查询，您必须调查完整的输出报告如前所示。ptupgrade不会指出查询速度慢的原因或为何产出不同结果；您需要遵循标准的引擎级故障排除流程。
场景2：回放慢查询日志的子集
您可以使用ptquerydigest解析慢查询日志，而不是回放完整的慢查询日志，从而回放一部分查询进行测试。
为生成慢查询日志，可以用ptquerydigest解析慢查询日志，或者替代地使用maxclasssize标志与ptupgrade结合生成带有查询子集的慢查询日志：
bashptquerydigest sample 10 noreport output slowlog ptupgradeslowlog gt parsedloglogptupgradeslowlog 4 1055 remainptupgradeslowlog 9 1000 remain
[ec2user@ip100018 ] ls lah grep parsedloglogrwrwr 1 ec2user ec2user 29K Jun 7 0951 parsedloglog
要运行ptupgrade，请使用以下只读命令：
bashptupgrade h=ltendpoint1gt h=ltendpoint2gt u ltusernamegt pltpasswordgt outputout 1gtltreportnamegtout 2gtlterrorlognamegtout
以下是输出报告的一些摘录：
plaintext
日志
文件 outputout大小 271204
主机
host1 DSN h=10039 hostname ip10039euwest2computeinternal MySQL MySQL Community Server (GPL) 5744
host2 DSN h=aurorarestoreclusterc5h2nrbsz4eaeuwest2rdsamazonawscom hostname ip172160131 MySQL MySQL Community Server (GPL) 5744
查询类别 84D1DEE77FA8D4C3
总查询数 1唯一查询数 1丢弃的查询数 0
select c from sbtest where id between and order by c
查询时间差：1
10000297 vs 0005713秒 (增幅192倍)
SELECT c FROM sbtest5 WHERE id BETWEEN 50287 AND 50386 ORDER BY c
统计信息
failedqueries 0notquery 11notselect 600queriesfiltered 0queriesnodiffs 499queriesread 1111querieswithdiffs 1querieswitherrors 0
如前所述，使用解析日志输出时，读取的查询数量远低于使用完整慢日志输出，因此运行测试所需的时间也显著减少。
考虑事项
ptupgrade支持多种不同选项，可以解析和回放查询：慢查询日志、常规日志、二进制日志和tcpdump。在本篇中，我们主要关注慢查询日志，但也可以使用其他选项。
此外，您可以将ptupgrade与另一个Percona工具ptquerydigest结合使用，以对每个查询指纹进行较少的样本抽取。这可能会在创建用于测试的EC2实例时需要额外的计算资源，因此您可能需要尝试不同的实例配置。
为了确保读取工作负载的一致结果，您必须在开始回放测试之前为数据库设置一致的起始点。可以使用多种工具创建测试环境：MySQL转存、MySQL Shell、mydumper/myloader和Percona XtraBackup。在本篇中，我们使用了Percona XtraBackup。为了减少在迁移过程中遇到的与权限相关的错误，您应该检查当前数据库用户及其相关权限，以确保它们在Amazon RDS上是支持的，但您可以自由使用上述选项之一。
在本博客中，我们主要关注从本地迁移到RDS MySQL/Amazon Aurora MySQL的过程，然而，您也可以使用ptupgrade测试从RDS MySQL到Amazon Aurora MySQL的迁移，或者测试不同数据库引擎版本的性能，例如从Aurora MySQL 2升级到Aurora MySQL 3。
结论
您可以使用ptupgrade测试兼容数据库引擎的查询性能，以及不同的主要和次要版本。尽管该工具可以帮助您找到在不同数据库引擎或版本上性能不佳的查询，但在查询并发性方面仍然存在一些限制。因此，如果在迁移完成之前唯一进行的测试是ptupgrade，您仍可能在迁移后遇到锁定或并发问题。
此外，尽管ptupgrade可以帮助您发现性能不佳的查询，您仍需要使用标准的性能故障排除方法来调查性能问题的根本原因。在这篇文章中，我们展示了如何使用ptupgrade测试Aurora MySQL兼容版的性能，但相同的方法论也适用于Amazon RDS for MySQL的升级和迁移。
若要了解更多关于使用不同方法对生产流量进行负载测试的信息，请参阅本系列的第三部分。
关于作者
Arnab Ghosh 是AWS北美的高级解决方案架构师，帮助企业客户构建弹性和成本效益高的架构。他在架构、设计和开发企业应用程序方面拥有超过15年的经验，致力于解决复杂的商业问题。
Patrick Gryczka 是一名高级解决方案架构师，专注于无服务器技术和体育行业。除了云计算，Patrick还喜欢猫、科幻、Python和Rust。
鲸鱼加速器最新版Simon Stewart 是AWS的数据库专家解决方案架构师，专注于MySQL和Amazon Aurora MySQL。Simon帮助AWS客户设计架构并提供高效的数据库解决方案。在不帮助客户管理AWS数据库时，他喜欢研究自己的家庭实验室。