优化 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
参数更新为大于零的值。
对于 Aurora MySQL 版本 3.04 及更高版本,复制默认是多线程的,replica_parallel_workers
设置为 4
。您可以在自定义参数组中修改此参数。
以下配置选项可以帮助您优化多线程复制。有关使用信息,请参阅 MySQL 参考手册中的复制和二进制日志记录选项和变量
最佳配置取决于多个因素。例如,二进制日志复制的性能受数据库工作负载特征和副本运行所在的数据库实例类的影响。因此,建议您在将新参数设置应用于生产实例之前,彻底测试对这些配置参数的所有更改:
-
binlog_group_commit_sync_delay
-
binlog_group_commit_sync_no_delay_count
-
binlog_transaction_dependency_history_size
-
binlog_transaction_dependency_tracking
-
replica_preserve_commit_order
-
replica_parallel_type
-
replica_parallel_workers
在 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
指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。