Amazon Aurora MySQL 参考
此参考包括有关 Aurora MySQL 参数、状态变量和常规 SQL 扩展或与社区 MySQL 数据库引擎的差异的信息。
主题
Aurora MySQL 配置参数
您可以使用数据库参数组中的参数按照与管理其他 Amazon RDS MySQL 数据库实例相同的方法管理 Amazon Aurora 数据库集群。Amazon Aurora 不同于其他数据库引擎，因为您具有一个包含多个数据库实例的数据库集群。因此，您用于管理 Aurora MySQL 数据库集群的有些参数将应用于整个集群。其他参数则仅应用于数据库集群中的特定数据库实例。
要管理集群级参数，请使用数据库集群参数组。要管理实例级参数，请使用数据库参数组。Aurora MySQL 数据库集群中的每个数据库实例均与 MySQL 数据库引擎兼容。不过，您在集群级别应用某些 MySQL 数据库引擎参数，并使用数据库集群参数组管理这些参数。您无法在 Aurora 数据库集群中实例的数据库参数组中查找集群级参数。本主题后面提供了集群级参数的列表。
您可以使用Amazon Web Services Management Console、Amazon CLI 或 Amazon RDS API 管理集群级参数和实例级参数。您可以使用单独的命令管理集群级参数和实例级参数。例如，您可以使用 modify-db-cluster-parameter-group CLI 命令来管理数据库集群参数组中的集群级参数。您可以使用 modify-db-parameter-group CLI 命令来为数据库集群中的数据库实例管理数据库参数组中的实例级参数。
您可以在控制台中或者使用 CLI 或 RDS API 查看集群级别和实例级别的参数。例如，您可以使用 describe-db-cluster-parameters Amazon CLI 命令来查看数据库集群参数组中的集群级参数。您可以使用 describe-db-parameters CLI 命令来查看数据库集群中数据库实例的数据库参数组中的实例级参数。
每个默认参数组包含参数组中所有参数的默认值。如果该参数具有此值的“引擎默认值”，请参阅特定版本的 MySQL 或 PostgreSQL 文档获取实际默认值。
有关数据库参数组的更多信息，请参阅 使用参数组。有关 Aurora Serverless 集群的规则和限制，请参阅Aurora Serverless v1 的参数组。
集群级别的参数
下表显示了适用于整个 Aurora MySQL 数据库集群的所有参数。
| 参数名称 | 可修改 | 备注 |
|---|---|---|
|
|
是 |
仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）。已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）。 |
|
|
是 |
仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）。已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
有关更多信息，请参阅“Amazon Aurora MySQL 复制的性能注意事项”。不适用于作为 Aurora 全局数据库的一部分的集群。已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
有关更多信息，请参阅“Amazon Aurora MySQL 复制的性能注意事项”。不适用于作为 Aurora 全局数据库的一部分的集群。已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
此设置在 Aurora MySQL 版本 1 和 3 中可用，但实际并未使用。 |
|
|
是 |
该设置在 Aurora MySQL 2.10 及更高版本中默认开启。有关更多信息，请参阅“Amazon Aurora MySQL 的零停机重启 (ZDR)”。 |
|
|
是 |
有关更多信息，请参阅将数据从 Amazon S3 存储桶中的文本文件加载到 Amazon Aurora MySQL 数据库集群。目前在 Aurora MySQL 版本 3 中不可用。使用 |
|
|
是 |
有关更多信息，请参阅将数据从 Amazon Aurora MySQL 数据库集群保存到 Amazon S3 存储桶中的文本文件。目前在 Aurora MySQL 版本 3 中不可用。使用 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
有关更多信息，请参阅“从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数”。 |
|
|
是 |
|
|
|
是 |
如果未设置此参数，Amazon CLI 和 RDS API 将报告 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
有关更多信息，请参阅Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
否 |
|
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
|
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 集群对所有数据使用 InnoDB 存储引擎。 |
|
|
有时 |
在 Aurora MySQL 版本 2.04 及更高版本中可修改。 |
|
|
是 |
指示事件计划程序的状态。 在 Aurora MySQL 版本 3 中，只能在集群级别修改。 |
|
|
有时 |
在 Aurora MySQL 版本 2.04 及更高版本中可修改。 |
|
|
是 |
|
|
|
否 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
是 |
此选项用于在 Aurora MySQL 版本 3 上禁用死锁检测。 在高并发系统中，当许多线程等待同一个锁时，死锁检测可能会导致速度下降。有关此参数的更多信息，请参阅 MySQL 文档。 |
|
|
是 |
此参数影响表存储的组织方式。有关更多信息，请参阅存储扩展。 |
|
|
Aurora MySQL 版本 1 和 2：是 Aurora MySQL 版本 3：否 |
对于 Aurora MySQL 版本 1 和 2，我们强烈建议使用原定设置值 1。 对于 Aurora MySQL 版本 3，Aurora 始终使用原定设置值 1。 有关更多信息，请参阅配置刷新日志缓冲区的频率。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
否 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
MyISAM 表的密钥缓存。有关更多信息，请参阅密钥缓存 -> cache_lock 互斥锁。 |
|
|
是 |
|
|
|
是（Aurora MySQL 版本 1 和 2），仅在集群创建时（Aurora MySQL 版本 3） |
在 Aurora MySQL 版本 2.10 及更高的 2.x 版本中，请确保在更改此设置并重启写入器实例后重启所有读取器实例。有关详细信息，请参阅重启 Aurora MySQL 集群（版本 2.10 及更高版本）。在 Aurora MySQL 版本 3 中，此参数的值在创建集群时永久设置。如果对此选项使用非原定设置值，请在升级之前设置 Aurora MySQL 版本 3 自定义参数组，然后在创建版本 3 集群的快照还原操作期间指定参数组。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
否 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
有关更多信息，请参阅“将 SSL/TLS 与 Aurora MySQL 数据库集群配合使用”。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
有关将日志上传到 Amazon CloudWatch Logs 的说明，请参阅将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs。 |
|
|
否 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
仅适用于 Aurora MySQL 版本 2 的集群，具备 MySQL 5.7 兼容性。 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
有关更多信息，请参阅“Aurora MySQL 的 TLS 版本”。 |
实例级参数
下表显示了适用于 Aurora MySQL 数据库集群中特定数据库实例的所有参数。
| 参数名称 | 可修改 | 备注 |
|---|---|---|
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
否 |
|
|
|
是 |
有关更多信息，请参阅Amazon Aurora MySQL 实验室模式。已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
此参数仅适用于 Aurora MySQL 版本 1.18 及更高版本。Aurora MySQL 版本 2 或 3 中不使用此参数。有关更多信息，请参阅 Amazon Aurora MySQL 内存不足问题 。 |
|
|
是 |
设置为 |
|
|
是 |
设置为 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
否 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
有时 |
指示事件计划程序的状态。 在 Aurora MySQL 版本 3 中，只能在集群级别修改。 |
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
有关将日志上传到 CloudWatch Logs 的说明，请参阅 将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs。 |
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
修改此参数不起作用，因为 Aurora 的 |
|
|
是 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
是 |
默认值由公式表示。有关公式中 |
|
|
否 |
Aurora MySQL 完全不使用 InnoDB 更改缓冲区。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
修改此参数不起作用，因为 Aurora 的 |
|
|
是 |
此选项用于在 Aurora MySQL 版本 3 上禁用死锁检测。 在高并发系统中，当许多线程等待同一个锁时，死锁检测可能会导致速度下降。有关此参数的更多信息，请参阅 MySQL 文档。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
否 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
否 |
Aurora MySQL 根据集群类型管理数据库实例的只读和读/写状态。例如，预置的集群具有一个读/写数据库实例（主实例），并且集群中的所有其他实例都是只读的（Aurora 副本）。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
修改此参数不起作用，因为 Aurora 的 |
|
|
是 |
Aurora 会估计 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
MyISAM 表的密钥缓存。有关更多信息，请参阅密钥缓存 -> cache_lock 互斥锁。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
将 |
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
否 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
默认值由公式表示。有关公式中 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
有关使用此开关的 Aurora MySQL 功能的信息，请参阅 Amazon Aurora MySQL 的最佳实践。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
仅限 Aurora MySQL 2.x |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
否 |
Aurora MySQL 管理连接属性，并为集群中的所有数据库实例强制执行一致的设置。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
默认值由公式表示。有关公式中 已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
Aurora MySQL 根据集群类型管理数据库实例的只读和读/写状态。例如，预置的集群具有一个读/写数据库实例（主实例），并且集群中的所有其他实例都是只读的（Aurora 副本）。更改此参数可以将写入器实例切换为只读状态。无论此参数的值如何，任何读取器实例始终处于只读状态。 |
|
|
是 |
|
|
|
否 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
否 |
|
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
否 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
Aurora MySQL 版本 1 和 2。在 Aurora MySQL 版本 3 中使用 |
|
|
是 |
Aurora MySQL 版本 3 及更高版本 |
|
|
是 |
|
|
|
是 |
有关将日志上传到 CloudWatch Logs 的说明，请参阅 将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs。 |
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
|
|
|
是 |
此参数适用于 Aurora MySQL 3 及更高版本。 |
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
|
|
|
是 |
|
|
|
否 |
|
|
|
是 |
默认值由公式表示。有关公式中 |
|
|
是 |
默认值由公式表示。有关公式中 |
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。有关详细信息，请参阅Aurora MySQL 版本 3 中的新临时表行为。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。有关详细信息，请参阅Aurora MySQL 版本 3 中的新临时表行为。 |
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。有关详细信息，请参阅Aurora MySQL 版本 3 中的新临时表行为。 |
|
|
否 |
|
|
|
是 |
|
|
|
是 |
|
|
|
是 |
|
|
|
否 |
Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
|
|
是 |
|
|
|
是 |
此参数适用于 Aurora MySQL 版本 3 及更高版本。它将代替 |
|
|
是 |
|
|
|
是 |
已从 Aurora MySQL 版本 3 中删除。它将替换为 |
|
|
是 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
否 |
|
|
|
是 |
Aurora 会估计 |
不适用于 Aurora MySQL 的 MySQL 参数
由于 Aurora MySQL 与 MySQL 之间存在架构差异，有些 MySQL 参数不适用于 Aurora MySQL。
以下 MySQL 参数不适用于 Aurora MySQL。此列表并不详尽。
-
activate_all_roles_on_login– 此参数不适用于 Aurora MySQL 版本 1 和 2。它在 Aurora MySQL 版本 3 中可用。 -
big_tables -
bind_address -
character_sets_dir -
innodb_adaptive_flushing -
innodb_adaptive_flushing_lwm -
innodb_buffer_pool_chunk_size -
innodb_buffer_pool_instances -
innodb_change_buffering -
innodb_checksum_algorithm -
innodb_data_file_path -
innodb_deadlock_detect– 此参数不适用于 Aurora MySQL 版本 1 和 2。它在 Aurora MySQL 版本 3 中可用。 -
innodb_dedicated_server -
innodb_default_row_format -
innodb_doublewrite -
innodb_flush_log_at_timeout– 此参数不适用于 Aurora MySQL。有关更多信息，请参阅配置刷新日志缓冲区的频率。 -
innodb_flush_method -
innodb_flush_neighbors -
innodb_io_capacity -
innodb_io_capacity_max -
innodb_log_buffer_size -
innodb_log_file_size -
innodb_log_files_in_group -
innodb_log_spin_cpu_abs_lwm -
innodb_log_spin_cpu_pct_hwm -
innodb_max_dirty_pages_pct -
innodb_numa_interleave -
innodb_page_size -
innodb_redo_log_capacity -
innodb_redo_log_encrypt -
innodb_undo_log_encrypt -
innodb_undo_log_truncate -
innodb_use_native_aio -
innodb_write_io_threads -
thread_cache_size
不适用于 Aurora MySQL 的 MySQL 状态变量
由于 Aurora MySQL 与 MySQL 之间存在架构差异，有些 MySQL 状态变量不适用于 Aurora MySQL。
以下 MySQL 状态变量不适用于 Aurora MySQL。此列表并不详尽。
-
innodb_buffer_pool_bytes_dirty -
innodb_buffer_pool_pages_dirty -
innodb_buffer_pool_pages_flushed
Aurora MySQL 版本 3 删除了 Aurora MySQL 版本 2 中的以下状态变量：
-
AuroraDb_lockmgr_bitmaps0_in_use -
AuroraDb_lockmgr_bitmaps1_in_use -
AuroraDb_lockmgr_bitmaps_mem_used -
AuroraDb_thread_deadlocks -
available_alter_table_log_entries -
Aurora_lockmgr_memory_used -
Aurora_missing_history_on_replica_incidents -
Aurora_new_lock_manager_lock_release_cnt -
Aurora_new_lock_manager_lock_release_total_duration_micro -
Aurora_new_lock_manager_lock_timeout_cnt -
Aurora_oom_response -
Aurora_total_op_memory -
Aurora_total_op_temp_space -
Aurora_used_alter_table_log_entries -
Aurora_using_new_lock_manager -
Aurora_volume_bytes_allocated -
Aurora_volume_bytes_left_extent -
Aurora_volume_bytes_left_total -
Com_alter_db_upgrade -
Compression -
External_threads_connected -
Innodb_available_undo_logs -
Last_query_cost -
Last_query_partial_plans -
Slave_heartbeat_period -
Slave_last_heartbeat -
Slave_received_heartbeats -
Slave_retried_transactions -
Slave_running -
Time_since_zero_connections
这些 MySQL 状态变量在 Aurora MySQL 版本 1 或 2 中可用，但它们在 Aurora MySQL 版本 3 中不可用：
-
Innodb_redo_log_enabled -
Innodb_undo_tablespaces_total -
Innodb_undo_tablespaces_implicit -
Innodb_undo_tablespaces_explicit -
Innodb_undo_tablespaces_active
Aurora MySQL 等待事件
以下是 Aurora MySQL 的一些常见等待事件。
有关 MySQL 等待事件中使用的命名约定的信息，请参阅 MySQL 文档中的性能架构测试命名约定
- cpu
-
准备运行的活动连接数一直高于 vCPU 的数量。有关更多信息，请参阅cpu。
- io/aurora_redo_log_flush
-
会话将数据持久存储到 Aurora 存储。通常，该等待事件针对 Aurora MySQL 中的写入 I/O 操作。有关更多信息，请参阅io/aurora_redo_log_flush。
- io/aurora_respond_to_client
-
以下 Aurora MySQL 版本的查询处理已完成，结果将返回到应用程序客户端：2.10.2 及更高的 2.10.x 版本、2.09.3 及更高的 2.09.x 版本、2.07.7 及更高的 2.07.x 版本以及 1.22.6 及更高的 1.22.x 版本。将数据库实例类的网络带宽与返回的结果集的大小进行比较。另外，请检查客户端响应时间。如果客户端无响应且无法处理 TCP 数据包，则可能会发生数据包丢弃和 TCP 重新传输。这种情况会对网络带宽产生负面影响。在低于 2.10.2、2.09.3、2.07.7 和 1.22.6 的版本中，等待事件错误地包含空闲时间。要了解如何在此等待突出时优化数据库，请参阅 io/aurora_respond_to_client。
- io/file/csv/data
-
线程以逗号分隔值 (CSV) 格式写入表。检查您的 CSV 表使用情况。此事件的典型原因是在表上设置
log_output。 - io/file/innodb/innodb_data_file
-
线程正在等待来自存储的输入/输出。此事件在输入/输出密集型工作负载中更普遍。当此等待事件普遍存在时，SQL 语句可能会运行磁盘密集型查询或请求无法从 InnoDB 缓冲池得到满足的数据。有关更多信息，请参阅io/file/innodb/innodb_data_file。
- io/file/sql/binlog
-
线程在等待正写入磁盘的二进制日志 (binlog) 文件。
- io/socket/sql/client_connection
-
mysqld程序正忙于创建线程来处理传入的新客户端连接。有关更多信息，请参阅io/socket/sql/client_connection。 - io/table/sql/handler
-
引擎正在等待访问表格。无论数据是缓存在缓冲池中还是可在磁盘上访问，都会发生此事件。有关更多信息，请参阅io/table/sql/handler。
- lock/table/sql/handler
-
该等待事件是表锁定等待事件处理程序。有关性能架构中的“原子”和“分子”事件的更多信息，请参阅 MySQL 文档中的性能架构原子和分子事件
。 - synch/cond/mysys/my_thread_var::suspend
-
由于另一个线程发出
LOCK TABLES ... READ，等待表级锁定时线程被暂停。 - synch/cond/sql/MDL_context::COND_wait_status
-
线程正等待表元数据锁定。引擎使用这种类型的锁定来管理对数据库架构的并发访问并确保数据的一致性。有关更多信息，请参阅 MySQL 文档中的优化锁定操作
。要了解如何在此事件突出时优化数据库，请参阅 synch/cond/sql/MDL_context::COND_wait_status。 - synch/cond/sql/MYSQL_BIN_LOG::COND_done
-
您已开启二进制日志记录。可能存在较高的提交吞吐量、大量事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中，使用全局数据库而不是二进制日志复制，或者使用
aurora_binlog_*参数。 - synch/mutex/innodb/aurora_lock_thread_slot_futex
-
多个数据操作语言 (DML) 语句同时访问相同的数据库行。有关更多信息，请参阅synch/mutex/innodb/aurora_lock_thread_slot_futex。
- synch/mutex/innodb/buf_pool_mutex
-
缓冲池不够大，无法容纳正常工作的数据集。或者，工作负载访问特定表中的页面，这会导致缓冲池中的争用。有关更多信息，请参阅synch/mutex/innodb/buf_pool_mutex。
- synch/mutex/innodb/fil_system_mutex
-
该进程正在等待对表空间内存缓存的访问。有关更多信息，请参阅synch/mutex/innodb/fil_system_mutex。
- synch/mutex/innodb/os_mutex
-
此事件是事件信号灯的一部分。它提供了对用于线程之间信号的变量的独占访问权限。用途包括统计线程、全文搜索、缓冲池转储和加载操作以及日志刷新。此等待事件特定于 Aurora MySQL 版本 1。
- synch/mutex/innodb/trx_sys_mutex
-
操作正在以一致或受控的方式在 InnoDB 中检查、更新、删除或添加事务 ID。这些操作需要
trx_sys互斥调用，该调用由性能架构工具跟踪。操作包括在数据库启动或关闭时管理事务系统、回滚、撤消清理、行读取访问和缓冲池加载。高数据库负载和大量事务导致此等待事件频繁出现。有关更多信息，请参阅synch/mutex/innodb/trx_sys_mutex。 - synch/mutex/mysys/KEY_CACHE::cache_lock
-
keycache->cache_lock互斥控制对 MyISAM 表的密钥缓存的访问。虽然 Aurora MySQL 不允许使用 MyISAM 表来存储持久数据，但它们用于存储内部临时表。考虑检查created_tmp_tables或created_tmp_disk_tables状态计数器，因为在某些情况下，当临时表不再适合放入内存中时，会将其写入磁盘。 - synch/mutex/sql/FILE_AS_TABLE::LOCK_offsets
-
在打开或创建表元数据文件时，引擎会获取此互斥。当此等待事件发生频率过高时，创建或打开的表的数量会激增。
- synch/mutex/sql/FILE_AS_TABLE::LOCK_shim_lists
-
引擎在跟踪打开的表的内部结构上执行以下操作（如
reset_size、detach_contents或add_contents）时获取此互斥。该互斥可同步对列表内容的访问。当此等待事件以高频发生时，它表示之前访问的表集突然发生变化。引擎需要访问新表或放弃与之前访问的表相关的上下文。 - synch/mutex/sql/LOCK_open
-
会话打开的表数超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息，请参阅 MySQL 如何打开和关闭表
。 - synch/mutex/sql/LOCK_table_cache
-
会话打开的表数量超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息，请参阅 MySQL 如何打开和关闭表
。 - synch/mutex/sql/LOG
-
在该等待事件中，有正等待日志锁定的线程。例如，线程可能等待锁定写入慢速查询日志文件。
- synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit
-
在该等待事件中，有正等待带着提交到二进制日志的意图获取锁定的线程。二进制日志记录争用可能出现在更改率非常高的数据库上。根据您的 MySQL 版本，有特定锁定用于保护二进制日志的一致性和持续性。在 RDS for MySQL 中，二进制日志用于复制和自动备份过程。在 Aurora MySQL 中，本机复制或备份不需要二进制日志。它们默认情况下处于禁用状态，但可以启用或用于外部复制或更改数据捕获。有关更多信息，请参阅 MySQL 文档中的二进制日志
。 - sync/mutex/sql/MYSQL_BIN_LOG::LOCK_dump_thread_metrics_collection
-
如果打开了二进制日志记录，则当引擎将活动转储线程指标打印到引擎错误日志和内部操作映射时，将获得此互斥。
- sync/mutex/sql/MYSQL_BIN_LOG::LOCK_inactive_binlogs_map
-
如果打开了二进制日志记录，引擎在添加、删除或搜索最新二进制日志文件后面的二进制日志文件列表时获取此互斥。
- sync/mutex/sql/MYSQL_BIN_LOG::LOCK_io_cache
-
如果打开二进制日志记录，引擎将在以下 Aurora 二进制日志 IO 缓存操作期间获取此互斥：分配、调整大小、释放、写入、读取、清除和访问缓存信息。如果此事件频繁发生，则引擎在访问存储二进制日志事件的缓存。为了减少等待时间，请减少提交。尝试将多个语句分组到一个事务中。
- synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log
-
您已开启二进制日志记录。可能存在较高的提交吞吐量、很多事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中，使用全局数据库而不是二进制日志复制，或使用
aurora_binlog_*参数。 - synch/mutex/sql/SERVER_THREAD::LOCK_sync
-
互斥锁
SERVER_THREAD::LOCK_sync在调度、处理或启动线程以进行文件写入的过程中获取。此等待事件发生过多表示数据库中的写入活动增加。 - synch/mutex/sql/TABLESPACES:lock
-
引擎在以下表空间操作期间获取
TABLESPACES:lock互斥：创建、删除、截断和扩展。此等待事件发生过多表示表空间操作频率很高。例如，将大量数据加载到数据库中。 - synch/rwlock/innodb/dict
-
在该等待事件中，有正等待 InnoDB 数据字典中保留的 rwlock 的线程。
- synch/rwlock/innodb/dict_operation_lock
-
在该等待事件中，有在 InnoDB 数据字典操作中保留锁定的线程。
- synch/rwlock/innodb/dict sys RW lock
-
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
- synch/rwlock/innodb/hash_table_locks
-
此等待事件发生过多表示修改映射缓冲区缓存的哈希表时存在争用现象。考虑增加缓冲区缓存大小并改进相关查询的访问路径。要了解如何在此等待突出时优化数据库，请参阅 synch/rwlock/innodb/hash_table_locks。
- synch/rwlock/innodb/index_tree_rw_lock
-
大量类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外，将工作负载分散到不同的数据库对象上。例如，实施分区。
- synch/sxlock/innodb/dict_operation_lock
-
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
- synch/sxlock/innodb/dict_sys_lock
-
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
- synch/sxlock/innodb/hash_table_locks
-
会话在缓冲池中找不到页面。引擎要么需要读取文件，要么需要修改缓冲池的最近使用最少 (LRU) 列表。考虑增加缓冲区缓存大小并改进相关查询的访问路径。
- synch/sxlock/innodb/index_tree_rw_lock
-
很多类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外，将工作负载分散到不同的数据库对象上。例如，实施分区。
有关同步等待事件问题排查的更多信息，请参阅为什么我的 MySQL 数据库实例在 Performance Insights 中的 SYNCH 等待事件显示有大量活动会话正在等待？
Aurora MySQL 线程状态
以下是 Aurora MySQL 的一些常见的线程状态。
- 检查权限
-
线程正在检查服务器是否具有运行语句所需的权限。
- 检查查询缓存以进行查询
-
服务器正在检查查询缓存中是否存在当前查询。
- 已清除
-
这是连接的最终状态，其工作已完成但客户端尚未关闭。最好的解决方案是在代码中明确关闭连接。或者您可以在参数组中设置较低的
wait_timeout值。 - 关闭表
-
线程正在将更改后的表数据刷新到磁盘并关闭使用过的表。如果这不是快速操作，请根据实例类网络带宽验证网络带宽消耗指标。另外，请检查
table_open_cache和table_definition_cache参数的参数值是否允许同时打开足够的表，以使引擎不需要频繁地打开和关闭表。这些参数会影响实例的内存消耗。 - 将 HEAP 转换为 MyISAM
-
该查询正在将临时表从内存中的表转换为磁盘上的表。这种转换是必要的，因为 MySQL 在查询处理的中间步骤中创建的临时表对内存来说太大了。检查
tmp_table_size和max_heap_table_size的值。在更高版本中，此线程状态名称为converting HEAP to ondisk。 - 将 HEAT 转换为磁盘上
-
线程正在将内部临时表从内存中的表转换为磁盘上的表。
- 复制到 tmp 表
-
线程正在处理
ALTER TABLE语句。此状态发生在具有新结构的表创建之后，但在将行复制到该表中之前。对于处于此状态的线程，您可以使用性能架构获取有关复制操作进度的信息。 - 创建排序索引
-
Aurora MySQL 正在执行一种排序，因为它不能使用现有的索引来满足查询的
ORDER BY或GROUP BY子句。有关更多信息，请参阅创建排序索引。 - 创建表
-
该线程正在创建一个永久表或临时表。
- 延迟提交确定完成
-
Aurora MySQL 中的异步提交已收到确认并已完成。
- 延迟提交确定启动
-
Aurora MySQL 线程已启动异步提交过程，但正在等待确认。这通常是事务的真正提交时间。
- 延迟发送确定完成
-
在向客户端发送响应时，可以释放绑定到连接的 Aurora MySQL 工作线程。线程可以开始其他工作。状态
delayed send ok意味着对客户端的异步确认已完成。 - 延迟发送确定已启动
-
Aurora MySQL 工作线程已异步向客户端发送响应，现在可以自由地为其他连接工作。事务已启动一个尚未确认的异步提交过程。
- executing
-
线程已经开始运行语句。
- 释放项目
-
线程已运行命令。在此状态下完成的一些项目释放涉及到查询缓存。这种状态之后通常是清理。
- init
-
此状态发生在
ALTER TABLE、DELETE、INSERT、SELECT或者UPDATE语句的初始化之前。处于此状态的操作包括刷新二进制日志或 InnoDB 日志，以及清理查询缓存。 - 主节点已将所有二进制日志发送给从节点
-
主节点已完成其复制的一部分。线程正在等待更多查询运行，以便可以写入二进制日志 (binlog)。
- 打开表
-
线程正在尝试打开一张表。除非
ALTER TABLE或者LOCK TABLE语句需要完成，或者它超出了table_open_cache的值，否则此操作会快速完成。 - 正在优化
-
服务器正在对查询执行初始优化。
- 正在准备
-
在查询优化期间会出现此状态。
- 查询结束
-
此状态发生在处理查询之后但在释放项目状态之前。
- 删除重复项
-
Aurora MySQL 无法在查询的早期阶段优化
DISTINCT操作。Aurora MySQL 必须先删除所有重复的行，然后才能将结果发送给客户端。 - 搜索行以进行更新
-
在更新它们之前，线程会查找所有匹配的行。如果
UPDATE正在更改引擎用来查找行的索引，这个阶段有必要。 - 向从节点发送二进制日志事件
-
线程从二进制日志中读取事件并将其发送到副本。
- 向客户端发送缓存的结果
-
服务器正在从查询缓存中获取查询的结果并将其发送到客户端。
- 发送数据
-
线程正在读取和处理
SELECT语句的行，但尚未开始向客户端发送数据。该过程是确定哪些页面包含满足查询所需的结果。有关更多信息，请参阅发送数据。 - 发送给客户端
-
服务器正在向客户端写入数据包。在早期的 MySQL 版本中，此等待事件被标记为
writing to net。 - starting
-
这是语句执行开始的第一阶段。
- 统计数据
-
服务器正在计算统计数据以制定查询执行计划。如果线程长期处于此状态，则在执行其他工作时，服务器可能会绑定磁盘。
- 将结果存储在查询缓存中
-
服务器正在将查询结果存储在查询缓存中。
- 系统锁定
-
线程已调用
mysql_lock_tables，但是自调用以来，线程状态尚未更新。出现这种普遍状态的原因很多。 - update
-
线程正在准备开始更新表格。
- 更新
-
线程正在搜索行并更新它们。
- 用户锁定
-
该线程发出
GET_LOCK调用。该线程在请求一个咨询锁并在等待该锁，或者计划请求咨询锁。 - 等待更多更新
-
主节点已完成其复制的一部分。线程正在等待更多查询运行，以便可以写入二进制日志 (binlog)。
- 等待架构元数据锁定
-
这是等待元数据锁定。
- 等待存储的函数元数据锁定
-
这是等待元数据锁定。
- 等待存储的过程元数据锁定
-
这是等待元数据锁定。
- 等待表刷新
-
线程正在执行
FLUSH TABLES并且正在等待所有线程关闭他们的表。或者线程收到通知，指示表格的底层结构发生了变化，因此它必须重新打开表格以获得新结构。要重新打开表格，线程必须等到所有其他线程都关闭表格。如果另一个线程使用了表格上的以下语句之一，则会发出此通知：FLUSH TABLES、ALTER TABLE、RENAME TABLE、REPAIR TABLE、ANALYZE TABLE或OPTIMIZE TABLE。 - 等待表级锁定
-
一个会话在表上保持锁定，而另一个会话则试图在同一个表上获取同一个锁定。
- 等待表元数据锁定
-
Aurora MySQL 使用元数据锁定来管理对数据库对象的并发访问并确保数据一致性。在此等待事件中，一个会话在表上保持元数据锁定，而另一个会话则试图在同一个表上获取同一个锁定。启用性能架构后，此线程状态将报告为等待事件
synch/cond/sql/MDL_context::COND_wait_status。 - 写入网络
-
服务器正在向网络写入数据包。在以后的 MySQL 版本中，此等待事件被标记为
Sending to client。
Aurora MySQL 隔离级别
接下来，您可以了解 Aurora MySQL 集群中的数据库实例如何实现隔离的数据库属性。这样做有助于您了解 Aurora MySQL 默认行为如何在严格一致性和高性能之间取得平衡。您还可以根据工作负载的特性决定何时更改默认设置。
写入器实例的可用隔离级别
您可以在 Aurora MySQL 单主集群的主实例上使用隔离级别 REPEATABLE READ、READ COMMITTED、READ
UNCOMMITTED 和 SERIALIZABLE。您可以在 Aurora MySQL 多主集群中的任何数据库实例上使用隔离级别 REPEATABLE READ READ COMMITTED 和 READ UNCOMMITTED。这些隔离级别在 Aurora MySQL 中的工作方式与在 RDS for MySQL 中的工作方式相同。
读取器实例的 REPEATABLE READ 隔离级别
默认情况下，配置为只读 Aurora 副本的 Aurora MySQL 数据库实例始终使用 REPEATABLE
READ 隔离级别。这些数据库实例会忽略任何 SET TRANSACTION ISOLATION LEVEL 语句并继续使用 REPEATABLE READ 隔离级别。
读取器实例的 READ COMMITTED 隔离级别
如果您的应用程序包括主实例上的写入密集型工作负载和 Aurora 副本上的长时间运行的查询，则可能会产生大量的清除滞后。当内部垃圾回收被长时间运行的查询阻止时，就会发生清除滞后。您看到的症状是 history list length 命令输出中的 SHOW ENGINE INNODB STATUS 值很高。可以使用 CloudWatch 中的 RollbackSegmentHistoryListLength 指标监控该值。这种情况会降低二级索引的效率，导致整体查询性能下降和存储空间浪费。
如果遇到此类问题，可以使用 Aurora MySQL 会话级别配置设置 aurora_read_replica_read_committed，在 Aurora 副本上使用 READ COMMITTED 隔离级别。使用此设置有助于减少在修改表的事务同时执行长时间运行的查询所导致的速度下降和空间浪费情况。
建议您在使用此设置之前一定要了解 READ COMMITTED 隔离的特定 Aurora MySQL 行为。Aurora 副本 READ COMMITTED 行为符合 ANSI SQL 标准。但是，隔离没有您可能熟悉的典型 MySQL READ COMMITTED 行为那么严格。因此，Aurora MySQL 只读副本上的 READ
COMMITTED 下的查询结果可能与 Aurora MySQL 主实例或 RDS for MySQL 上的 READ
COMMITTED 下的同一查询的结果不同。您可以将 aurora_read_replica_read_committed 设置用于诸如扫描超大型数据库的综合报告之类的用例。在精度和可重复性很重要的小型结果集的短查询中，您可能会避免使用它。
READ COMMITTED 隔离级别不适用于 Aurora 全局数据库的辅助集群中使用写入转发功能的会话。有关写入转发的信息，请参阅 在 Amazon Aurora Global Database 中使用写入转发。
对读取器启用 READ COMMITTED
要对 Aurora 副本启用 READ COMMITTED 隔离级别，请启用 aurora_read_replica_read_committed 配置设置。在连接特定的 Aurora 副本时，在会话级别启用此设置。为此，请运行以下 SQL 命令。
set session aurora_read_replica_read_committed = ON; set session transaction isolation level read committed;
您可能会暂时启用此配置设置，以执行交互式临时（一次性）查询。您可能还想运行一个从 READ
COMMITTED 隔离级别中受益的报告或数据分析应用程序，而其他应用程序的默认设置保持不变。
启用 aurora_read_replica_read_committed 设置后，使用 SET TRANSACTION
ISOLATION LEVEL 命令为适当的事务指定隔离级别。
set transaction isolation level read committed;
Aurora 副本上的 READ COMMITTED 行为差异
aurora_read_replica_read_committed 设置使 READ COMMITTED 隔离级别可用于 Aurora 副本，并具有针对长时间运行的事务进行优化的一致性行为。Aurora 副本上的 READ COMMITTED 隔离级别没有 Aurora 主实例或多主实例上的隔离那么严格。因此，仅在您知道查询可接受某些类型不一致结果的可能性的 Aurora 副本上启用此设置。
当 aurora_read_replica_read_committed 设置打开时，您的查询可能会遇到某些类型的读取异常。理解并处理应用程序代码中的两种异常特别重要。在查询运行期间提交另一个事务时，将发生不可重复的读取。长时间运行的查询在查询开始时看到的数据可能与在结束时看到的数据不同。当其他事务导致在查询运行期间将对现有行进行重组，并且查询将两次读取一行或多行时，将发生幻读。
您的查询可能会因幻读而导致行数不一致；也可能由于不可重复的读取而返回不完整或不一致的结果。例如，假设联接操作引用由 SQL 语句并发修改的表，如 INSERT 或 DELETE。在这种情况下，联接查询可能从一个表读取一行，但不从另一个表读取对应的行。
ANSI SQL 标准允许 READ COMMITTED 隔离级别存在这两种行为。但是，这些行为与 READ COMMITTED 的典型 MySQL 实现不同。因此，启用 aurora_read_replica_read_committed 设置之前，请先检查任何现有的 SQL 代码，以验证其在更宽松的一致性模型下是否按预期运行。
启用此设置时，READ COMMITTED 隔离级别下的行数和其他结果可能不具有强一致性。因此，通常只在运行聚合大量数据且无需绝对精度的分析查询时才启用该设置。如果没有这些类型的长时间运行的查询以及写入密集型工作负载，则可能不需要 aurora_read_replica_read_committed 设置。如果没有长时间运行的查询和写入密集型工作负载的组合，就不太可能遇到历史记录列表长度的问题。
例 显示 READ COMMITTED 隔离行为的针对 Aurora 副本的查询
以下示例展示了如果事务同时修改关联表，针对 Aurora 副本的 READ COMMITTED 查询如何返回不可重复的结果。表 BIG_TABLE 在任何查询开始之前包含 100 万行。其他数据操作语言 (DML) 语句在运行时会添加、删除或更改行。
READ COMMITTED 隔离级别下针对 Aurora 主实例的查询生成可预测的结果。但是，在每个长时间运行的查询的生命周期内保持一致的读取视图，这样所产生的开销可能会导致以后的垃圾回收成本高昂。
我们优化了 READ COMMITTED 隔离级别下对 Aurora 副本的查询，以最大程度减少这种垃圾回收开销。权衡之下，结果可能有所不同，具体取决于查询是否检索查询运行期间提交的事务所添加、删除或重组的行。允许查询考虑这些行，但不要求这样做。出于演示目的，查询仅使用 COUNT(*) 函数检查表中的行数。
| Time | Aurora 主实例上的 DML 语句 | 针对 Aurora 主实例（具有 READ COMMITTED）的查询 | 针对 Aurora 副本（具有 READ COMMITTED）的查询 |
|---|---|---|---|
| T1 |
INSERT INTO big_table SELECT * FROM other_table LIMIT 1000000; COMMIT;
|
||
| T2 | Q1：SELECT COUNT(*) FROM big_table; |
Q2：SELECT COUNT(*) FROM big_table; |
|
| T3 |
INSERT INTO big_table (c1, c2) VALUES (1, 'one more row'); COMMIT;
|
||
| T4 | 如果 Q1 现在完成，则结果为 1,000,000。 | 如果 Q2 现在完成，则结果为 1,000,000 或 1,000,001。 | |
| T5 |
DELETE FROM big_table LIMIT 2; COMMIT;
|
||
| T6 | 如果 Q1 现在完成，则结果为 1,000,000。 | 如果 Q2 现在完成，则结果为 1,000,000 或 1,000,001 或 999,999 或 999,998。 | |
| T7 |
UPDATE big_table SET c2 = CONCAT(c2,c2,c2); COMMIT;
|
||
| T8 | 如果 Q1 现在完成，则结果为 1,000,000。 | 如果 Q2 现在完成，则结果为 1,000,000 或 1,000,001 或 999,999 或可能某个更大的数字。 | |
| T9 | Q3：SELECT COUNT(*) FROM big_table; |
Q4：SELECT COUNT(*) FROM big_table; |
|
| T10 | 如果 Q3 现在完成，则结果为 999,999。 | 如果 Q4 现在完成，则结果为 999,999。 | |
| T11 | Q5：SELECT COUNT(*) FROM parent_table p JOIN child_table c
ON (p.id = c.id) WHERE p.id = 1000; |
Q6：SELECT COUNT(*) FROM parent_table p JOIN child_table c
ON (p.id = c.id) WHERE p.id = 1000; |
|
| T12 |
INSERT INTO parent_table (id, s) VALUES (1000, 'hello'); INSERT INTO child_table (id, s)
VALUES (1000, 'world'); COMMIT;
|
||
| T13 | 如果 Q5 现在完成，则结果为 0。 | 如果 Q6 现在完成，则结果为 0 或 1。 |
如果查询快速完成，则在任何其他事务执行 DML 语句并提交之前，结果是可预测的，并且主实例与 Aurora 副本之间也是如此。
Q1 的结果高度可预测，因为主实例上的 READ COMMITTED 使用类似于 REPEATABLE READ 隔离级别的强一致性模型。
Q2 的结果可能会因查询运行期间提交的事务而异。例如，假设其他事务执行 DML 语句并在查询运行期间提交。在这种情况下，针对具有 READ COMMITTED 隔离级别的 Aurora 副本的查询可能考虑更改，也可能不考虑更改。不能像在 REPEATABLE READ 隔离级别下那样预测行数。它们也不像针对 READ COMMITTED 隔离级别下的主实例或针对 RDS for MySQL 实例运行的查询那样可预测。
T7 处的 UPDATE 语句实际上并未更改表中的行数。但是，通过更改可变长度列的长度，该语句可能导致在内部对行进行重组。长时间运行的 READ COMMITTED 事务可能会看到某行的旧版本，随后又在同一查询中看到该行的新版本。查询还可以跳过该行的旧版本和新版本。因此，行数可能与预期不同。
Q5 和 Q6 的结果可能相同，也可能略有不同。READ COMMITTED 下针对 Aurora 副本的查询 Q6 可以查看（但不是必须查看）查询运行期间提交的新行。它也可能从一个表中看到该行，但从另一表中看不到该行。如果联接查询在两个表中均未找到匹配的行，则返回的计数为零。如果查询的确在 PARENT_TABLE 和 CHILD_TABLE 中找到了新行，则该查询返回的计数为一。在长时间运行的查询中，从联接的表进行查找的时间可能相隔很远。
这些行为上的差异取决于事务何时提交以及查询何时处理底层表行。因此，在耗时数分钟或数小时的报告查询以及同时在处理 OLTP 事务的 Aurora 集群上运行的报表查询中，您最有可能看到这样的差异。这些类型的混合工作负载从 Aurora 副本上的 READ
COMMITTED 隔离级别获益最大。
Aurora MySQL 提示
您可以将 SQL 提示与 Aurora MySQL 查询结合使用来微调性能。您还可以使用提示来防止重要查询的执行计划根据不可预知的条件进行更改。
要验证提示对查询的影响，请查看 EXPLAIN 语句生成的查询计划。比较包含和不包含提示的查询计划。
在 Aurora MySQL 版本 3 中，您可以使用社群 MySQL 8.0 中提供的所有提示。有关这些提示的详细信息，请参阅 MySQL 参考手册中的优化程序提示
以下提示在 Aurora MySQL 2.08 及更高版本中可用。这些提示适用于使用 Aurora MySQL 版本 2 中的哈希联接功能的查询，尤其是使用并行查询优化的查询。
- HASH_JOIN、NO_HASH_JOIN
-
开启或关闭优化程序的功能来选择是否对查询使用哈希联接优化方法。
HASH_JOIN允许优化程序使用哈希联接（如果该机制更高效）。NO_HASH_JOIN阻止优化程序对查询使用哈希联接。此提示在 Aurora MySQL 2.08 及更高的次要版本中可用。它在 Aurora MySQL 版本 3 中没有效果。以下示例显示如何使用此提示。
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; - HASH_JOIN_PROBING、NO_HASH_JOIN_PROBING
-
在哈希联接查询中，指定是否将指定的表用于联接的探查端。查询测试构建表中的列值是否存在于探查表中，而不是读取探查表的全部内容。您可以使用
HASH_JOIN_PROBING和HASH_JOIN_BUILDING指定如何处理哈希联接查询，而无需重新排序查询文本中的表。此提示在 Aurora MySQL 2.08 及更高的次要版本中可用。它在 Aurora MySQL 版本 3 中没有效果。以下示例显示如何使用此提示。为表
HASH_JOIN_PROBING指定T2提示与为表NO_HASH_JOIN_PROBING指定T1具有相同的效果。EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; - HASH_JOIN_BUILDING、NO_HASH_JOIN_BUILDING
-
在哈希联接查询中，指定是否将指定的表用于联接的构建端。查询处理此表中的所有行来构建列值列表，以便与其他表进行交叉引用。您可以使用
HASH_JOIN_PROBING和HASH_JOIN_BUILDING指定如何处理哈希联接查询，而无需重新排序查询文本中的表。此提示在 Aurora MySQL 2.08 及更高的次要版本中可用。它在 Aurora MySQL 版本 3 中没有效果。以下示例显示如何使用此提示。为表
HASH_JOIN_BUILDING指定T2提示与为表NO_HASH_JOIN_BUILDING指定T1具有相同的效果。EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; - JOIN_FIXED_ORDER
-
指定查询中的表按它们在查询中的列出顺序进行联接。对于涉及三个或更多表的查询，它特别有用。它旨在替代 MySQL
STRAIGHT_JOIN提示。等效于 MySQL JOIN_FIXED_ORDER提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。 以下示例显示如何使用此提示。
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); - JOIN_ORDER
-
指定查询中表的联接顺序。对于涉及三个或更多表的查询，它特别有用。等效于 MySQL JOIN_ORDER
提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。 以下示例显示如何使用此提示。
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); - JOIN_PREFIX
-
指定联接顺序中首先放置的表。对于涉及三个或更多表的查询，它特别有用。等效于 MySQL JOIN_PREFIX
提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。 以下示例显示如何使用此提示。
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id); - JOIN_SUFFIX
-
指定联接顺序中最后放置的表。对于涉及三个或更多表的查询，它特别有用。等效于 MySQL JOIN_SUFFIX
提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。 以下示例显示如何使用此提示。
EXPLAIN SELECT /*+ JOIN_ORDER (t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
有关使用哈希联接查询的信息，请参阅使用哈希联接优化大型 Aurora MySQL 联接查询。
Aurora MySQL 存储过程
您可以在连接到 Aurora MySQL 集群中的主实例时，调用以下存储过程。这些过程控制事务如何从外部数据库复制到 Aurora MySQL，或从 Aurora MySQL 复制到外部数据库。要了解如何根据 Aurora MySQL 中的全局事务标识符 (GTID) 使用复制，请参阅 将基于 GTID 的复制用于 Amazon Aurora MySQL。
主题
- mysql.rds_assign_gtids_to_anonymous_transactions（Aurora MySQL 版本 3 及更高版本）
- mysql.rds_set_master_auto_position（Aurora MySQL 版本 1 和 2）
- mysql.rds_set_source_auto_position（Aurora MySQL 版本 3 及更高版本）
- mysql.rds_set_external_master_with_auto_position（Aurora MySQL 版本 1 和 2）
- mysql.rds_set_external_source_with_auto_position（Aurora MySQL 版本 3 及更高版本）
- mysql.rds_skip_transaction_with_gtid
mysql.rds_assign_gtids_to_anonymous_transactions（Aurora MySQL 版本 3 及更高版本）
语法
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
参数
- gtid_option
-
字符串值。允许的值为
OFF、LOCAL或者指定的 UUID。
使用说明
此过程与在社群 MySQL 中发布语句 CHANGE REPLICATION SOURCE TO
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = 的效果相同。gtid_option
GTID 必须转向 ON 才能使 gtid_option 设置为 LOCAL 或指定的 UUID。
原定设置值为 OFF，这意味着没有使用该功能。
LOCAL 会分配一个 GTID，其中包括副本自己的 UUID（server_uuid 设置)。
传递一个作为 UUID 的参数会分配一个包含指定 UUID 的 GTID，例如复制源服务器的 server_uuid 设置。
示例
要关闭此功能：
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF'); +-------------------------------------------------------------+ | Message | +-------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF | +-------------------------------------------------------------+ 1 row in set (0.07 sec)
要使用副本自己的 UUID：
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL'); +---------------------------------------------------------------+ | Message | +---------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL | +---------------------------------------------------------------+ 1 row in set (0.07 sec)
要使用指定的 UUID：
mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e'); +----------------------------------------------------------------------------------------------+ | Message | +----------------------------------------------------------------------------------------------+ | ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e | +----------------------------------------------------------------------------------------------+ 1 row in set (0.07 sec)
mysql.rds_set_master_auto_position（Aurora MySQL 版本 1 和 2）
将复制模式设置为基于二进制日志文件位置或全局事务标识符 (GTID)。
语法
CALL mysql.rds_set_master_auto_position (auto_position_mode);
参数
- auto_position_mode
-
该值指示是使用日志文件位置复制还是基于 GTID 的复制：
-
0– 使用基于二进制日志文件位置的复制方法。默认为0。 -
1– 使用基于 GTID 的复制方法。
-
使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
主用户必须运行 mysql.rds_set_master_auto_position 过程。
对于 Aurora，Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。
mysql.rds_set_source_auto_position（Aurora MySQL 版本 3 及更高版本）
将复制模式设置为基于二进制日志文件位置或全局事务标识符 (GTID)。
语法
CALL mysql.rds_set_source_auto_position (auto_position_mode);
参数
- auto_position_mode
-
该值指示是使用日志文件位置复制还是基于 GTID 的复制：
-
0– 使用基于二进制日志文件位置的复制方法。默认为0。 -
1– 使用基于 GTID 的复制方法。
-
使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
管理用户必须运行 mysql.rds_set_source_auto_position 过程。
mysql.rds_set_external_master_with_auto_position（Aurora MySQL 版本 1 和 2）
将 Aurora MySQL 主实例配置为接受来自外部 MySQL 实例的传入复制。此过程还会根据全局事务标识符 (GTID) 配置复制。
此过程对 RDS for MySQL 和 Aurora MySQL 均可用。它在不同上下文中的作用可能不同。在用于 Aurora MySQL 时，此过程不会配置延迟复制。此限制是由于 RDS for MySQL 支持延迟复制，但 Aurora MySQL 不支持。
语法
CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption );
参数
- host_name
-
在 Aurora 之外运行以变为复制主实例的 MySQL 实例的主机名或 IP 地址。
- host_port
-
在 Aurora 之外运行的要配置为复制主实例的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
- replication_user_name
-
在对 Aurora 外部运行的 MySQL 实例上具有
REPLICATION CLIENT和REPLICATION SLAVE权限的用户的 ID。建议您向专用于复制的账户提供外部实例。 - replication_user_password
-
在
replication_user_name中指定的用户 ID 的密码。 - ssl_encryption
-
目前未实施该选项。默认值为 0。
使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
主用户必须运行 mysql.rds_set_external_master_with_auto_position 过程。主用户在充当复制目标的 Aurora MySQL 数据库集群的主实例上运行此过程。这可能是外部 MySQL 数据库实例或 Aurora MySQL 数据库集群的复制目标。
对于 Aurora，Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。对于 Aurora MySQL 版本 3，请改为使用程序 mysql.rds_set_external_source_with_auto_position。
在运行 mysql.rds_set_external_master_with_auto_position 前，请将外部 MySQL 数据库实例配置为复制主实例。要连接到外部 MySQL 实例，应指定 replication_user_name 和 replication_user_password 值。这些值必须指示具有外部 MySQL 实例上的 REPLICATION CLIENT 和 REPLICATION SLAVE 权限的复制用户。
将外部 MySQL 实例配置为复制主实例
-
通过使用所选的 MySQL 客户端，连接到外部 MySQL 实例并创建要用于复制的用户账户。以下是示例。
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' -
在外部 MySQL 实例上，向复制用户授予
REPLICATION CLIENT和REPLICATION SLAVE权限。以下示例为您的域的REPLICATION CLIENT用户授予所有数据库的REPLICATION SLAVE和'repl_user'权限。GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
在调用 mysql.rds_set_external_master_with_auto_position 时，Amazon RDS 将记录某些信息。这些信息包括 "set master" 和 mysql.rds_history 表中的时间、用户和 mysql.rds_replication_status 操作。
要跳过已知会导致问题的基于 GTID 的特定事务，您可以使用 mysql.rds_skip_transaction_with_gtid 存储过程。有关使用基于 GTID 的复制的更多信息，请参阅将基于 GTID 的复制用于 Amazon Aurora MySQL。
示例
在 Aurora 主实例上运行时，以下示例将 Aurora 集群配置为充当在 Aurora 之外运行的某个 MySQL 实例的只读副本。
call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd');
mysql.rds_set_external_source_with_auto_position（Aurora MySQL 版本 3 及更高版本）
将 Aurora MySQL 主实例配置为接受来自外部 MySQL 实例的传入复制。此过程还会根据全局事务标识符 (GTID) 配置复制。
此过程对 RDS for MySQL 和 Aurora MySQL 均可用。它在不同上下文中的作用可能不同。在用于 Aurora MySQL 时，此过程不会配置延迟复制。此限制是由于 RDS for MySQL 支持延迟复制，但 Aurora MySQL 不支持。
语法
CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption );
参数
- host_name
-
在 Aurora 之外运行以变为复制源的 MySQL 实例的主机名或 IP 地址。
- host_port
-
在 Aurora 之外运行的要配置为复制源的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
- replication_user_name
-
在对 Aurora 外部运行的 MySQL 实例上具有
REPLICATION CLIENT和REPLICATION SLAVE权限的用户的 ID。建议您向专用于复制的账户提供外部实例。 - replication_user_password
-
在
replication_user_name中指定的用户 ID 的密码。 - ssl_encryption
-
目前未实施该选项。默认值为 0。
使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
管理用户必须运行 mysql.rds_set_external_source_with_auto_position 过程。管理用户在充当复制目标的 Aurora MySQL 数据库集群的主实例上运行此过程。这可能是外部 MySQL 数据库实例或 Aurora MySQL 数据库集群的复制目标。
对于 Aurora，Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 版本 3 也支持它。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。
在运行 mysql.rds_set_external_source_with_auto_position 前，请将外部 MySQL 数据库实例配置为复制源。要连接到外部 MySQL 实例，应指定 replication_user_name 和 replication_user_password 值。这些值必须指示具有外部 MySQL 实例上的 REPLICATION CLIENT 和 REPLICATION SLAVE 权限的复制用户。
要将外部 MySQL 实例配置为复制源
-
通过使用所选的 MySQL 客户端，连接到外部 MySQL 实例并创建要用于复制的用户账户。以下是示例。
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' -
在外部 MySQL 实例上，向复制用户授予
REPLICATION CLIENT和REPLICATION SLAVE权限。以下示例为您的域的REPLICATION CLIENT用户授予所有数据库的REPLICATION SLAVE和'repl_user'权限。GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
在调用 mysql.rds_set_external_source_with_auto_position 时，Amazon RDS 将记录某些信息。这些信息包括 "set master" 和 mysql.rds_history 表中的时间、用户和 mysql.rds_replication_status 操作。
要跳过已知会导致问题的基于 GTID 的特定事务，您可以使用 mysql.rds_skip_transaction_with_gtid 存储过程。有关使用基于 GTID 的复制的更多信息，请参阅将基于 GTID 的复制用于 Amazon Aurora MySQL。
示例
在 Aurora 主实例上运行时，以下示例将 Aurora 集群配置为充当在 Aurora 之外运行的某个 MySQL 实例的只读副本。
call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd');
mysql.rds_skip_transaction_with_gtid
在 Aurora 主实例上跳过复制具有指定全局事务标识符 (GTID) 的事务。
在已知特定 GTID 事务导致问题时，您可以使用该过程进行灾难恢复。请使用该存储过程跳过有问题的事务。有问题的事务示例包括禁用复制、删除重要数据或导致数据库实例变得不可用的事务。
语法
CALL mysql.rds_skip_transaction_with_gtid (gtid_to_skip);
参数
- gtid_to_skip
-
要跳过的复制事务的 GTID。
使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
主用户必须运行 mysql.rds_skip_transaction_with_gtid 过程。
对于 Aurora，Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 版本 3 也支持它。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。
Aurora MySQL 特定的 information_schema 表
Aurora MySQL 有一些特定于 Aurora 的 information_schema 表。
information_schema.replica_host_status
information_schema.replica_host_status 表包含复制信息。您可以使用的列如下表所示。其余列仅供 Aurora 内部使用。
| 列 | 数据类型 | 描述 |
|---|---|---|
| CPU | double | 副本主机的 CPU 使用百分比。 |
| IS_CURRENT | tinyint | 副本是否为最新副本。 |
| LAST_UPDATE_TIMESTAMP | datetime(6) | 上次更新发生的时间。用于确定记录是否过时。 |
| REPLICA_LAG_IN_MILLISECONDS | double | 副本滞后，以毫秒为单位。 |
| SERVER_ID | varchar(100) | 数据库服务器的 ID。 |
| SESSION_ID | varchar(100) | 数据库会话的 ID。用于确定数据库实例是写入器实例还是读取器实例。 |
当副本实例滞后时，从其 information_schema.replica_host_status 表中查询到的信息可能已过时。在这种情况下，我们建议您改为从写入器实例进行查询。
虽然 mysql.ro_replica_status 表具有相似的信息，但我们不建议使用它。