Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)
Amazon Aurora MySQL 与 MySQL 兼容,因此您可以在 MySQL 数据库与 Amazon Aurora MySQL 数据库集群之间设置复制。此类复制使用 MySQL 二进制日志复制,也称为二进制日志复制。如果将二进制日志复制与 Aurora 结合使用,建议您的 MySQL 数据库运行 MySQL 版本 5.5 或更高版本。您可以在 Aurora MySQL 数据库集群为复制源或副本的位置设置复制。您可以使用 Amazon RDS MySQL 数据库实例、Amazon RDS 外部的 MySQL 数据库或其他 Aurora MySQL 数据库集群进行复制。
注意
您不能使用二进制日志复制以复制到某些类型的 Aurora 数据库集群或从中进行复制。特别是,二进制日志复制不可用于 Aurora Serverless v1 集群。如果 SHOW MASTER STATUS
和 SHOW
SLAVE STATUS
(Aurora MySQL 版本 2)或 SHOW REPLICA STATUS
(Aurora MySQL 版本 3)语句不返回任何输出,请检查您使用的集群是否支持二进制日志复制。
在 Aurora MySQL 版本 3 中,二进制日志复制无法复制到 mysql
系统数据库。Aurora MySQL 版本 3 中的二进制日志复制不会复制密码和账户。因此,不会复制诸如 CREATE USER
、GRANT
和 REVOKE
之类的数据控制语言(DCL)语句。
您还可以在其他 Amazon Web Services 区域中的 RDS for MySQL 数据库实例或 Aurora MySQL 数据库集群之间进行复制。跨 Amazon Web Services 区域执行复制时,请确保您的数据库集群和数据库实例可公开访问。如果 Aurora MySQL 数据库集群位于您的 VPC 的私有子网中,请在 Amazon Web Services 区域之间使用 VPC 对等。有关更多信息,请参阅 VPC 中的数据库集群由另一 VPC 中的 EC2 实例访问。
如果要在 Aurora MySQL 数据库集群和另一个 Amazon Web Services 区域中的 Aurora MySQL 数据库集群之间配置复制,您可以在与源数据库集群不同的 Amazon Web Services 区域 中创建一个 Aurora MySQL 数据库集群作为只读副本。有关更多信息,请参阅 跨 Amazon Web Services 区域复制 Amazon Aurora MySQL 数据库集群。
使用 Aurora MySQL 版本 2 和 3,您可以在 Aurora MySQL 与为复制使用全局事务标识符(GTID)的外部源或目标之间进行复制。请确保 Aurora MySQL 数据库集群中的 GTID 相关参数具有与外部数据库的 GTID 状态兼容的设置。若要了解如何执行此操作,请参阅 使用基于 GTID 的复制。在 Aurora MySQL 版本 3.01 及更高版本中,您可以选择如何将 GTID 分配给从不使用 GTID 的源复制的事务。有关控制该设置的存储过程的信息,请参阅 mysql.rds_assign_gtids_to_anonymous_transactions(Aurora MySQL 版本 3)。
警告
在 Aurora MySQL 与 MySQL 之间复制时,请确保仅使用 InnoDB 表。如果有 MyISAM 表需要复制,可以在设置复制之前使用以下命令将其转换为 InnoDB。
alter table <schema>.<table_name> engine=innodb, algorithm=copy;
设置与 MySQL 或其他 Aurora 数据库集群的复制
设置使用 Aurora MySQL 进行 MySQL 复制包括以下步骤(下面将详细讨论):
1. 在复制源上开启二进制日志记录
在下面查找有关如何在数据库引擎的复制源上开启二进制日志记录的说明。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
在 Aurora MySQL 数据库集群上开启二进制日志记录 将 要更改 如果要将 有关更多信息,请参阅Amazon Aurora 数据库集群和数据库实例参数 和使用参数组。 |
RDS for MySQL |
在 Amazon RDS 数据库实例上开启二进制日志记录 您不能直接为 Amazon RDS 数据库实例开启二进制日志记录,但可以通过执行以下操作之一来开启它: |
MySQL (外部) |
设置加密复制 要使用 Aurora MySQL 版本 2 安全地复制数据,您可以使用加密复制。 注意如果您不需要使用加密复制,可以跳过以下步骤。 以下是使用加密复制的先决条件:
在加密复制期间,Aurora MySQL 数据库集群充当 MySQL 数据库服务器的客户端。Aurora MySQL 客户端的证书和密钥必须是 .pem 格式的文件。
在外部 MySQL 数据库上开启二进制日志记录
|
2. 在复制源上保留二进制日志,直到不再需要
使用 MySQL 二进制日志复制时,Amazon RDS 不会对复制过程进行管理。因此,您需要确保复制源上的二进制日志文件保留到更改应用于副本之后。保留这些文件有助于在发生故障时可还原您的源数据库。
使用以下说明为数据库引擎保留二进制日志。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
在 Aurora MySQL 数据库集群上保留二进制日志 您无法访问 Aurora MySQL 数据库集群的二进制日志文件。因此,您必须为复制源上的二进制日志文件选择足够长的保留时间,从而确保在 Amazon RDS 删除二进制日志文件之前将更改应用于副本。Aurora MySQL 数据库集群上的二进制日志文件最多可以保留 90 天。 如果所设置的复制以 MySQL 数据库或 RDS for MySQL 数据库实例作为副本,并且要创建副本的数据库非常大,请为二进制日志文件选择较长的保留时间范围,直到数据库到副本的初始复制完成,并且副本滞后达到 0。 要设置二进制日志保留时间范围,请使用 mysql.rds_set_configuration 过程,并指定 以下示例将二进制日志文件的保留期设置为 6 天:
复制开始之后,可以通过对副本运行 如果未指定此设置,则 Aurora MySQL 的默认值为 24 小时(1 天)。 如果您为 |
RDS for MySQL |
在 Amazon RDS 数据库实例上保留二进制日志 您也可以通过设置二进制日志保留小时数在 Amazon RDS 数据库实例上保留二进制日志文件,就如同 Aurora MySQL 数据库集群一样(如上一行所述)。 还可以通过为数据库实例创建只读副本,在 Amazon RDS 数据库实例上保留二进制日志文件。此只读副本是临时副本,仅用于保留二进制日志文件的目的。在创建只读副本后,在只读副本上调用 mysql.rds_stop_replication 过程。复制停止时,Amazon RDS 不会删除复制源上的任何二进制日志文件。设置与永久副本间的复制之后,可以在复制源与永久副本之间的副本滞后( |
MySQL (外部) |
在外部 MySQL 数据库上保留二进制日志 外部 MySQL 数据库上的二进制日志文件不由 Amazon RDS 进行管理,因此,它们会一直保留,直到由您删除。 复制开始之后,可以通过对副本运行 |
3. 创建复制源的副本或转储
使用复制源的快照、克隆或转储将数据的基准副本加载到您的副本。然后从该点开始复制。
使用以下说明创建数据库引擎的复制源的副本或转储。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
创建 Aurora MySQL 数据库集群的副本 使用以下方法之一:
确定二进制日志文件名和位置 使用以下方法之一:
创建 Aurora MySQL 数据库集群的转储 如果副本目标是外部 MySQL 数据库或 RDS for MySQL 数据库实例,则必须从 Aurora 数据库集群创建转储文件。 请务必针对您创建的源数据库集群的副本运行
|
RDS for MySQL |
创建 Amazon RDS 数据库实例的快照 创建 Amazon RDS 数据库实例的只读副本。有关更多信息,请参阅 Amazon Relational Database Service 用户指南 中的创建只读副本。
|
MySQL (外部) |
创建外部 MySQL 数据库的转储
|
4. 将转储加载到副本目标(如果需要)
如果您打算从 Amazon RDS 外部的 MySQL 数据库转储加载数据,则可能要创建用于将转储文件复制到其中的 EC2 实例。然后,可以从该 EC2 实例将数据加载到数据库集群或数据库实例中。使用此方法时,您可以在将转储文件复制到 EC2 实例之前压缩它们,以便降低与向 Amazon RDS 复制数据关联的网络成本。在网络中进行传输时,还可以加密转储文件以保护数据。
注意
如果您创建一个新的 Aurora MySQL 数据库集群作为副本目标,则不需要加载转储文件:
-
可以从数据库集群快照进行还原来创建新的数据库集群。有关更多信息,请参阅 从数据库集群快照还原。
-
可以克隆源数据库集群来创建新的数据库集群。有关更多信息,请参阅 克隆 Amazon Aurora 数据库集群卷。
-
可以将数据从数据库实例快照迁移到新的数据库集群中。有关更多信息,请参阅 将数据迁移到 Amazon Aurora MySQL 数据库集群。
使用以下说明将复制源的转储加载到数据库引擎的副本目标中。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
将转储加载到 Aurora MySQL 数据库集群
|
RDS for MySQL |
将转储加载到 Amazon RDS 数据库实例
|
MySQL (外部) |
将转储加载到外部 MySQL 数据库 您无法将数据库快照或数据库集群快照加载到外部 MySQL 数据库中。您必须使用
|
5. 在您的复制源上创建复制用户
在源上创建一个专用于复制的用户 ID。以下示例适用于 RDS for MySQL 或外部 MySQL 源数据库。
mysql>
CREATE USER 'repl_user
'@'domain_name
' IDENTIFIED BY 'password
';
对于 Aurora MySQL 源数据库,skip_name_resolve
数据库集群参数设置为 1
(ON
)且无法修改,因此您必须使用主机的 IP 地址而不是域名。有关更多信息,请参阅 MySQL 文档中的 skip_name_resolve
mysql>
CREATE USER 'repl_user
'@'IP_address
' IDENTIFIED BY 'password
';
该用户需要 REPLICATION CLIENT
和 REPLICATION SLAVE
权限。向该用户授予这些权限。
如果您需要使用加密复制,则需为复制用户要求 SSL 连接。例如,您可以使用下面的语句之一来要求对用户账户 repl_user
使用 SSL 连接。
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '
repl_user
'@'IP_address
';
GRANT USAGE ON *.* TO '
repl_user
'@'IP_address
' REQUIRE SSL;
注意
如果不包括 REQUIRE SSL
,则复制连接可能会无提示地返回到未加密连接。
6. 在副本目标上开启复制
开启复制之前,我们建议您手动创建 Aurora MySQL 数据库集群或 RDS for MySQL 数据库实例副本目标的快照。如果出现问题,而您需要重新建立与数据库集群或数据库实例副本目标间的复制,则您可以从此快照还原数据库集群或数据库实例,而不必再次将数据导入您的副本目标之中。
使用以下说明对数据库引擎开启复制。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
从 Aurora MySQL 数据库集群中开启复制
要使用 SSL 加密,请将最终值设置为 |
RDS for MySQL |
从 Amazon RDS 数据库实例中开启复制
要使用 SSL 加密,请将最终值设置为 |
MySQL (外部) |
开启从外部 MySQL 数据库进行复制
|
如果复制失败,可能会导致副本上的意外输入/输出大量增加,从而降低性能。如果复制失败或不再需要复制,则可运行 mysql.rds_reset_external_master(Aurora MySQL 版本 2) 或 mysql.rds_reset_external_source(Aurora MySQL 版本 3) 存储过程来删除复制配置。
设置停止复制到只读副本的位置
在 Aurora MySQL 版本 3.04 及更高版本中,您可以使用 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程启动复制,然后在指定的二进制日志文件位置停止复制。
开始复制到只读副本并在特定位置处停止复制
-
通过使用 MySQL 客户端,以主用户的身份连接到副本 Aurora MySQL 数据库集群。
-
运行 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程。
以下示例将启动复制并复制更改,直到它到达
120
二进制日志文件中的mysql-bin-changelog.000777
位置。在灾难恢复方案中,假定位置120
刚好位于灾难之前。call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);
当到达停止点时,复制将自动停止。将生成以下 RDS 事件:Replication has been stopped since the replica reached the stop point specified by the
rds_start_replication_until stored procedure
。
如果使用基于 GTID 的复制,请使用 mysql.rds_start_replication_until_gtid(Aurora MySQL 版本 3) 存储过程而不是 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程。有关基于 GTID 的复制的更多信息,请参阅使用基于 GTID 的复制。
7. 监控副本
在设置与 Aurora MySQL 数据库集群的 MySQL 复制时,您必须在 Aurora MySQL 数据库集群作为副本目标时监控它的故障转移事件。如果发生故障转移,则可能会在具有不同网络地址的新主机上重新创建作为副本目标的数据库集群。有关如何监控故障转移事件的信息,请参阅使用 Amazon RDS 事件通知。
您还可以通过连接到副本目标并运行 SHOW SLAVE STATUS
(Aurora MySQL 版本 2)或 SHOW REPLICA STATUS
(Aurora MySQL 版本 3)命令,监控副本目标落后于复制源的程度。命令输出中的 Seconds Behind Master
字段可以揭示副本目标落后于源的程度。
在复制源和目标之间同步密码
使用 SQL 语句更改复制源上的用户账户和密码时,这些更改将自动复制到复制目标。
如果您使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 来更改复制源上的主密码,则这些更改不会自动复制到复制目标。如果要在源系统和目标系统之间同步主用户和主密码,则必须自己对复制目标进行相同的更改。
停止 Aurora 和 MySQL 之间或 Aurora 和其他 Aurora 数据库集群之间的复制
要停止对 MySQL 数据库实例、外部 MySQL 数据库或其他 Aurora 数据库集群进行的二进制日志复制,请执行以下步骤 (本主题后文有详细讨论)。
1. 在副本目标上停止二进制日志复制
按照以下说明停止数据库引擎的二进制日志复制。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
在 Aurora MySQL 数据库集群副本目标上停止二进制日志复制 连接到作为副本目标的 Aurora 数据库集群,然后调用 mysql.rds_stop_replication 过程。 |
RDS for MySQL |
在 Amazon RDS 数据库实例上停止二进制日志复制 连接到作为副本目标的 RDS 数据库实例,然后调用 mysql.rds_stop_replication 过程。 |
MySQL (外部) |
在外部 MySQL 数据库上停止二进制日志复制 连接到 MySQL 数据库并运行 |
2. 在复制源上关闭二进制日志记录
使用下表中的说明在数据库引擎的复制源上关闭二进制日志记录。
数据库引擎 | 说明 |
---|---|
Aurora MySQL |
在 Amazon Aurora 数据库集群上关闭二进制日志记录
|
RDS for MySQL |
在 Amazon RDS 数据库实例上关闭二进制日志记录 您不能直接为 Amazon RDS 数据库实例关闭二进制日志记录,但可以通过执行以下操作来关闭它:
|
MySQL (外部) |
在外部 MySQL 数据库上关闭二进制日志记录 连接到 MySQL 数据库并调用
|
使用 Amazon Aurora 为 MySQL 数据库扩展读取
您可以将 Amazon Aurora 用于 MySQL 数据库实例,以便利用 Amazon Aurora 的读取扩展功能并为 MySQL 数据库实例扩展读取工作负载。要使用 Aurora 对 MySQL 数据库实例扩缩读取,请创建 Amazon Aurora MySQL 数据库集群并使它成为 MySQL 数据库实例的只读副本。这适用于 RDS for MySQL 数据库实例或是在 Amazon RDS 外部运行的 MySQL 数据库。
有关创建 Amazon Aurora 数据库集群的信息,请参阅创建 Amazon Aurora 数据库集群。
在 MySQL 数据库实例与 Amazon Aurora 数据库集群之间设置复制时,请确保遵循以下准则:
-
当您引用 Amazon Aurora 数据库集群时,使用 Amazon Aurora MySQL 数据库集群端点地址。如果发生故障转移,则提升为 Aurora 数据库集群主实例的 Aurora MySQL 副本继续使用数据库集群端点地址。
-
在您的写入器实例上维护二进制日志,直至您确认其已应用于 Aurora 副本。这种维护将确保您可以在发生故障时还原写入器实例。
重要
当使用自管理复制时,您负责监控和解决可能发生的所有复制问题。有关更多信息,请参阅 诊断并解决只读副本之间的滞后。
注意
对 Aurora MySQL 数据库集群启动复制功能所需的权限受到限制且对 Amazon RDS 主用户不可用。为此,您必须使用 mysql.rds_set_external_master(Aurora MySQL 版本 2) 或 mysql.rds_set_external_source(Aurora MySQL 版本 3) 和 mysql.rds_start_replication 过程来设置 Aurora MySQL 数据库集群和 MySQL 数据库实例之间的复制。
启动外部源实例和 Aurora MySQL 数据库集群之间的复制
-
将源 MySQL 数据库实例设为只读:
mysql>
FLUSH TABLES WITH READ LOCK;mysql>
SET GLOBAL read_only = ON; -
对源 MySQL 数据库实例运行
SHOW MASTER STATUS
命令以确定二进制日志位置。将会收到类似于以下示例的输出:File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
-
使用
mysqldump
将数据库从外部 MySQL 数据库实例复制到 Amazon Aurora MySQL 数据库集群。对于非常大的数据库,您可能希望使用 Amazon Relational Database Service 用户指南 中的将数据导入到 MySQL 或 MariaDB 数据库实例并减少停机时间中的过程。对于 Linux、macOS 或 Unix:
mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ -u
local_user
\ -plocal_password
| mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -uRDS_user_name
\ -pRDS_password
对于 Windows:
mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u
local_user
^ -plocal_password
| mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -uRDS_user_name
^ -pRDS_password
注意
确保
-p
选项和输入的密码之间没有空格。在
--host
命令中使用--user (-u)
、--port
、-p
和mysql
选项,以指定用于连接到 Aurora 数据库集群的主机名、用户名、端口和密码。主机名是 Amazon Aurora 数据库集群端点中的 DNS 名称,例如mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com
。您可以在 Amazon RDS 管理控制台上的集群详细信息中找到端点值。 -
再次将源 MySQL 数据库实例设为可写:
mysql>
SET GLOBAL read_only = OFF;mysql>
UNLOCK TABLES;有关生成备份以用于复制的更多信息,请参阅 MySQL 文档中的Backing up a source or replica by making it read only
。 -
在 Amazon RDS 管理控制台中,将托管源 MySQL 数据库的服务器的 IP 地址添加到 Amazon Aurora 数据库集群的 VPC 安全组。有关修改 VPC 安全组的更多信息,请参阅 Amazon Virtual Private Cloud 用户指南 中的您的 VPC 的安全组。
您可能还需要配置本地网络以允许来自 Amazon Aurora 数据库集群的 IP 地址的连接,以便它能与源 MySQL 实例进行通信。要查找 Amazon Aurora 数据库集群的 IP 地址,请使用
host
命令。host
aurora_endpoint_address
主机名是 Amazon Aurora 数据库集群端点中的 DNS 名称。
-
通过使用所选的客户端,连接到外部 MySQL 实例并创建用于复制的 MySQL 用户。此账户仅用于复制,并且必须仅供您的域使用以增强安全性。以下是示例。
CREATE USER '
repl_user
'@'mydomain.com
' IDENTIFIED BY 'password
'; -
对于外部 MySQL 实例,向复制用户授予
REPLICATION CLIENT
和REPLICATION SLAVE
权限。例如,要为您的域的“REPLICATION CLIENT
”用户授予对所有数据库的REPLICATION SLAVE
和repl_user
权限,请发出以下命令。GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '
repl_user
'@'mydomain.com
' IDENTIFIED BY 'password
'; -
在设置复制之前,请创建 Aurora MySQL 数据库集群的手动快照以作为只读副本。如果您需要将数据库集群作为只读副本来重新建立复制,则可从此快照还原 Aurora MySQL 数据库集群,而不必将 MySQL 数据库实例中的数据导入新的 Aurora MySQL 数据库集群。
-
使 Amazon Aurora 数据库集群成为副本。以主用户身份连接到 Amazon Aurora 数据库集群,并通过使用 mysql.rds_set_external_master(Aurora MySQL 版本 2) 或 mysql.rds_set_external_source(Aurora MySQL 版本 3) 和 mysql.rds_start_replication 过程将源 MySQL 数据库确定为复制主实例。
使用在步骤 2 中确定的主日志文件名和主日志位置。示例如下:
For Aurora MySQL version 2: CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3: CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
-
在 Amazon Aurora 数据库集群上,调用 mysql.rds_start_replication 过程以开始复制。
CALL mysql.rds_start_replication;
在源 MySQL 数据库实例与 Amazon Aurora 数据库集群之间建立复制之后,可以将 Aurora 副本添加到 Amazon Aurora 数据库集群。随后可以连接到 Aurora 副本以对数据进行读取扩展。有关创建 Aurora 副本的信息,请参阅将 Aurora 副本添加到数据库集群。
优化二进制日志复制
接下来,您可以了解如何优化二进制日志复制性能和排查 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
(禁用)。启用此特征不需要重启实例。要启用此特征,请停止正在进行的复制,设置所需的并行工作线程数,然后重新开始复制。
您也可以将此参数用作全局变量,其中 n
是并行工作线程的数量:
SET global aurora_binlog_replication_sec_index_parallel_workers=
n
;
优化二进制日志复制(Aurora MySQL 2.10 及更高版本)
在 Aurora MySQL 2.10 及更高版本中,Aurora 会自动将称为二进制日志 I/O 缓存的优化应用于二进制日志复制。通过缓存最近提交的二进制日志事件,此优化旨在提高二进制日志转储线程性能,同时限制对二进制日志源实例上前台事务的影响。
注意
用于此特征的内存独立于 MySQL binlog_cache
设置。
此特征不适用于使用 db.t2
和 db.t3
实例类的 Aurora 数据库实例。
您无需调整任何配置参数即可启用此优化。特别是,如果在早期 Aurora MySQL 版本中将配置参数 aurora_binlog_replication_max_yield_seconds
调整为非零值,请在 Aurora MySQL 2.10 及更高版本中将其重新设置为零。
Aurora MySQL 2.10 及更高版本中提供了状态变量 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
指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。
优化二进制日志复制(Aurora MySQL 版本 2 至 2.09)
要优化 Aurora MySQL 的二进制日志复制,您可以调整以下集群级优化参数。这些参数可帮助您在二进制日志源实例的延迟和复制滞后之间指定适当的平衡。
-
aurora_binlog_use_large_read_buffer
-
aurora_binlog_read_buffer_size
-
aurora_binlog_replication_max_yield_seconds
注意
对于 MySQL 5.7 兼容的集群,您可以在 Aurora MySQL 版本 2 至 2.09.* 中使用这些参数。在 Aurora MySQL 2.10.0 及更高版本中,这些参数被二进制日志 I/O 缓存优化所取代,无需使用这些参数。
大型读取缓冲区和最大生成率优化概述
当集群处理大量事务时,如果二进制日志转储线程访问 Aurora 集群卷,您可能会遇到二进制日志复制性能降低的情况。您可以使用参数 aurora_binlog_use_large_read_buffer
、aurora_binlog_replication_max_yield_seconds
和 aurora_binlog_read_buffer_size
帮助最大限度减少这种类型的争用。
假设您有一个情况:aurora_binlog_replication_max_yield_seconds
设置为大于 0 并且转储线程的当前二进制日志文件处于活动状态。在这种情况下,二进制日志转储线程最多会等待指定的秒数,以便事务填充当前二进制日志文件。此等待期避免了单独复制每个二进制日志事件可能引起的争用。但是,这样做会增加二进制日志副本的副本滞后。这些副本可能落后于源,落后的描述与 aurora_binlog_replication_max_yield_seconds
设置相同。
当前的二进制日志文件表示转储线程当前正在读取以执行复制的二进制日志文件。我们认为一个二进制日志文件在更新或打开以供传入事务更新时,该二进制日志文件处于活动状态。Aurora MySQL 填满活动的二进制日志文件后,MySQL 会创建并切换到新的二进制日志文件。旧二进制日志文件变为非活动状态。传入的事务不再更新它。
注意
在调整这些参数之前,请衡量一段时间内的事务延迟和吞吐量。即使偶尔出现争用,您也可能会发现二进制日志复制性能稳定且延迟低。
aurora_binlog_use_large_read_buffer
-
如果此参数设置为 1,Aurora MySQL 会基于参数
aurora_binlog_read_buffer_size
和aurora_binlog_replication_max_yield_seconds
的设置优化二进制日志复制。如果aurora_binlog_use_large_read_buffer
为 0,Aurora MySQL 会忽略aurora_binlog_read_buffer_size
和aurora_binlog_replication_max_yield_seconds
参数的值。 aurora_binlog_read_buffer_size
-
具有较大读取缓冲区的二进制日志转储线程可通过读取每个输入/输出的更多事件来最大限度地减少读取输入/输出操作的数量。参数
aurora_binlog_read_buffer_size
设置读取缓冲区大小。大型读取缓冲区可以减少生成大量二进制日志数据的工作负载的二进制日志争用。注意
此参数仅在集群也具有
aurora_binlog_use_large_read_buffer=1
设置时才有效。提高读取缓冲区的大小不会影响二进制日志复制的性能。二进制日志转储线程不会等待更新事务填满读缓冲区。
aurora_binlog_replication_max_yield_seconds
-
如果您的工作负载需要较低的事务延迟,并且可以容忍某些复制延迟,您可以提高
aurora_binlog_replication_max_yield_seconds
参数。此参数控制集群中的二进制日志复制的最大生成属性。注意
此参数仅在集群也具有
aurora_binlog_use_large_read_buffer=1
设置时才有效。
Aurora MySQL 可立即识别对 aurora_binlog_replication_max_yield_seconds
参数值的任何更改。您无需重新启动数据库实例。但是,开启此设置后,只有当当前二进制日志文件达到 128MB 的最大大小并轮换到新文件时,转储线程才开始生成。
相关参数
使用以下数据库集群参数开启二进制日志优化。
参数 | 默认值 | 有效值 | 描述 |
---|---|---|---|
aurora_binlog_use_large_read_buffer
|
1 | 0, 1 | 切换开启复制改进特征。当其值为 1 时,二进制日志转储线程将使用 aurora_binlog_read_buffer_size 进行二进制日志复制;否则使用默认缓冲区大小(8K)。在 Aurora MySQL 版本 3 中不使用。 |
aurora_binlog_read_buffer_size
|
5242880 | 8192-536870912 | 参数 aurora_binlog_use_large_read_buffer 设置为 1 时,二进制日志转储线程使用的读取缓冲区大小。在 Aurora MySQL 版本 3 中不使用。 |
aurora_binlog_replication_max_yield_seconds
|
0 | 0-36000 |
对于版本 Aurora MySQL 2.07.*,可接受的最大值为 45。您可以在 2.09 及更高版本中将其调整为更高的值。 对于版本 2,仅当参数 |
启用二进制日志复制的最大生成率机制
您可以按如下方式开启二进制日志复制最大生成率优化。这样做可以最大限度地减少二进制日志源实例上的事务延迟。但是,您可能会遇到更高的复制滞后。
要为 Aurora MySQL 集群开启最大生成率二进制日志优化
-
使用以下参数设置创建或编辑数据库集群参数组:
-
aurora_binlog_use_large_read_buffer
:使用值ON
或 1 开启。 -
aurora_binlog_replication_max_yield_seconds
:指定一个大于 0 的值。
-
-
将数据库集群参数组与作为二进制日志源的 Aurora MySQL 集群相关联。为此,请按照 使用参数组 中的过程进行操作。
-
确认参数更改生效。为此,请在二进制日志源实例上运行以下查询。
SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;
您的输出应类似于以下内容。
+---------------------------------------+-----------------------------------------------+ | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds | +---------------------------------------+-----------------------------------------------+ | 1 | 45 | +---------------------------------------+-----------------------------------------------+
关闭二进制日志复制最大生成率优化
您可以按如下方式关闭二进制日志复制最大生成率优化。这样做可最大限度地减少复制滞后。但是,在二进制日志源实例上,您可能会遇到更高的延迟。
要关闭 Aurora MySQL 集群的最大生成率优化
-
确保与 Aurora MySQL 集群关联的数据库集群参数组将
aurora_binlog_replication_max_yield_seconds
设置为 0。有关使用参数组设置配置参数的更多信息,请参阅 使用参数组。 -
确认参数更改生效。为此,请在二进制日志源实例上运行以下查询。
SELECT @@aurora_binlog_replication_max_yield_seconds;
您的输出应类似于以下内容。
+-----------------------------------------------+ | @@aurora_binlog_replication_max_yield_seconds | +-----------------------------------------------+ | 0 | +-----------------------------------------------+
关闭大型读取缓冲区
您可以按如下方式关闭整个大型读取缓冲区特征。
要关闭 Aurora MySQL 集群的大型二进制日志读缓冲区
-
将
aurora_binlog_use_large_read_buffer
重置为OFF
或 0。确保与 Aurora MySQL 集群关联的数据库集群参数组将
aurora_binlog_use_large_read_buffer
设置为 0。有关使用参数组设置配置参数的更多信息,请参阅 使用参数组。 -
在二进制日志源实例上,运行以下查询。
SELECT @@ aurora_binlog_use_large_read_buffer;
您的输出应类似于以下内容。
+---------------------------------------+ | @@aurora_binlog_use_large_read_buffer | +---------------------------------------+ | 0 | +---------------------------------------+
设置增强型二进制日志
增强型二进制日志可减少开启二进制日志所导致的计算性能开销,在某些情况下,该开销最高可达 50%。使用增强型二进制日志,这种开销可以减少到大约 13%。为了减少开销,增强型二进制日志将二进制和事务日志并行写入存储,从而最大限度地减少在事务提交时间写入的数据。
与社区 MySQL 二进制日志相比,使用增强型二进制日志还可以将重启和故障转移后的数据库恢复时间缩短多达 99%。增强型二进制日志与现有的基于二进制日志的工作负载兼容,您与其交互的方式和您与社区 MySQL 二进制日志交互的方式相同。
增强型二进制日志在 Aurora MySQL 版本 3.03.1 及更高版本上可用。
配置增强型二进制日志参数
您可以通过开启/关闭增强型二进制日志参数,在社区 MySQL 二进制日志和增强型二进制日志之间切换。现有的二进制日志使用者可以继续读取和使用二进制日志文件,而不会在二进制日志文件序列中出现任何间隔。
开启增强型二进制日志 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
参数 | 默认值 | 描述 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binlog_format
|
– | 将 binlog_format 参数设置为您选择的二进制日志记录格式,以开启增强型二进制日志。确保 binlog_format parameter 未设置为 OFF。有关更多信息,请参阅配置 Aurora MySQL 二进制日志记录。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
aurora_enhanced_binlog
|
0 |
在与 Aurora MySQL 集群关联的数据库集群参数组中,将此参数的值设置为 1 。更改此参数的值时,当 DBClusterParameterGroupStatus 值显示为 pending-reboot 时,必须重启写入器实例。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binlog_backup
|
1 |
关闭此参数可开启增强型二进制日志。为此,请将此参数的值设置为 0 。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binlog_replication_globaldb
|
1 |
关闭此参数可开启增强型二进制日志。为此,请将此参数的值设置为 0 。 |
重要
只有在使用增强型二进制日志时,才能关闭 binlog_backup
和 binlog_replication_globaldb
参数。
关闭增强型二进制日志 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
参数 | 描述 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
aurora_enhanced_binlog
|
在与 Aurora MySQL 集群关联的数据库集群参数组中,将此参数的值设置为 0 。每当您更改此参数的值时,当 DBClusterParameterGroupStatus 值显示为 pending-reboot 时,必须重启写入器实例。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binlog_backup
|
关闭增强型二进制日志时开启此参数。为此,请将此参数的值设置为 1 。 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
binlog_replication_globaldb
|
关闭增强型二进制日志时开启此参数。为此,请将此参数的值设置为 1 。 |
要检查增强型二进制日志是否已开启,请在 MySQL 客户端中使用以下命令:
mysql>
show status like 'aurora_enhanced_binlog';+------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | aurora_enhanced_binlog | ACTIVE | +------------------------+--------+ 1 row in set (0.00 sec)
开启增强型二进制日志时,输出将对于 aurora_enhanced_binlog
显示 ACTIVE
。
其他相关参数
当您开启增强型二进制日志时,以下参数会受到影响:
max_binlog_size
参数可见但不可修改。当开启增强型二进制日志时,此参数的默认值134217728
会自动调整为268435456
。与社区 MySQL 二进制日志不同,当开启增强型二进制日志时,
binlog_checksum
不充当动态参数。要使对此参数的更改生效,必须手动重启数据库集群,即使ApplyMethod
为immediate
也是如此。开启增强型二进制日志时,您对
binlog_order_commits
参数设置的值对提交顺序没有影响。提交始终是按顺序排列的,不会对性能产生任何进一步的影响。
增强型二进制日志和社区 MySQL 二进制日志之间的区别
与社区 MySQL 二进制日志相比,增强型二进制日志与克隆、备份和 Aurora Global Database 的交互方式不同。我们建议您在使用增强型二进制日志之前了解以下差异。
来自源数据库集群的增强型二进制日志文件在克隆的数据库集群上不可用。
增强型二进制日志文件不包含在 Aurora 备份中。因此,尽管在数据库集群上设置了任何保留期,但在还原数据库集群后,源数据库集群中的增强型二进制日志文件不可用。
与 Aurora 全局数据库一起使用时,主数据库集群的增强二进制日志文件不会复制到辅助区域中的数据库集群。
示例
以下示例说明了增强型二进制日志和社区 MySQL 二进制日志之间的区别。
在还原或克隆的数据库集群上
开启增强型二进制日志后,历史二进制日志文件在还原或克隆的数据库集群中不可用。在执行还原或克隆操作后,如果开启二进制日志,则新的数据库集群将开始写入其自己的二进制日志文件序列,从 1 开始(mysql-bin-changelog.000001)。
要在还原或克隆操作后开启增强型二进制日志,请在还原或克隆的数据库集群上设置所需的数据库集群参数。有关更多信息,请参阅 配置增强型二进制日志参数。
例 开启增强型二进制日志时执行的克隆或还原操作
源数据库集群:
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec)
在还原或克隆的数据库集群上,开启增强型二进制日志时不备份二进制日志文件。为避免二进制日志数据出现不连续性,在开启增强型二进制日志之前写入的二进制日志文件也不可用。
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec)
例 关闭增强型二进制日志时执行的克隆或还原操作
源数据库集群:
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec)
在还原或克隆的数据库集群上,关闭增强型二进制日志后写入的二进制日志文件可用。
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 1 row in set (0.00 sec)
在 Amazon Aurora 全局数据库上
在 Amazon Aurora 全局数据库上,主数据库集群的二进制日志数据不会复制到辅助数据库集群。在执行跨区域故障转移过程后,二进制日志数据在新升级的主数据库集群中不可用。如果开启二进制日志,则新提升的数据库集群将开始其自己的二进制日志文件序列,从 1 开始(mysql-bin-changelog.000001)。
要在故障转移后开启增强型二进制日志,您必须在辅助数据库集群上设置所需的数据库集群参数。有关更多信息,请参阅 配置增强型二进制日志参数。
例 开启增强型二进制日志时执行全局数据库故障转移操作
旧的主数据库集群(故障转移前):
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec)
新的主数据库集群(故障转移后):
开启增强型二进制日志后,二进制日志文件不会复制到辅助区域。为避免二进制日志数据出现不连续性,在开启增强型二进制日志之前写入的二进制日志文件不可用。
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec)
例 关闭增强型二进制日志时执行全局数据库故障转移操作
源数据库集群:
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec)
还原或克隆的数据库集群:
关闭增强型二进制日志后写入的二进制日志文件会被复制,并在新提升的数据库集群中可用。
mysql>
show binary logs;+----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 3 rows in set (0.00 sec)
增强型二进制日志的 Amazon CloudWatch 指标
以下 Amazon CloudWatch 指标仅在开启增强型二进制日志时发布。
CloudWatch 指标 | 描述 | 单位 |
---|---|---|
ChangeLogBytesUsed | 增强型二进制日志使用的存储空间量。 | 字节 |
ChangeLogReadIOPs | 在 5 分钟的时间间隔内,在增强型二进制日志中执行的读取 I/O 操作的数量。 | 每 5 分钟计数 |
ChangeLogWriteIOPs | 在 5 分钟的时间间隔内,在增强型二进制日志中执行的写入磁盘 I/O 操作的数量。 | 每 5 分钟计数 |
增强型二进制日志限制
开启增强型二进制日志时,以下限制适用于 Amazon Aurora 数据库集群。
-
仅在 Aurora MySQL 版本 3.03.1 及更高版本上支持增强型二进制日志。
-
在主数据库集群上写入的增强型二进制日志文件不会复制到克隆或还原的数据库集群。
-
与 Amazon Aurora 全局数据库一起使用时,主数据库集群的增强型二进制日志文件不会复制到辅助数据库集群。因此,在故障转移过程之后,历史二进制日志数据在新的主数据库集群中不可用。
-
将忽略以下二进制日志配置参数:
-
binlog_group_commit_sync_delay
-
binlog_group_commit_sync_no_delay_count
-
binlog_max_flush_queue_time
-
-
您无法删除或重命名数据库中损坏的表。要删除这些表,您可以联系 Amazon Web Services Support。
-
开启增强型二进制日志时,会禁用二进制日志 I/O 缓存。有关更多信息,请参阅 优化二进制日志复制。
注意
增强型二进制日志提供了与二进制日志 I/O 缓存类似的读取性能改进以及更好的写入性能改进。
-
不支持回溯特征。在以下情况下,无法在数据库集群中开启增强型二进制日志:
当前已启用回溯特征的数据库集群。
先前已启用但现在禁用回溯功能的数据库集群。
从启用了回溯特征的源数据库集群或快照中还原的数据库集群。