优化 Aurora MySQL 的二进制日志复制 - Amazon Aurora
多线程二进制日志复制优化二进制日志复制
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

优化 Aurora MySQL 的二进制日志复制

接下来，您可以了解如何优化二进制日志复制性能和排查 Aurora MySQL 中的相关问题。

提示

本讨论假定您熟悉 MySQL 二进制日志复制机制及其工作原理。有关背景信息，请参阅 MySQL 文档中的复制实施。

多线程二进制日志复制

使用多线程二进制日志复制时，SQL 线程会从中继日志中读取事件并将其排队，以便 SQL 工作线程应用。SQL 工作线程由协调器线程管理。尽可能并行应用二进制日志事件。并行度级别取决于版本、参数、架构设计和工作负载特性等因素。

Aurora MySQL 版本 3 和 Aurora MySQL 2.12.1 及更高版本支持多线程二进制日志复制。为了使多线程副本能够高效地并行处理二进制日志事件，您必须为多线程二进制日志复制配置源，并且源使用的版本必须包含有关其二进制日志文件中的并行度信息。

当 Aurora MySQL 数据库实例配置为使用二进制日志复制时，默认情况下，副本实例对低于 3.04 的 Aurora MySQL 版本使用单线程复制。要启用多线程复制，请在您的自定义参数组中将 replica_parallel_workers 参数更新为大于 1 的值。

对于 Aurora MySQL 版本 3.04 及更高版本，复制默认是多线程的，replica_parallel_workers 设置为 4。您可以在自定义参数组中修改此参数。

为了提高数据库在意外中断时的弹性，我们建议您在源上启用 GTID 复制，并在副本上支持 GTID。要支持 GTID 复制，请同时在源和副本上将 gtid_mode 设置为 ON_PERMISSIVE。有关基于 GTID 的复制的更多信息，请参阅使用基于 GTID 的复制。

以下配置选项可以帮助您优化多线程复制。有关使用信息，请参阅 MySQL 参考手册中的复制和二进制日志记录选项和变量。有关多线程复制的更多信息，请参阅 MySQL 博客 Improving the Parallel Applier with Writeset-based Dependency Tracking。

最佳参数值取决于多个因素。例如，二进制日志复制的性能受数据库工作负载特征和副本运行所在的数据库实例类的影响。因此，建议您在将新参数设置应用于生产实例之前，彻底测试对这些配置参数的所有更改：

  • binlog_format recommended value – 设置为 ROW

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking：建议值为 WRITESET

  • replica_preserve_commit_order

  • replica_parallel_type：建议值为 LOGICAL_CLOCK

  • replica_parallel_workers

  • replica_pending_jobs_size_max

  • transaction_write_set_extraction：建议值为 XXHASH64

您的架构和工作负载特征是影响并行复制的因素。最常见的因素如下。

  • 缺少主键：RDS 无法为没有主键的表建立写集依赖关系。使用 ROW 格式，可以通过在源上进行单次全表扫描来完成单个多行语句，但会导致对在副本上修改的每一行都进行一次完整表扫描。缺少主键会显著降低复制吞吐量。

  • 存在外键：如果存在外键，Amazon RDS 就无法使用写集依赖关系来实现表与 FK 关系的并行性。

  • 事务大小：如果单个事务跨越数十或数百兆字节或千兆字节，则协调器线程和其中一个工作线程可能会花很长时间只处理该事务。在此期间，所有其它工作线程在完成对先前事务的处理后可能会保持空闲状态。

在 Aurora MySQL 版本 3.06 及更高版本中，在为具有多个二级索引的大型表复制事务时，可以提高二进制日志副本的性能。此功能引入了一个线程池，用于在二进制日志副本上并行应用二级索引更改。该功能由 aurora_binlog_replication_sec_index_parallel_workers 数据库集群参数控制，该参数控制可用于应用二级索引更改的并行线程总数。默认情况下，此参数设置为 0（禁用）。启用此功能不需要重启实例。要启用此功能，请停止正在进行的复制，设置所需的并行工作线程数，然后重新开始复制。

优化二进制日志复制

在 Aurora MySQL 2.10 及更高版本中，Aurora 会自动将称为二进制日志 I/O 缓存的优化应用于二进制日志复制。通过缓存最近提交的二进制日志事件，此优化旨在提高二进制日志转储线程性能，同时限制对二进制日志源实例上前台事务的影响。

注意

用于此功能的内存独立于 MySQL binlog_cache 设置。

此功能不适用于使用 db.t2 和 db.t3 实例类的 Aurora 数据库实例。

您无需调整任何配置参数即可启用此优化。特别是，如果您在早期 Aurora MySQL 版本中曾将配置参数 aurora_binlog_replication_max_yield_seconds 调整为非零值，请为当前可用版本设置回零。

状态变量 aurora_binlog_io_cache_reads 和 aurora_binlog_io_cache_read_requests 可帮助您监控从二进制日志 I/O 缓存读取数据的频率。

  • aurora_binlog_io_cache_read_requests 显示来自缓存的二进制日志输入/输出读取请求的数量。

  • aurora_binlog_io_cache_reads 显示从缓存检索信息的二进制日志输入/输出读取的数量。

以下 SQL 查询计算利用缓存信息的二进制日志读取请求的百分比。在此情况下，比率越接近 100，就越好。

mysql> SELECT
  (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
  / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
    WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
  * 100
  as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
|         99.99847949080622 |
+---------------------------+

二进制日志 I/O 缓存功能还包括与二进制日志转储线程相关的新指标。转储线程是当新的二进制日志副本连接到二进制日志源实例时创建的线程。

转储线程指标每 60 秒输出到数据库日志中一次，并带有前缀 [Dump thread metrics]。这些指标包括每个二进制日志副本的信息，例如，Secondary_id、Secondary_uuid、二进制日志文件名以及每个副本读取的位置。这些指标还包括 Bytes_behind_primary，表示复制源和副本之间的距离（以字节为单位）。此指标衡量副本 I/O 线程的滞后。该数字不同于副本 SQL 应用程序线程的滞后，后者通过二进制日志副本上的 seconds_behind_master 指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。