engine=innodb, algorithm=copy;
```
在以下各节中，设置复制、停止复制、扩展数据库的读取、优化二进制日志复制以及设置增强型二进制日志。
**Topics**
+ [为 Aurora MySQL 设置二进制日志复制](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [停止 Aurora MySQL 的二进制日志复制](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [使用 Amazon Aurora 扩展 MySQL 数据库的读取](AuroraMySQL.Replication.ReadScaling.md)
+ [优化 Aurora MySQL 的二进制日志复制](binlog-optimization.md)
+ [为 Aurora MySQL 设置增强型二进制日志](AuroraMySQL.Enhanced.binlog.md)
# 为 Aurora MySQL 设置二进制日志复制
设置使用 Aurora MySQL 进行 MySQL 复制包括以下步骤（下面将详细讨论）：
**Contents**
+ [1. 在复制源上开启二进制日志记录](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. 在复制源上保留二进制日志，直到不再需要](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. 创建复制源的副本或转储](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. 将转储加载到副本目标（如果需要）](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. 在您的复制源上创建复制用户](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. 在副本目标上开启复制](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [设置停止复制到只读副本的位置](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. 监控副本](#AuroraMySQL.Replication.MySQL.Monitor)
+ [在复制源和目标之间同步密码](#AuroraMySQL.Replication.passwords)
## 1. 在复制源上开启二进制日志记录
在下面查找有关如何在数据库引擎的复制源上开启二进制日志记录的说明。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 数据库集群上开启二进制日志记录** 将 `binlog_format` 数据库集群参数设置为 `ROW`、`STATEMENT` 或 `MIXED`。建议设置为 `MIXED`，除非您需要采用特定的二进制日志格式。（默认值为 `OFF`。） 要更改 `binlog_format` 参数，请创建自定义数据库集群参数组，并将该自定义参数组与您的数据库集群关联。您无法更改默认数据库集群参数组中的参数。 如果要将 `binlog_format` 参数从 `OFF` 更改为其他值，请重启 Aurora 数据库集群以使更改生效。 有关更多信息，请参阅[Amazon Aurora 数据库集群和数据库实例参数](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups)和[Amazon Aurora 的参数组](USER_WorkingWithParamGroups.md)。 |
| RDS for MySQL | **在 Amazon RDS 数据库实例上开启二进制日志记录** 您不能直接为 Amazon RDS 数据库实例开启二进制日志记录，但可以通过执行以下操作之一来开启它： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **设置加密复制** 要使用 Aurora MySQL 版本 2 安全地复制数据，您可以使用加密复制。 如果您不需要使用加密复制，可以跳过以下步骤。 以下是使用加密复制的先决条件： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 在加密复制期间，Aurora MySQL 数据库集群充当 MySQL 数据库服务器的客户端。Aurora MySQL 客户端的证书和密钥必须是 .pem 格式的文件。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **在外部 MySQL 数据库上开启二进制日志记录** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. 在复制源上保留二进制日志，直到不再需要
使用 MySQL 二进制日志复制时，Amazon RDS 不会对复制过程进行管理。因此，您需要确保复制源上的二进制日志文件保留到更改应用于副本之后。保留这些文件有助于在发生故障时可还原您的源数据库。
使用以下说明为数据库引擎保留二进制日志。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 数据库集群上保留二进制日志** 您无法访问 Aurora MySQL 数据库集群的二进制日志文件。因此，您必须为复制源上的二进制日志文件选择足够长的保留时间，从而确保在 Amazon RDS 删除二进制日志文件之前将更改应用于副本。Aurora MySQL 数据库集群上的二进制日志文件最多可以保留 90 天。 如果所设置的复制以 MySQL 数据库或 RDS for MySQL 数据库实例作为副本，并且要创建副本的数据库非常大，请为二进制日志文件选择较长的保留时间范围，直到数据库到副本的初始复制完成，并且副本滞后达到 0。 要设置二进制日志保留时间范围，请使用 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 过程，并指定 `'binlog retention hours'` 配置参数以及在数据库集群上保留二进制日志文件的小时数。Aurora MySQL 版本 2.11.0 及更高版本和版本 3 的最大值为 2160（90天）。 以下示例将二进制日志文件的保留期设置为 6 天： CALL mysql.rds_set_configuration('binlog retention hours', 144); 复制开始之后，可以通过对副本运行 `SHOW SLAVE STATUS`（Aurora MySQL 版本 2）或 `SHOW REPLICA STATUS`（Aurora MySQL 版本 3）命令并检查 `Seconds behind master` 字段来验证更改是否已经应用于副本。如果 `Seconds behind master` 字段为 0，则表示不存在副本滞后。不存在副本滞后时，请通过将 `binlog retention hours` 配置参数设置为更短的时间范围缩短保留二进制日志文件的时间。 如果未指定此设置，则 Aurora MySQL 的默认值为 24 小时（1 天）。 如果您为 `'binlog retention hours'` 指定的值大于最大值，则 Aurora MySQL 使用最大值。 |
| RDS for MySQL | **在 Amazon RDS 数据库实例上保留二进制日志** 您也可以通过设置二进制日志保留小时数在 Amazon RDS 数据库实例上保留二进制日志文件，就如同 Aurora MySQL 数据库集群一样（如上一行所述）。 还可以通过为数据库实例创建只读副本，在 Amazon RDS 数据库实例上保留二进制日志文件。此只读副本是临时副本，仅用于保留二进制日志文件的目的。在创建只读副本后，在只读副本上调用 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 过程。复制停止时，Amazon RDS 不会删除复制源上的任何二进制日志文件。设置与永久副本间的复制之后，可以在复制源与永久副本之间的副本滞后（`Seconds behind master` 字段）达到 0 时删除只读副本。 |
| MySQL (外部) | **在外部 MySQL 数据库上保留二进制日志** 外部 MySQL 数据库上的二进制日志文件不由 Amazon RDS 进行管理，因此，它们会一直保留，直到由您删除。 复制开始之后，可以通过对副本运行 `SHOW SLAVE STATUS`（Aurora MySQL 版本 2）或 `SHOW REPLICA STATUS`（Aurora MySQL 版本 3）命令并检查 `Seconds behind master` 字段来验证更改是否已经应用于副本。如果 `Seconds behind master` 字段为 0，则表示不存在副本滞后。不存在副本滞后时，可以删除旧的二进制日志文件。 |
## 3. 创建复制源的副本或转储
使用复制源的快照、克隆或转储将数据的基准副本加载到您的副本。然后从该点开始复制。
使用以下说明创建数据库引擎的复制源的副本或转储。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **创建 Aurora MySQL 数据库集群的副本** 使用以下方法之一： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **确定二进制日志文件名和位置** 使用以下方法之一： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **创建 Aurora MySQL 数据库集群的转储** 如果副本目标是外部 MySQL 数据库或 RDS for MySQL 数据库实例，则必须从 Aurora 数据库集群创建转储文件。 请务必针对您创建的源数据库集群的副本运行 `mysqldump` 命令。这是为了避免在进行转储时考虑锁定问题。如果转储是直接在源数据库集群上进行的，则需要锁定源表，用于防止在转储过程中对这些表进行并发写入。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **创建 Amazon RDS 数据库实例的快照** 创建 Amazon RDS 数据库实例的只读副本。有关更多信息，请参阅 *Amazon Relational Database Service 用户指南* 中的[创建只读副本](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **创建外部 MySQL 数据库的转储** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. 将转储加载到副本目标（如果需要）
如果您打算从 Amazon RDS 外部的 MySQL 数据库转储加载数据，则可能要创建用于将转储文件复制到其中的 EC2 实例。然后，可以从该 EC2 实例将数据加载到数据库集群或数据库实例中。使用此方法时，您可以在将转储文件复制到 EC2 实例之前压缩它们，以便降低与向 Amazon RDS 复制数据关联的网络成本。在网络中进行传输时，还可以加密转储文件以保护数据。
**注意**
如果您创建一个新的 Aurora MySQL 数据库集群作为副本目标，则不需要加载转储文件：
可以从数据库集群快照进行还原来创建新的数据库集群。有关更多信息，请参阅 [从数据库集群快照还原](aurora-restore-snapshot.md)。
可以克隆源数据库集群来创建新的数据库集群。有关更多信息，请参阅 [克隆 Amazon Aurora 数据库集群卷](Aurora.Managing.Clone.md)。
可以将数据从数据库实例快照迁移到新的数据库集群中。有关更多信息，请参阅 [将数据迁移到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Migrating.md)。
使用以下说明将复制源的转储加载到数据库引擎的副本目标中。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **将转储加载到 Aurora MySQL 数据库集群** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **将转储加载到 Amazon RDS 数据库实例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **将转储加载到外部 MySQL 数据库** 您无法将数据库快照或数据库集群快照加载到外部 MySQL 数据库中。您必须使用 `mysqldump` 命令的输出。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 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\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_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 数据库集群中开启复制** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 要使用 SSL 加密，请将最终值设置为 `1` 而不是 `0`。 |
| RDS for MySQL | **从 Amazon RDS 数据库实例中开启复制** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 要使用 SSL 加密，请将最终值设置为 `1` 而不是 `0`。 |
| MySQL (外部) | **开启从外部 MySQL 数据库进行复制** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
如果复制失败，可能会导致副本上的意外输入/输出大量增加，从而降低性能。如果复制失败或不再需要复制，则可运行 [mysql.rds\$1reset\$1external\$1master（Aurora MySQL 版本 2）](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) 或 [mysql.rds\$1reset\$1external\$1source（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) 存储过程来删除复制配置。
### 设置停止复制到只读副本的位置
在 Aurora MySQL 版本 3.04 及更高版本中，您可以使用 [mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 存储过程启动复制，然后在指定的二进制日志文件位置停止复制。
**开始复制到只读副本并在特定位置处停止复制**
1. 通过使用 MySQL 客户端，以主用户的身份连接到副本 Aurora MySQL 数据库集群。
1. 运行 [mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 存储过程。
以下示例将启动复制并复制更改，直到它到达 `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\$1start\$1replication\$1until\$1gtid（Aurora MySQL 版本 3）](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 存储过程而不是 [mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) 存储过程。有关基于 GTID 的复制的更多信息，请参阅[使用基于 GTID 的复制](mysql-replication-gtid.md)。
## 7. 监控副本
在设置与 Aurora MySQL 数据库集群的 MySQL 复制时，您必须在 Aurora MySQL 数据库集群作为副本目标时监控它的失效转移事件。如果发生失效转移，则可能会在具有不同网络地址的新主机上重新创建作为副本目标的数据库集群。有关如何监控失效转移事件的信息，请参阅[使用 Amazon RDS 事件通知](USER_Events.md)。
您还可以通过连接到副本目标并运行 `SHOW SLAVE STATUS`（Aurora MySQL 版本 2）或 `SHOW REPLICA STATUS`（Aurora MySQL 版本 3）命令，监控副本目标落后于复制源的程度。命令输出中的 `Seconds Behind Master` 字段可以揭示副本目标落后于源的程度。
**重要**
如果您升级数据库集群并指定自定义参数组，请确保在升级完成后手动重启集群。这样可以让集群使用新的自定义参数设置，并重新启动二进制日志复制。
## 在复制源和目标之间同步密码
使用 SQL 语句更改复制源上的用户账户和密码时，这些更改将自动复制到复制目标。
如果您使用 AWS 管理控制台、AWS CLI 或 RDS API 来更改复制源上的主密码，则这些更改不会自动复制到复制目标。如果要在源系统和目标系统之间同步主用户和主密码，则必须自己对复制目标进行相同的更改。
# 停止 Aurora MySQL 的二进制日志复制
要停止对 MySQL 数据库实例、外部 MySQL 数据库或其他 Aurora 数据库集群进行的二进制日志复制，请执行以下步骤 (本主题后文有详细讨论)。
[1. 在副本目标上停止二进制日志复制](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. 在复制源上关闭二进制日志记录](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. 在副本目标上停止二进制日志复制
按照以下说明停止数据库引擎的二进制日志复制。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **在 Aurora MySQL 数据库集群副本目标上停止二进制日志复制** 连接到作为副本目标的 Aurora 数据库集群，然后调用 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 过程。 |
| RDS for MySQL | **在 Amazon RDS 数据库实例上停止二进制日志复制** 连接到作为副本目标的 RDS 数据库实例，然后调用 [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) 过程。 |
| MySQL (外部) | **在外部 MySQL 数据库上停止二进制日志复制** 连接到 MySQL 数据库并运行 `STOP SLAVE`（版本 5.7）或 `STOP REPLICA`（版本 8.0）命令。 |
## 2. 在复制源上关闭二进制日志记录
使用下表中的说明在数据库引擎的复制源上关闭二进制日志记录。
| 数据库引擎 | 说明 |
| --- | --- |
| Aurora MySQL | **在 Amazon Aurora 数据库集群上关闭二进制日志记录** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **在 Amazon RDS 数据库实例上关闭二进制日志记录** 您不能直接为 Amazon RDS 数据库实例关闭二进制日志记录，但可以通过执行以下操作来关闭它： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (外部) | **在外部 MySQL 数据库上关闭二进制日志记录** 连接到 MySQL 数据库并调用 `STOP REPLICATION` 命令。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# 使用 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 数据库集群](Aurora.CreateInstance.md)。
在 MySQL 数据库实例与 Amazon Aurora 数据库集群之间设置复制时，请确保遵循以下准则：
+ 当您引用 Amazon Aurora 数据库集群时，使用 Amazon Aurora MySQL 数据库集群端点地址。如果发生故障转移，则提升为 Aurora 数据库集群主实例的 Aurora MySQL 副本继续使用数据库集群端点地址。
+ 在您的写入器实例上维护二进制日志，直至您确认其已应用于 Aurora 副本。这种维护将确保您可以在发生故障时还原写入器实例。
**重要**
当使用自管理复制时，您负责监控和解决可能发生的所有复制问题。有关更多信息，请参阅 [诊断并解决只读副本之间的滞后](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)。
**注意**
对 Aurora MySQL 数据库集群启动复制功能所需的权限受到限制且对 Amazon RDS 主用户不可用。为此，您必须使用 [mysql.rds\$1set\$1external\$1master（Aurora MySQL 版本 2）](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) 或 [mysql.rds\$1set\$1external\$1source（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) 和 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 过程来设置 Aurora MySQL 数据库集群和 MySQL 数据库实例之间的复制。
## 启动外部源实例和 Aurora MySQL 数据库集群之间的复制
1. 将源 MySQL 数据库实例设为只读：
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 对源 MySQL 数据库实例运行 `SHOW MASTER STATUS` 命令以确定二进制日志位置。将会收到类似于以下示例的输出：
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. 使用 `mysqldump` 将数据库从外部 MySQL 数据库实例复制到 Amazon Aurora MySQL 数据库集群。对于非常大的数据库，您可能希望使用《Amazon Relational Database Service 用户指南》**中的[将数据导入到 Amazon RDS for MySQL 数据库并减少停机时间](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html)中的过程。
对于 Linux、macOS 或 Unix：
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
对于：Windows
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**注意**
确保 `-p` 选项和输入的密码之间没有空格。
在 `--host` 命令中使用 `--user (-u)`、`--port`、`-p` 和 `mysql` 选项，以指定用于连接到 Aurora 数据库集群的主机名、用户名、端口和密码。主机名是 Amazon Aurora 数据库集群端点中的 DNS 名称，例如 `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`。您可以在 Amazon RDS 管理控制台上的集群详细信息中找到端点值。
1. 再次将源 MySQL 数据库实例设为可写：
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
有关生成备份以用于复制的更多信息，请参阅 MySQL 文档中的[http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html)。
1. 在 Amazon RDS 管理控制台中，将托管源 MySQL 数据库的服务器的 IP 地址添加到 Amazon Aurora 数据库集群的 VPC 安全组。有关修改 VPC 安全组的更多信息，请参阅 *Amazon Virtual Private Cloud 用户指南* 中的[您的 VPC 的安全组](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。
您可能还需要配置本地网络以允许来自 Amazon Aurora 数据库集群的 IP 地址的连接，以便它能与源 MySQL 实例进行通信。要查找 Amazon Aurora 数据库集群的 IP 地址，请使用 `host` 命令。
```
host aurora_endpoint_address
```
主机名是 Amazon Aurora 数据库集群端点中的 DNS 名称。
1. 通过使用所选的客户端，连接到外部 MySQL 实例并创建用于复制的 MySQL 用户。此账户仅用于复制，并且必须仅供您的域使用以增强安全性。以下是示例。
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. 对于外部 MySQL 实例，向复制用户授予 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限。例如，要为您的域的“`REPLICATION CLIENT`”用户授予对所有数据库的 `REPLICATION SLAVE` 和 `repl_user` 权限，请发出以下命令。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. 在设置复制之前，请创建 Aurora MySQL 数据库集群的手动快照以作为只读副本。如果您需要将数据库集群作为只读副本来重新建立复制，则可从此快照还原 Aurora MySQL 数据库集群，而不必将 MySQL 数据库实例中的数据导入新的 Aurora MySQL 数据库集群。
1. 使 Amazon Aurora 数据库集群成为副本。以主用户身份连接到 Amazon Aurora 数据库集群，并通过使用 [mysql.rds\$1set\$1external\$1master（Aurora MySQL 版本 2）](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)或 [mysql.rds\$1set\$1external\$1source（Aurora MySQL 版本 3）](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)和 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 过程将源 MySQL 数据库确定为复制源。
使用在步骤 2 中确定的二进制日志文件名和位置。示例如下：
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. 在 Amazon Aurora 数据库集群上，调用 [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) 过程以开始复制。
```
CALL mysql.rds_start_replication;
```
在源 MySQL 数据库实例与 Amazon Aurora 数据库集群之间建立复制之后，可以将 Aurora 副本添加到 Amazon Aurora 数据库集群。随后可以连接到 Aurora 副本以对数据进行读取扩展。有关创建 Aurora 副本的信息，请参阅[将 Aurora 副本添加到数据库集群](aurora-replicas-adding.md)。
# 优化 Aurora MySQL 的二进制日志复制
接下来，您可以了解如何优化二进制日志复制性能和排查 Aurora MySQL 中的相关问题。
**提示**
本讨论假定您熟悉 MySQL 二进制日志复制机制及其工作原理。有关背景信息，请参阅 MySQL 文档中的[复制实施](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html)。
## 多线程二进制日志复制
使用多线程二进制日志复制时，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-replication-gtid.md)。
以下配置选项可以帮助您优化多线程复制。有关使用信息，请参阅 *MySQL 参考手册*中的[复制和二进制日志记录选项和变量](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html)。有关多线程复制的更多信息，请参阅 MySQL 博客 [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/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` 指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。
## 内存中继日志
在 Aurora MySQL 版本 3.10 及更高版本中，Aurora 引入了称为内存中继日志的优化来提高复制吞吐量。此优化通过在内存中缓存所有中间中继日志内容来增强中继日志 I/O 性能。因此，它通过最大限度地减少存储 I/O 操作来减少提交延迟，因为中继日志内容在内存中仍然保持可供随时访问。
默认情况下，当副本满足以下任何配置时，会自动为 Aurora 托管式复制场景（包括蓝绿部署、Aurora-Aurora 复制以及跨区域副本）启用内存中继日志功能：
+ 单线程复制模式（replica\$1parallel\$1workers = 0）
+ 启用了 GTID 模式的多线程复制：
+ 启用了自动定位
+ 副本上的 GTID 模式设置为 ON
+ 在 replica\$1preserve\$1commit\$1order = ON 时进行基于文件的复制
大于 t3.large 的实例类支持内存中继日志功能，但此功能在 Aurora Serverless 实例上不可用。中继日志循环缓冲区的固定大小为 128 MB。要监控此功能的内存消耗，可以运行以下查询：
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
内存中继日志功能由 aurora\$1in\$1memory\$1relaylog 参数控制，该参数可以在数据库集群或实例级别进行设置。可以在不重新启动实例的情况下动态启用或禁用此功能：
1. 停止正在进行的复制
1. 在参数组中将 aurora\$1in\$1memory\$1relaylog 设置为 ON（启用）或 OFF（禁用）
1. 重新启动复制
示例：
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
即使 aurora\$1in\$1memory\$1relaylog 设置为 ON，在某些条件下，内存中继日志功能仍可能被禁用。要验证该功能的当前状态，可以使用以下命令：
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
如果意外禁用了该功能，则可以通过运行以下命令来确定原因：
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
此命令返回一条消息，解释当前禁用该功能的原因。
# 为 Aurora MySQL 设置增强型二进制日志
增强型二进制日志可减少开启二进制日志所导致的计算性能开销，在某些情况下，该开销最高可达 50%。使用增强型二进制日志，这种开销可以减少到大约 13%。为了减少开销，增强型二进制日志将二进制和事务日志并行写入存储，从而最大限度地减少在事务提交时间写入的数据。
与社区 MySQL 二进制日志相比，使用增强型二进制日志还可以将重启和故障转移后的数据库恢复时间缩短多达 99%。增强型二进制日志与现有的基于二进制日志的工作负载兼容，您与其交互的方式和您与社区 MySQL 二进制日志交互的方式相同。
增强型二进制日志在 Aurora MySQL 版本 3.03.1 及更高版本上可用。
**Topics**
+ [配置增强型二进制日志参数](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [其他相关参数](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [增强型二进制日志和社区 MySQL 二进制日志之间的区别](#AuroraMySQL.Enhanced.binlog.differences)
+ [增强型二进制日志的 Amazon CloudWatch 指标](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [增强型二进制日志限制](#AuroraMySQL.Enhanced.binlog.limitations)
## 配置增强型二进制日志参数
您可以通过开启/关闭增强型二进制日志参数，在社区 MySQL 二进制日志和增强型二进制日志之间切换。现有的二进制日志使用者可以继续读取和使用二进制日志文件，而不会在二进制日志文件序列中出现任何间隔。
要开启增强型二进制日志，请设置以下参数：
| 参数 | 默认值 | 描述 |
| --- | --- | --- |
| binlog\$1format | – | 将 binlog\$1format 参数设置为您选择的二进制日志记录格式，以开启增强型二进制日志。确保 binlog\$1format parameter 未设置为 OFF。有关更多信息，请参阅[配置 Aurora MySQL 二进制日志记录](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html)。 |
| aurora\$1enhanced\$1binlog | 0 | 在与 Aurora MySQL 集群关联的数据库集群参数组中，将此参数的值设置为 1。更改此参数的值时，当 DBClusterParameterGroupStatus 值显示为 pending-reboot 时，必须重启写入器实例。 |
| binlog\$1backup | 1 | 关闭此参数可开启增强型二进制日志。为此，请将此参数的值设置为 0。 |
| binlog\$1replication\$1globaldb | 1 | 关闭此参数可开启增强型二进制日志。为此，请将此参数的值设置为 0。 |
**重要**
只有在使用增强型二进制日志时，才能关闭 `binlog_backup` 和 `binlog_replication_globaldb` 参数。
要关闭增强型二进制日志，请设置以下参数：
| 参数 | 描述 |
| --- | --- |
| aurora\$1enhanced\$1binlog | 在与 Aurora MySQL 集群关联的数据库集群参数组中，将此参数的值设置为 0。每当您更改此参数的值时，当 DBClusterParameterGroupStatus 值显示为 pending-reboot 时，必须重启写入器实例。 |
| binlog\$1backup | 关闭增强型二进制日志时开启此参数。为此，请将此参数的值设置为 1。 |
| binlog\$1replication\$1globaldb | 关闭增强型二进制日志时开启此参数。为此，请将此参数的值设置为 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）。
要在还原或克隆操作后开启增强型二进制日志，请在还原或克隆的数据库集群上设置所需的数据库集群参数。有关更多信息，请参阅 [配置增强型二进制日志参数](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)。
**Example 示例：开启增强型二进制日志时执行的克隆或还原操作**
源数据库集群：
```
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)
```
**Example 示例：关闭增强型二进制日志时执行的克隆或还原操作**
源数据库集群：
```
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-bin-changelog.000003` 之后禁用了增强型二进制日志。在还原或克隆的数据库集群上，关闭增强型二进制日志后写入的二进制日志文件可用。
```
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）。
要在故障转移后开启增强型二进制日志，您必须在辅助数据库集群上设置所需的数据库集群参数。有关更多信息，请参阅 [配置增强型二进制日志参数](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)。
**Example 示例：开启增强型二进制日志时执行全球数据库失效转移操作**
旧的主数据库集群（故障转移前）：
```
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)
```
**Example 示例：关闭增强型二进制日志时执行全球数据库失效转移操作**
源数据库集群：
```
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-bin-changelog.000003` 之后禁用了增强型二进制日志。关闭增强型二进制日志后写入的二进制日志文件会被复制，并在新提升的数据库集群中可用。
```
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`
+ 您无法删除或重命名数据库中损坏的表。要删除这些表，您可以联系 支持。
+ 开启增强型二进制日志时，会禁用二进制日志 I/O 缓存。有关更多信息，请参阅 [优化 Aurora MySQL 的二进制日志复制](binlog-optimization.md)。
**注意**
增强型二进制日志提供了与二进制日志 I/O 缓存类似的读取性能改进以及更好的写入性能改进。
+ 不支持回溯特征。在以下情况下，无法在数据库集群中开启增强型二进制日志：
+ 当前已启用回溯特征的数据库集群。
+ 先前已启用但现在禁用回溯功能的数据库集群。
+ 从启用了回溯特征的源数据库集群或快照中还原的数据库集群。
# 使用基于 GTID 的复制
以下内容说明了如何在 Aurora MySQL 集群和外部源之间使用采用二进制日志（binlog）复制的全局事务标识符（GTID）。
**注意**
对于 Aurora，只能通过对外部 MySQL 数据库使用二进制日志复制的 Aurora MySQL 集群使用此功能。另一个数据库可能是其他 AWS 区域的 Amazon RDS MySQL 实例、本地 MySQL 数据库或 Aurora 数据库集群。要了解如何配置此类复制，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
如果您使用的是二进制日志复制，不熟悉 MySQL 的基于 GTID 的复制，请参阅 MySQL 文档中的 [Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html)。
Aurora MySQL 版本 2 和 3 支持基于 GTID 的复制。
**Topics**
+ [全局事务标识符 (GTID) 概述](#mysql-replication-gtid.overview)
+ [基于 GTID 的复制的参数](#mysql-replication-gtid.parameters)
+ [为 Aurora MySQL 集群启用基于 GTID 的复制](mysql-replication-gtid.configuring-aurora.md)
+ [为Aurora MySQL 数据库集群禁用基于 GTID 的复制](mysql-replication-gtid.disabling.md)
## 全局事务标识符 (GTID) 概述
*全局事务标识符 (GTID)* 是为提交的 MySQL 事务生成的唯一标识符。您可以使用 GTID 让二进制日志复制的故障排除更加简单便捷。
**注意**
当 Aurora 在集群中的数据库实例之间同步数据时，该复制机制不会涉及二进制日志 (binlog)。对于 Aurora MySQL，基于 GTID 的复制仅在您还使用二进制日志复制从外部的 MySQL 兼容数据向 Aurora MySQL 数据库集群复制或从中复制时应用。
MySQL 使用两种不同类型的事务进行二进制日志复制：
+ *GTID 事务* – 由 GTID 标识的事务。
+ *匿名事务* – 未分配 GTID 的事务。
在复制配置中，GTID 在所有数据库实例中是唯一的。GTID 简化了复制配置，因为在使用它们时，您不必引用日志文件位置。通过使用 GTID，还可以更轻松地跟踪复制的事务并确定源实例和副本是否一致。
在从外部的 MySQL 兼容数据向 Aurora 集群复制时，通常使用 Aurora 的基于 GTID 的复制。您可以将此复制配置设置为从本地数据库或 Amazon RDS 数据库迁移到 Aurora MySQL 的一部分。如果外部数据库已使用 GTID，为 Aurora 集群启用基于 GTID 的复制可以简化复制过程。
为 Aurora MySQL 集群配置基于 GTID 的复制的方法是先在数据库集群参数组中设置相关配置参数。然后将该参数组与集群关联。
## 基于 GTID 的复制的参数
可以使用以下参数配置基于 GTID 的复制。
| 参数 | 有效值 | 描述 |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` 指定新事务是匿名事务（即，没有 GTID），并且事务必须是匿名事务才能复制。 `OFF_PERMISSIVE` 指定新事务是匿名事务，但可以复制所有事务。 `ON_PERMISSIVE` 指定新事务是 GTID 事务，但可以复制所有事务。 `ON` 指定新事务是 GTID 事务，并且事务必须是 GTID 事务才能复制。 |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` 允许事务违反 GTID 一致性。 `ON` 禁止事务违反 GTID 一致性。 `WARN` 允许事务违反 GTID 一致性，但在违反一致性时生成警告。 |
**注意**
在 AWS 管理控制台中，`gtid_mode` 参数显示为 `gtid-mode`。
对于基于 GTID 的复制，请为 Aurora MySQL 数据库集群的数据库集群参数组使用这些设置：
+ `ON` 和 `ON_PERMISSIVE` 仅适用于从 Aurora MySQL 集群的传出复制。这两个值都可以让 Aurora 数据库集群为复制到外部数据库的事务使用 GTID。`ON` 要求外部数据库也使用基于 GTID 的复制。`ON_PERMISSIVE` 让基于 GTID 的复制成为外部数据库上的可选项。
+ `OFF_PERMISSIVE`（如果设置）表明您的 Aurora 数据库集群可以接受来自外部数据库的传入复制。不论外部数据库是否使用基于 GTID 的复制，它都可以接受。
+ `OFF`（如果设置）表明您的 Aurora 数据库集群只接受来自不使用基于 GTID 的复制的外部数据库的传入复制。
**提示**
传入复制是 Aurora MySQL 集群最常见的二进制日志复制场景。对于传入复制，建议您将 GTID 模式设置为 `OFF_PERMISSIVE`。该设置允许来自外部数据库的传入复制，不论复制源的 GTID 设置如何。
有关参数组的更多信息，请参阅 [Amazon Aurora 的参数组](USER_WorkingWithParamGroups.md)。
# 为 Aurora MySQL 集群启用基于 GTID 的复制
在为 Aurora MySQL 数据库集群启用了基于 GTID 的复制后，GTID 设置将应用于入站和出站两种二进制日志复制。
**为 Aurora MySQL 集群启用基于 GTID 的复制**
1. 使用以下参数设置创建或编辑数据库集群参数组：
+ `gtid_mode` – `ON` 或 `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. 将数据库集群参数组与 Aurora MySQL 集群关联。为此，请按照 [Amazon Aurora 的参数组](USER_WorkingWithParamGroups.md) 中的过程进行操作。
1. （可选）指定如何将 GTID 分配给不包括它们的事务。为实现此目的，请在 [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions（Aurora MySQL 版本 3）](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions) 中调用已存储的过程。
# 为Aurora MySQL 数据库集群禁用基于 GTID 的复制
您可以为 Aurora MySQL 数据库集群禁用基于 GTID 的复制。这样做意味着 Aurora 集群不能对使用基于 GTID 的复制的外部数据库执行入站或出站二进制日志复制。
**注意**
在以下过程中，*只读副本* 表示采用对外部数据库执行二进制日志复制的 Aurora 配置中的复制目标。它不表示只读 Aurora 副本数据库实例。例如，当 Aurora 集群接受来自外部源的传入复制时，Aurora 主实例充当二进制日志复制的只读副本。
有关此部分提到的存储过程的更多详细信息，请参阅 [Aurora MySQL 存储过程参考](AuroraMySQL.Reference.StoredProcs.md)。
**为 Aurora MySQL 数据库集群禁用基于 GTID 的复制**
1. 在 Aurora 副本上，运行以下过程：
对于版本 3
```
CALL mysql.rds_set_source_auto_position(0);
```
对于版本 2
```
CALL mysql.rds_set_master_auto_position(0);
```
1. 将 `gtid_mode` 重置为 `ON_PERMISSIVE`。
1. 确保与 Aurora MySQL 集群关联的数据库集群参数组将 `gtid_mode` 设置为 `ON_PERMISSIVE`。
有关使用参数组设置配置参数的更多信息，请参阅 [Amazon Aurora 的参数组](USER_WorkingWithParamGroups.md)。
1. 重启 Aurora MySQL 数据库集群。
1. 将 `gtid_mode` 重置为 `OFF_PERMISSIVE`。
1. 确保与 Aurora MySQL 集群关联的数据库集群参数组将 `gtid_mode` 设置为 `OFF_PERMISSIVE`。
1. 重启 Aurora MySQL 数据库集群。
1. 等待在 Aurora 主实例上应用所有 GTID 事务。要检查是否应用了这些事务，请按以下步骤操作：
1. 在 Aurora 主实例上，运行 `SHOW MASTER STATUS` 命令。
您的输出应类似于以下输出。
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
记下输出中的文件和位置。
1. 在每个只读副本上，使用上一步中的源实例上的文件和位置信息运行以下查询：
对于版本 3
```
SELECT SOURCE_POS_WAIT('file', position);
```
对于版本 2
```
SELECT MASTER_POS_WAIT('file', position);
```
例如，如果文件名是 `mysql-bin-changelog.000031` 并且位置是 `107`，请运行以下语句：
对于版本 3
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
对于版本 2
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. 重置 GTID 参数以禁用基于 GTID 的复制。
1. 确保与 Aurora MySQL 集群关联的数据库集群参数组具有以下参数设置：
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. 重启 Aurora MySQL 数据库集群。