亚马逊Aurora MySQL版本3中的二进制日志优化 数据库博客
亚马逊 Aurora MySQL 版本 3 的二进制日志优化
作者：Marc Reilly，发布日期：2024 年 5 月 17 日，来源于 高级 (300)，Amazon Aurora，MySQL 兼容，思想领导力永久链接评论 分享
关键要点
在这篇文章中，我们探讨了亚马逊 Aurora MySQL 中的二进制日志的优化以及重要功能的提升。这些改进使客户能够利用变更数据、新用例的开发，并提高数据库性能和恢复时间。
在 MySQL 中，二进制日志binlog用于捕获数据库修改，以逻辑格式记录为“事件”。这些修改包括 DCL 语句如 CREATE USER 或 GRANT、DDL 语句CREATE TABLE，ALTER TABLE和 DML 语句INSERT、UPDATE、DELETE。当 MySQL 中的某项修改被提交时，服务器以 2 阶段提交2PC方式原子性地持久化事务的二进制日志事件。这种 ACID原子性、一致性、隔离性和持久性合规性和数据库变更的记录，使得 MySQL 能够利用这些日志实现对其他 MySQL 服务器的逻辑复制只读副本、协助数据库恢复过程，并提供通过在完整数据库备份上再次应用逻辑变更来恢复数据库实例到某一时间点的能力。
然而，强制执行这种 ACID 合规性可能带来一些问题，包括写入放大、较长的数据库恢复时间以及在高并发下的锁竞争。对于时间点恢复PITR和使用只读副本进行横向扩展，二进制日志必须在数据库服务器上进行逻辑重放。这可能导致延迟以及在重写负载下增加的恢复时间目标RTO。例如，当 DDL 语句需要复制到只读副本或备用服务器时，这可能会阻塞其他日志事件的应用，直至完成。
自 2015 年发布 Amazon Aurora MySQL 兼容版 以来，客户不再需要依赖二进制日志来满足这些要求。在 Amazon Aurora 的自定义构建存储架构中，复制、恢复和 PITR 都在存储层透明地处理，无需启用二进制日志。这些创新使您能够将高并发工作负载扩展到数十万次写入每秒，同时确保跨可用区和 AWS 区域的复制延迟仅为毫秒，并且不会牺牲恢复时间或 ACID 合规性。
在这篇文章中，我们讨论了亚马逊 Aurora MySQL 中二进制日志的使用案例、近年来添加的改进能力以及对 MySQL 原生二进制日志功能的额外支持。
二进制日志的使用案例
尽管在 Amazon Aurora MySQL 中不需要二进制日志以实现高可用性或横向可扩展性，但仍有一些使用案例可以利用这个数据库变更日志，例如：
在迁移到 Amazon Aurora MySQL 时，可以利用二进制日志复制，将 Amazon Aurora MySQL 配置为 MySQL 数据库实例的二进制日志只读副本，以实现最小停机时间迁移。详情请查阅 将数据迁移到 Amazon Aurora MySQL DB 集群。使用 亚马逊 RDS 蓝绿部署，可以在生产系统上减少停机时间，例如执行主要版本升级，利用逻辑二进制日志复制。可以使用 Amazon Aurora 的零 ETL 集成与 Amazon Redshift 或工具如 Maxwell 和 Debezium 将数据库变更流式传输到其他源，如缓存、数据仓库或数据湖。利用在线模式更改工具，如 Spirit 和 ghost，可以以最小的影响进行生产系统的模式更改。改进的二进制日志能力
根据客户的使用案例和反馈，Amazon Aurora MySQL 团队通过支持更多的社区功能，并优化 Aurora MySQL 中二进制日志的实现，来提高其能力。这些改进的重点包括了以下四个主要领域。
二进制日志复制消费者线程
在 Amazon Aurora MySQL 版本 210 中，我们引入了 二进制日志 I/O 缓存。二进制日志 I/O 缓存旨在通过在写入 DB 实例上保持最新的二进制日志变更事件的循环缓存，来最小化来自 Aurora 存储层的读取 I/O。这种 I/O 延迟的改善帮助提高了复制消费者线程获取变更日志事件的速率，并减少锁竞争，尤其是在高并发写入工作负载下，前台事务和二进制日志消费者可能会争抢活跃二进制日志文件上的锁。如需了解更多信息，请参阅 在 Amazon Aurora MySQL 中引入二进制日志 I/O 缓存以提升 binlog 性能。
正如之前所提到的，二进制日志的常见使用案例之一是从 Aurora MySQL 数据库集群流式传输数据库变更到其他源。在 Amazon Aurora MySQL 版本 305 中，我们引入了与 Amazon Redshift 零 ETL 的集成。这个集成使得在填充数PB的交易数据中，用户能使用 Amazon Redshift 实现近实时分析和机器学习(ML)。在事务数据写入 Aurora 几秒钟内，零 ETL 就使数据在 Amazon Redshift 中可用，消除了构建和维护执行提取、转换和加载ETL操作的复杂数据管道的必要性。此外，使用 Amazon Aurora 零 ETL 集成与 Amazon Redshift，用户不再需要使用 Maxwell 和 Debezium 等工具去设置和配置变更数据捕获基础设施，Aurora MySQL 会自动设置和管理变更数据捕获基础设施，直接将变更流式传输到 Amazon Redshift 数据仓库。
二进制日志复制应用程序线程
在 Amazon Aurora MySQL 版本 305 中，我们还引入了针对 Amazon Aurora MySQL 二进制日志副本的内存 中继日志 缓存。此改进可以帮助实现二进制日志复制的吞吐量比未启用 中继日志 缓存的数据库集群增加高达 40 的提升。当使用单线程二进制日志复制或在启用 GTID 自动定位 时，这一增强会自动启用。
在 Amazon Aurora MySQL 版本 306 及更高版本中，我们引入了一项优化，改善大型表的二进制日志副本在复制事务时的性能。此功能引入了一个后台线程池，在 Aurora MySQL 的二进制日志副本中并行应用二级索引变更，补充了已有的 replicaparallelworkers 功能。如需了解更多有关启用此优化的信息，请参阅 优化二进制日志复制。
一元机场官网推荐DML 吞吐量和延迟
为优化二进制日志提交过程，MySQL 实施了一系列优化，例如 二进制日志组提交，以更高效地将变更写入二进制日志，同时不影响事件的次序。然而，这一同步点可能会在高写入吞吐量工作负载的数据库实例上引入争用区域。
在 Amazon Aurora MySQL 版本 3031 中，我们引入了 Amazon Aurora MySQL 增强型二进制日志增强型二进制日志。此功能允许数据库引擎充分利用 Aurora 分布式存储，减少与存取相关的争用，将二进制日志变更事件的顺序移交给 Aurora 存储层，确保提交顺序和已提交事务的持久性不受影响。根据 引入 Amazon Aurora MySQL 增强型二进制日志binlog 中的测试，这些优化帮助在与未启用增强型二进制日志的数据库集群相比，提供了高达 40 的吞吐量提升。
二进制日志恢复
在事务提交时，必须将二进制日志事件以正确的提交顺序写入活动的二进制日志文件并确保持久性。对于生成大量二进制日志数据的事务，启动期间的二进制日志恢复过程涉及扫描整个二进制日志文件以收集事务的元数据，并使用这些数据确保与存储引擎InnoDB数据的一致性。如果二进制日志文件很大，这可能需要几分钟或更长时间，与之成比例地影响二进制日志恢复时间。
正如前面讨论的，增强型二进制日志还改善了 MySQL 的二进制日志恢复过程。借助增强型二进制日志，时间较长的二进制日志文件扫描过程通过 Aurora 分布式存储层的优化而被避免。
得益于这些改进，二进制日志恢复时间可减少高达 99，从几分钟缩短至几秒钟。下表总结了这些恢复时间。
事务大小Binlog 恢复时间秒总引擎恢复时间秒社区 Binlog增强版 Binlog1 GB303420475 GB12963905050 GB1587949061有关更多信息，请参阅 介绍 Amazon Aurora MySQL 增强型二进制日志binlog。
额外的 MySQL 支持
除了我们已经讨论的 Amazon Aurora MySQL 优化外，还添加了对原生 MySQL 社区功能的支持，这些支持在 Aurora MySQL 的版本 1 和 2 中均没有。
在 Amazon Aurora MySQL 版本 3010 中，我们新增了对二进制日志复制过滤器的支持。复制过滤器允许您配置哪些内容会写入二进制日志文件以及哪些内容会在二进制日志只读副本上应用。这一功能对选择性复制特定表或数据库到只读副本数据库实例的用例非常有用。如需了解有关复制过滤器的更多信息，请参见 在 Aurora MySQL 中配置复制过滤器。
随着 MySQL 8 中 动态权限 的增加，某些受限的会话变量可在 SESSIONVARIABLESADMIN 数据库权限下使用。在 Amazon Aurora MySQL 版本 3 中，具备此权限的用户可以在会话级别执行以下操作：
现在可以修改 sqllogbin。如果您想执行不希望被记录到二进制日志中的操作例如归档作业或不希望复制到二进制日志消费者的 DDL 语句，这将十分有用。在 Amazon Aurora MySQL 版本 2 中，您无法在本地设置 sqllogbin，但在版本 212 中新增了 mysqlrdsdisablesessionbinlog 和 mysqlrdsenablesessionbinlog 存储过程，以允许您执行这些操作。此外，您可以在会话级别修改 binlogformat。有三种二进制日志格式：行ROW、混合MIXED和语句STATEMENT。在大多数用例中，推荐使用基于行的日志，这将为 MySQL 服务器上进行的每个行变更记录一个变更事件。然而，在某些情况下，这会导致冗余，例如在执行大批量 UPDATE/DELETE 操作进行归档或数据清除时。另一个流行的用例是使用开源工具 pttablechecksum，这需要将 binlogformat 设置为语句。通过 binlogformat，您现在可以在会话级别原生地更改 binlog 格式，以适应这些操作。在 Amazon Aurora MySQL 版本 2 中，您无法以本地方式在会话级别设置 binlogformat，但在版本 212 中新增了 mysqlrdssetsessionbinlogformat 存储过程以允许您执行此操作。在 Amazon Aurora MySQL 版本 304 中，新增了 mysqlrdsgtidpurged 存储过程。该 gtidpurged 系统变量是一个 GTID 集合，包含了服务器上已经提交但在任何二进制日志文件中不存在的所有事务的 GTID。此功能常用于配置 MySQL 数据库服务器之间的二进制日志复制自动定位，从而使用户更容易配置复制。有关 MySQL 中 GTID 的更多信息，请参见 使用全局事务标识符 (GTID) 进行复制。
结论
在这篇文章中，我们讨论了亚马逊 Aurora MySQL 中二进制日志的优化和改进。这些渐进式的变化使客户能够利用变更数据，开发新用例，并提高数据库性能和恢复时间。
若要了解有关新版本及功能的更多信息，请参考我们的 发布说明，并订阅 RSS 源，以便接收新版本的通知。
有关 Amazon Aurora MySQL 中二进制日志的更多信息，请查看 配置 Aurora MySQL 二进制日志。
关于升级到 Amazon Aurora MySQL 版本 3 的更多信息，请参阅 [Aurora MySQL 版本 3 兼容 MySQL 80](