MySQL迁移环境性能测试的两种方法

关键要点

将MySQL数据库从本地环境迁移到AWS带来了诸多优势。然而在处理多个应用程序的遗留集中式数据库时，这个过程可能会面临挑战。确保您的云设置能够处理现实生产流量是此过程中的一项关键步骤。

现实地模拟数据流和查询模式可能是一个复杂的任务，这可能会延迟团队自信迁移的能力。尽管合成测试可以提供新的系统评估基准，并为迁移过程的第一步提供良好开端，但最好用真实世界的测试来补充合成测试，以验证您的查询和工作负载。这能更好地确保新平台能够处理您在现实世界中的流量，并提供更深入的洞察新环境下工作负载的表现。

在这一系列的文章中，我们将深入探讨从本地迁移到AWS的MySQL环境性能测试。在本篇文章中，我们回顾了两种不同的测试迁移环境的方法，这两种方法捕获和重新播放代表真实生产流量的流量：使用回放应用程序捕获和重放流量，以及通过代理镜像流量。这样您便可以以现实的数据访问模式来验证您的环境。

第二部分将深入探讨查询回放的设置与配置， 第三部分将涉及流量镜像的设置与配置。

在本系列博客中，我们专注于本地迁移到AWS的环境。然而，ptupgrade 和ProxySQL的流量镜像也可以用于测试RDS MySQL到Amazon Aurora的迁移，以及测试RDS MySQL和Amazon Aurora的引擎更新后的工作负载表现。

查询回放架构

在第一个解决方案中，我们讨论了查询回放。查询回放不同于流量镜像，因为它不在第二个环境中并行镜像流量，而是依赖于捕获一段时间的流量，比如一个繁忙的周末或峰值流量事件，然后在团队选定的时间重放这些记录的流量以测试另一个环境。

这种解决方案可以让您的团队在方便的时候进行测试。由于您可以多次重放捕获的流量，这种解决方案也支持一致和可重复的负载测试，使得您能够针对优化迁移环境进行迭代测试。

针对查询回放，我们聚焦于最近更新的Percona ptupgrade 工具；Percona还提供一个较旧的工具，Query Playback。

以下图示展示了使用Percona ptupgrade工具的查询回放架构。

该工作流程包括以下步骤：

备份生产数据库。将备份上传至亚马逊简单存储服务Amazon S3。将备份恢复为AWS中的迁移数据库及本地测试数据库。在生产数据库上启用慢日志，并将其复制到正在运行ptupgrade的亚马逊弹性计算云Amazon EC2实例或虚拟机VM。对迁移数据库和本地测试数据库运行ptupgrade工具。

捕获用于测试的查询集是第一步，这可以通过启用源数据库上的慢查询日志来完成。请注意，启用生产数据库上的慢查询日志会对性能产生影响，因此请查看文档中的“总体考虑”部分以获取更多详细信息。接下来，需要将Percona ptupgrade工具设置为以慢日志作为输入，并对本地测试数据库和迁移数据库实例运行。这将生成展示性能差异的结果。根据您希望托管ptupgrade工具的位置，可能会对某个数据库连接产生小的延迟开销。在本例中，我们展示了针对Amazon Aurora MySQL兼容版数据库进行的查询测试，但针对迁移至亚马逊关系数据库服务Amazon RDS的模式、亚马逊EC2上的MySQL以及其他MySQL兼容选项，模式也是相同的。

在第二部分中，我们将重点使用Percona ptupgrade。

查询回放注意事项

为了获得一致的非只读工作负载的结果，您需要在重放测试之前确保数据库具有一致的起点。这可以通过从快照或源数据库的mysql转储中重新加载迁移环境的数据库来实现。我们在我们的架构中使用Percona XtraBackup。

除了重放流量到AWS的目标迁移环境外，我们还在本地设置了一个测试环境，存有生产数据库的副本。将流量重放到此副本使得可以更清晰地比较目标AWS环境和本地测试环境之间的性能，这排除了生产数据库中因日志记录而引起的过程成本。

数据库流量镜像架构

在我们的第二种解决方案中，我们讨论了如何使用ProxySQL从本地生产工作负载镜像SQL查询流量到AWS的迁移环境。以下图示展示了一个示例架构。

该工作流程包括以下步骤：

在这个例子中，我们展示了流量镜像至Aurora MySQL数据库。针对迁移至亚马逊RDS for MySQL、亚马逊EC2上的MySQL及其他MySQL兼容选项，模式同样适用。

与查询回放架构一样，我们还在本地设置了一个测试环境，存有生产数据库的副本。将流量重放到此副本和AWS迁移环境使得可以更清晰地比较目标AWS环境和本地测试环境的性能，排除因日志记录等流程在生产数据库中运行而对比较产生的影响。

我们还使用了AWS Direct Connect提供确保带宽的连接，以避免在负载测试中引入不必要的变量。

此方法要求在镜像之前，您的迁移环境需要与本地环境同步，或者通过二进制日志复制或其他数据迁移工具进行同步。

在本系列的第三部分中，我们将重点讨论如何使用ProxySQL从本地设置流量镜像。

流量镜像注意事项

重要的是要彻底测试并建立监控，以理解ProxySQL的镜像开销对您应用程序延迟的影响。这有助于确保您可以充分利用ProxySQL所提供的好处，同时避免意外的性能下降。通过主动评估延迟的影响，您可以做出明智的决策和调整，以优化应用程序的性能并提供无缝的用户体验，即使引入了ProxySQL层。

为了保证迁移过程的有效性和成功性，建立源环境与目标环境之间的数据一致性至关重要。通过验证两者环境中的数据对齐，您可以确保后续对迁移环境的评估将提供准确、可操作的见解。这一主动措施帮助您为迁移奠定坚实基础，使您能及早识别和解决任何不一致问题。优先考虑数据一致性是一项基本的最佳实践，这将在整个迁移过程中带来回报。

ProxySQL能够将流量镜像到多个目标，为您的迁移过程提供了灵活度。这一能力允许您创建生产环境的本地副本以及托管在Amazon RDS上的单独副本。通过拥有这两个独立的环境，您可以在真实条件下彻底测试应用程序的行为和性能，而不冒险影响您的实时生产系统。

这种方法的有效性直接受限于您生产流量的特征。通过基于实际流量源进行测试和评估，您可以获得与现实条件紧密相关的有价值洞见。这确保了您的迁移规划和准备是建立在您实时环境的现实基础之上。然而，如果您在高峰流量期间的负载发生不频繁，则可能需要采取额外措施或在不同的时间窗口进行测试以提供广泛的覆盖范围。

总体考虑事项

在选择您的策略时，请考虑以下几点：

确定用于测试的查询集 使用慢查询日志捕获查询是一种常见策略。尽管将longquerytime参数设置为0可以捕获所有查询，但必须注意对生产实例性能的潜在影响。请注意，如果longquerytime参数未设置为0，则可能不会捕获对生产数据库执行的所有查询。在这种情况下，重放与您原始生产流量不完全一致。通过使用本地测试数据库，您仍然可以获得本地测试数据库和迁移数据库实例之间的类似比较，尽管只是生产流量的一个子集。作为最佳实践，我们建议从较高的longquerytime值开始。这种更保守的方法允许您监控对生产环境的影响，确保没有意外的性能问题。如果您发现较高的longquerytime值对您的生产实例没有显著影响，则可以考虑逐渐降低该值以捕获更大体量的查询。这一迭代过程使您能够在综合数据收集和保持实时环境稳定性之间找到平衡。

在测试中保持数据和安全合规 组织在其生产和测试环境中通常有不同的安全和合规规定或标准。通过主动步骤让您的迁移测试环境与生产系统保持一致，您可以确保您的测试活动以安全和合规的方式进行。

高层次的差异化 请注意以下两种解决方案的区别：

结论

在本篇文章中，我们回顾了将生产流量回放和镜像到新迁移环境的两种方法，使得可以直接比较本地环境的全部或部分工作负载。这确保了在将流量切换到云上之前，对性能进行适当验证。这些方法使您可以对迁移项目采取积极、以数据为驱动的方法。与其依赖假设或猜测，不如基于源环境与目标环境之间的性能比较做出明智的决策。在本系列的后续文章中，我们将深入探讨每个工具的使用。关于查询回放的更多细节，请参见第二部分。有关流量镜像，请参见第三部分。

有关AWS环境之间流量镜像的更多信息，请参考使用VPC流量镜像将生产流量镜像到测试环境。要了解有关ProxySQL的更多信息，请访问ProxySQL网页。有关Percona Query Playback工具的详细信息，请访问GitHub仓库。

作者介绍

Arnab Ghosh 是AWS北美的资深解决方案架构师，帮助企业客户构建高效且节省成本的架构。他在架构、设计和开发企业应用程序方面拥有超过15年的经验，旨在解决复杂的商业问题。

Patrick Gryczka 是一名专注于无服务器技术和体育行业的资深解决方案架构师。在云计算之外，Patrick还喜欢猫，科幻小说，Python和Rust。

Simon Stewart 是AWS的数据库专家解决方案架构师，专注于MySQL和Amazon Aurora MySQL。Simon帮助AWS客户进行架构设计，并为其数据库工作负载提供高效的解决方案。当他不在AWS上帮助客户处理数据库时，他喜欢研究自己的家庭实验室。