介绍亚马逊 Aurora MySQL 增强型二进制日志 (binlog)

Amazon Aurora 是一个兼容 MySQL 和 PostgreSQL 的关系数据库，专为云而构建。Aurora 将传统企业数据库的性能和可用性与开源数据库的简单性和成本效益相结合。Aurora 有围绕数据库引擎和运行数据库的底层基础设施进行创新的历史，同时保持兼容性。MySQL 数据库引擎的一个常用功能是二进制日志 (binlog)。binlog 记录了对数据库所做的更改，用于各种工作负载，例如使用只读副本进行灾难恢复、用于数据流的变更数据捕获、事件驱动架构和分析。

2023年5月22日，亚马逊云科技 宣布 在Aurora MySQL 3上推出新的增强二进制日志（与MySQL 8兼容）。增强的二进制日志降低了启用二进制日志的计算开销，在某些情况下，二进制日志最多可以达到50％，降至13％。这反过来又允许在同一硬件上增加吞吐量。与启用社区二进制日志时的恢复相比，增强的二进制日志还可以将启用二进制日志时的数据库恢复时间缩短多达99％。在这篇文章中，我们深入探讨了 Aurora MySQL 增强版 binlog、它解决的常见挑战以及为使其成为可能而进行的创新。

使用binlog面临的挑战

MySQL 二进制日志用途广泛，使用广泛；但是，许多客户在启用 binlog 时会发现性能受损。这种性能下降是由计算资源争用造成的，因为启用 binlog 时，除了事务之外，数据库还必须做额外的工作来处理 binlog。Binlog 必须维护对数据库所做更改的提交顺序。这是通过在提交工作流程中为事务添加一个额外的过程来实现的，该过程与每个事务串行写入二进制日志文件。在提交时使用两阶段提交 (2PC) 来同步写入事务日志和二进制日志，这会增加写入延迟。Aurora MySQL 也继承了这些挑战。Aurora 中计算和存储的分离是一项开创性的创新，它解决了数据库的主要挑战之一——吞吐量。但是，这种架构有时可能会放大写入二进制日志时的性能影响，这是因为写入二进制日志文件时需要更多的协调工作和网络跳转。此外，启用 binlog 后，如果重启或故障转移，Aurora 可能会经历额外的恢复时间，因为必须通过回滚或向前滚事务来读回和恢复 binlog。值得注意的是，Aurora MySQL 架构不需要 binlog 来恢复数据库或 Aurora 的区域内和全球数据库复制。Binlog 是一项可选功能，您可以为各种用例启用。

Aurora MySQL 增强版

为了克服一些性能挑战，我们在2021年首次推出了 binlog I/O缓存 。二进制日志 I/O 缓存通过将最新的二进制日志事件保留在其循环缓存中，最大限度地减少了来自 Aurora 存储引擎的读取 I/O。Aurora MySQL 的二进制日志 I/O 缓存显示，在二进制日志复制设置中，吞吐量提高了 5 倍以上。

现在，在 Aurora MySQL 3.03 及更高版本中，我们对二进制日志的编写和存储方式进行了额外的、更根本的更改。这种增强的二进制日志降低了启用二进制日志的性能开销，在某些情况下，二进制日志最多可以达到50％，降至13％。这反过来又允许在同一硬件上增加事务处理吞吐量。

第一项创新来自将事务日志的存储与二进制日志的存储分开。现在，Aurora MySQL 没有使用同一个存储节点来存储事务和二进制日志，而是将二进制日志存储在针对二进制日志进行了优化的专用存储节点上。这些存储节点添加了逻辑，使数据库引擎可以将二进制日志的排序和排序下推到存储层。这使我们能够提高并行度，减少锁定，缩短写入事务日志和二进制日志时数据库引擎中的两阶段提交时间，同时仍然实现有序写入。这些架构改进极大地提高了 Aurora MySQL 的二进制日志写入性能。下图显示了社区二进制日志（上）和新的增强二进制日志（下图）之间事务日志和二进制日志事件的写入方式的比较。

图 1：社区二进制日志（顶部）和增强版二进制日志（底部）提交阶段。

启用 binlog 后，这些更改还有助于改善数据库故障转移和一般恢复性能。凭借其分布式存储层，Aurora MySQL 能够并行和无序恢复。但是，启用二进制日志后，除了数据库恢复外，还必须恢复二进制日志以确保其处于一致状态。在崩溃恢复期间，启用社区二进制日志时，Aurora MySQL 必须按顺序读取二进制日志文件以确认应向前还是向后滚动交易。这种增加的开销可能会影响 Aurora 数据库的总恢复时间，尤其是在必须回滚大型事务的情况下。增强的二进制日志在存储层添加了逻辑，因此无需按顺序扫描二进制日志文件。取而代之的是，在保持一致性的同时，以更具选择性的方式恢复交易。这最多可将二进制日志的恢复时间缩短99％。因此，数据库恢复时间从多达几分钟缩短到几秒钟。

启用增强版二进制日志

要启用增强二进制日志，请将 a urora_enhanced_binlog 集群参数的值设置为 1，将 binlog_backup 和 binlog_replication_globald b 集群参数设置为 0。 这些是静态参数，因此必须重新启动写入器实例才能使更改生效。您可以在社区二进制日志和增强二进制日志之间切换，Aurora MySQL 将跟踪每个二进制日志文件的存储位置以提供连续的序列。如果您决定关闭该功能，则可以通过更改这三个集群参数的值并重新启动写入器实例来实现。以下代码块显示了通过 亚马逊云科技 命令行接口 (亚马逊云科技 CLI) 启用增强二进制日志的示例。

aws rds modify-db-cluster-parameter-group --parameter-group-name <parameter group name> parameters  [ \
{ \
"ParameterName": "aurora_enhanced_binlog", \
"ParameterValue": "1" \
"ParameterName": "binlog_backup", \
"ParameterValue": "0" \
"ParameterName": "binlog_replication_globaldb ", \
"ParameterValue": "0" \
} \
]

增强的二进制日志性能对比

提高性能是使用增强版 binlog 的主要好处。增强的二进制日志降低了启用二进制日志对性能的影响，因此您可以每秒处理更多事务。我们使用 sysbench 对 db.r6g.8xlarge 和 db.r6g.16xlarge 实例类 10 次测试迭代中实现的平均吞吐量进行了基准测试。重复测试，线程数从 25 到 4000 不等。数据显示，在具有高交易吞吐量要求且性能真正重要的大型实例中，增强型 binlog 通过减少写入器实例上的计算争用来提高交易吞吐量。以下图表显示了使用社区二进制日志和增强二进制日志之间的比较，以及使用增强二进制日志时事务处理性能的提高。

图 2：db.r6g.8xlarge 上的每秒事务数 (TPS) 扩展结果

图 3：db.r6g.16xlarge 上的每秒事务数 (TPS) 扩展结果

下表包含与上图所示相同的数据，还包括改善百分比。

提高性能的第二个方面是数据库恢复。我们比较了启用社区二进制日志和启用增强二进制日志之间的数据库恢复结果差异。您可以看到一系列工作负载的恢复时间差异，如下图所示（图 4）。随着二进制日志交易规模的增加，社区二进制日志需要更长的时间才能恢复，而增强的二进制日志恢复时间在一秒钟内保持稳定。

图 4：二进制日志恢复时间改进

第二张图表（图 5）显示了数据库恢复的总体改进，介于 92% 到 99% 之间。

图 5：总体数据库恢复时间缩短

下表包含与上图所示相同的数据，还包括改善百分比。

局限性

对于许多用例，启用增强型 binlog 可以提高数据库的性能。但是，需要记住一些限制。当 Amazon Aurora 全球数据库 与增强型二进制日志一起使用时，您的二进制日志文件不会复制到您的跨区域副本，因此在故障转移后它们不可用。跨区域故障转移后，如果启用了增强二进制日志，则新升级的集群将开始从新文件序列开始写入二进制日志文件。从快照恢复集群或克隆数据库后也存在类似的限制。与社区二进制日志相比，启用增强版二进制日志将导致行为发生变化。使用增强版 binlog，尽管在原始群集上设置了任何保留期，但新恢复的数据库集群或克隆将无法使用原始二进制日志文件。相比之下，社区二进制日志将在新恢复或克隆的集群上保留二进制日志文件并使其可用。最后，增强版 binlog 不能用于曾经使用过 Backtrack 的集群或已从使用 Backtrack 的集群中恢复的集群。如需更多信息，请参阅增强版 binlog 文档 。

成本

与二进制日志相比，使用增强版二进制日志没有额外费用。您继续使用 Aurora 集群的一部分计算、存储和 IO 成本为二进制日志的写入、读取和存储付费。由于增强的二进制日志文件存储在单独的存储节点上，而不是数据库的事务日志中，因此增强的二进制日志文件不包含在备份文件中。这可能会降低备份存储的成本。您仍需为集群使用的总数据存储空间付费，包括二进制日志和数据文件。

结论

在这篇文章中，我们讨论了现在可在Aurora MySQL 3.03及更高版本上使用的新的增强二进制日志。增强二进制日志的好处是，由于减少了计算争用，提高了吞吐量，启用了二进制日志可以缩短数据库恢复时间。您可以立即访问数据库控制台并 启动 Aurora 实例 ，开始使用 Aurora MySQL 增强版二进制日志。有关更多信息，请查阅 文档 。

作者简介

Aditya Samant 是关系数据库行业的资深人士，在使用商业和开源数据库方面拥有 20 多年的经验。多年来，他担任过许多职务，包括数据库顾问、专业支持、DBA 和数据库架构师。他目前在亚马逊网络服务担任高级数据库专家解决方案架构师。在他目前的职位上，他花时间与客户合作设计可扩展、安全和强大的云原生架构。Aditya还帮助服务团队设计和交付亚马逊旗舰关系数据库Amazon Aurora的开创性功能。

亚当·莱文 是位于加州的亚马逊 Aurora 团队的产品经理。在过去的十年中，他一直在研究各种云数据库服务。