# Amazon Aurora MySQL 参考
此参考包括有关 Aurora MySQL 参数、状态变量和常规 SQL 扩展或与社区 MySQL 数据库引擎的差异的信息。
**Topics**
+ [Aurora MySQL 配置参数](AuroraMySQL.Reference.ParameterGroups.md)
+ [Aurora MySQL 全局状态变量](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Aurora MySQL 等待事件](AuroraMySQL.Reference.Waitevents.md)
+ [Aurora MySQL 线程状态](AuroraMySQL.Reference.thread-states.md)
+ [Aurora MySQL 隔离级别](AuroraMySQL.Reference.IsolationLevels.md)
+ [Aurora MySQL 提示](AuroraMySQL.Reference.Hints.md)
+ [Aurora MySQL 存储过程参考](AuroraMySQL.Reference.StoredProcs.md)
+ [Aurora MySQL 特定的 information\$1schema 表](AuroraMySQL.Reference.ISTables.md)
# Aurora MySQL 配置参数
您可以使用数据库参数组中的参数按照与管理其他 Amazon RDS MySQL 数据库实例相同的方法管理 Amazon Aurora 数据库集群。Amazon Aurora 不同于其他数据库引擎，因为您具有一个包含多个数据库实例的数据库集群。因此，您用于管理 Aurora MySQL 数据库集群的有些参数将应用于整个集群。其他参数则仅应用于数据库集群中的特定数据库实例。
要管理集群级参数，请使用数据库集群参数组。要管理实例级参数，请使用数据库参数组。Aurora MySQL 数据库集群中的每个数据库实例均与 MySQL 数据库引擎兼容。不过，您在集群级别应用某些 MySQL 数据库引擎参数，并使用数据库集群参数组管理这些参数。您无法在 Aurora 数据库集群中实例的数据库参数组中查找集群级参数。本主题后面提供了集群级参数的列表。
您可以使用AWS 管理控制台、AWS CLI 或 Amazon RDS API 管理集群级参数和实例级参数。您可以使用单独的命令管理集群级参数和实例级参数。例如，您可以使用 [modify-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) CLI 命令来管理数据库集群参数组中的集群级参数。您可以使用 [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) CLI 命令来为数据库集群中的数据库实例管理数据库参数组中的实例级参数。
您可以在控制台中或者使用 CLI 或 RDS API 查看集群级别和实例级别的参数。例如，您可以使用 [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) AWS CLI 命令来查看数据库集群参数组中的集群级参数。您可以使用 [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) CLI 命令来查看数据库集群中数据库实例的数据库参数组中的实例级参数。
**注意**
每个[默认参数组](USER_WorkingWithParamGroups.md)包含参数组中所有参数的默认值。如果该参数具有此值的“引擎默认值”，请参阅特定版本的 MySQL 或 PostgreSQL 文档获取实际默认值。
除非另有说明，否则下表中列出的参数对于 Aurora MySQL 版本 2 和 3 有效。
有关数据库参数组的更多信息，请参阅 [Amazon Aurora 的参数组](USER_WorkingWithParamGroups.md)。有关 Aurora Serverless v1 集群的规则和限制，请参阅[Aurora Serverless v1 的参数组](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups)。
**Topics**
+ [集群级别的参数](#AuroraMySQL.Reference.Parameters.Cluster)
+ [实例级参数](#AuroraMySQL.Reference.Parameters.Instance)
+ [不适用于 Aurora MySQL 的 MySQL 参数](#AuroraMySQL.Reference.Parameters.Inapplicable)
## 集群级别的参数
下表显示了适用于整个 Aurora MySQL 数据库集群的所有参数。
| 参数名称 | 可修改 | 备注 |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | 是 | 仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。已从 Aurora MySQL 版本 3 中删除。 |
| `aurora_binlog_replication_max_yield_seconds` | 是 | 仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。 |
| `aurora_binlog_replication_sec_index_parallel_workers` | 是 | 设置在为具有多个二级索引的大型表复制事务时可用于应用二级索引更改的并行线程总数。默认情况下，此参数设置为 `0`（禁用）。 此参数可用于 Aurora MySQL 版本 3.06 及更高版本。有关更多信息，请参阅 [优化 Aurora MySQL 的二进制日志复制](binlog-optimization.md)。 |
| `aurora_binlog_use_large_read_buffer` | 是 | 仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。已从 Aurora MySQL 版本 3 中删除。 |
| `aurora_disable_hash_join` | 是 | 将此参数设置为 `ON` 可在 Aurora MySQL 版本 2.09 或更高版本中关闭哈希联接优化。版本 3 不支持此参数。有关更多信息，请参阅 [Amazon Aurora MySQL 的并行查询](aurora-mysql-parallel-query.md)。 |
| `aurora_enable_replica_log_compression` | 是 | 有关更多信息，请参阅“[Amazon Aurora MySQL 复制的性能注意事项](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance)”。不适用于作为 Aurora 全局数据库的一部分的集群。已从 Aurora MySQL 版本 3 中删除。 |
| `aurora_enable_repl_bin_log_filtering` | 是 | 有关更多信息，请参阅“[Amazon Aurora MySQL 复制的性能注意事项](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance)”。不适用于作为 Aurora 全局数据库的一部分的集群。已从 Aurora MySQL 版本 3 中删除。 |
| `aurora_enable_staggered_replica_restart` | 是 | 此设置在 Aurora MySQL 版本 3 中可用，但并未使用。 |
| `aurora_enable_zdr` | 是 | 该设置在 Aurora MySQL 2.10 及更高版本中默认开启。有关更多信息，请参阅“[Amazon Aurora MySQL 的零停机重启 (ZDR)](AuroraMySQL.Replication.Availability.md)”。 |
| `aurora_enhanced_binlog` | 是 | 将此参数的值设置为 1，以在 Aurora MySQL 版本 3.03.1 及更高版本中开启增强型二进制日志。有关更多信息，请参阅 [为 Aurora MySQL 设置增强型二进制日志](AuroraMySQL.Enhanced.binlog.md)。 |
| `aurora_jemalloc_background_thread` | 是 | 使用此参数以使后台线程能够执行内存维护操作。允许的值为 `0`（禁用）和 `1`（启用）。默认值为 `0`。 此参数适用于 Aurora MySQL 版本 3.05 及更高版本。 |
| `aurora_jemalloc_dirty_decay_ms` | 是 | 使用此参数以将释放的内存保留一段时间（以毫秒为单位）。保留内存可以更快地重用。允许的值为 `0`–`18446744073709551615`。默认值（`0`）将所有内存作为可释放内存返回给操作系统。 此参数适用于 Aurora MySQL 版本 3.05 及更高版本。 |
| `aurora_jemalloc_tcache_enabled` | 是 | 使用此参数，通过绕过内存领域，在线程本地缓存中处理小内存请求（最多 32KiB）。允许的值为 `0`（禁用）和 `1`（启用）。默认值为 `1`。 此参数适用于 Aurora MySQL 版本 3.05 及更高版本。 |
| `aurora_load_from_s3_role` | 是 | 有关更多信息，请参阅 [将数据从 Amazon S3 存储桶中的文本文件加载到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Integrating.LoadFromS3.md)。目前在 Aurora MySQL 版本 3 中不可用。使用 `aws_default_s3_role`。 |
| `aurora_mask_password_hashes_type` | 是 | 原定设置情况下，该设置在 Aurora MySQL 2.11 及更高版本中开启。 使用此设置可在慢速查询和审核日志中屏蔽 Aurora MySQL 密码哈希。允许的值为 `0` 和 `1`（原定设置）。设置为 `1` 时，密码将记录为 ``。设置为 `0` 时，密码将记录为哈希（`#`）值。 |
| `aurora_select_into_s3_role` | 是 | 有关更多信息，请参阅 [将数据从 Amazon Aurora MySQL 数据库集群保存到 Amazon S3 存储桶中的文本文件](AuroraMySQL.Integrating.SaveIntoS3.md)。目前在 Aurora MySQL 版本 3 中不可用。使用 `aws_default_s3_role`。 |
| `authentication_kerberos_caseins_cmp` | 是 | 控制 `authentication_kerberos` 插件不区分大小写的用户名比较。将它设置为 `true` 以进行不区分大小写的比较。原定设置情况下，使用区分大小写的比较（`false`）。有关更多信息，请参阅 [对 Aurora MySQL 使用 Kerberos 身份验证](aurora-mysql-kerberos.md)。 此参数适用于 Aurora MySQL 版本 3.03 及更高版本。 |
| `auto_increment_increment` | 是 | |
| `auto_increment_offset` | 是 | |
| `aws_default_lambda_role` | 是 | 有关更多信息，请参阅“[从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数](AuroraMySQL.Integrating.Lambda.md)”。 |
| `aws_default_s3_role` | 是 | 从数据库集群调用 `LOAD DATA FROM S3`、`LOAD XML FROM S3` 或 `SELECT INTO OUTFILE S3` 语句时使用。 在 Aurora MySQL 版本 2 中，如果没有为相应语句的 `aurora_load_from_s3_role` 或 `aurora_select_into_s3_role` 指定 IAM 角色，则使用在该参数中指定的 IAM 角色。 在 Aurora MySQL 版本 3 中，始终使用为该参数指定的 IAM 角色。 有关更多信息，请参阅 [将 IAM 角色与 Amazon Aurora MySQL 数据库集群关联](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md)。 |
| `binlog_backup` | 是 | 将此参数的值设置为 0，以在 Aurora MySQL 版本 3.03.1 及更高版本中开启增强型二进制日志。您只能在使用增强型二进制日志时关闭此参数。有关更多信息，请参阅 [为 Aurora MySQL 设置增强型二进制日志](AuroraMySQL.Enhanced.binlog.md)。 |
| `binlog_checksum` | 是 | 如果未设置此参数，AWS CLI 和 RDS API 将报告 `None` 的值。在这种情况下，Aurora MySQL 会使用引擎默认值，即 `CRC32`。这与关闭校验和的显式设置 `NONE` 不同。 |
| `binlog-do-db` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_format` | 是 | 有关更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。 |
| `binlog_group_commit_sync_delay` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_group_commit_sync_no_delay_count` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog-ignore-db` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_replication_globaldb` | 是 | 将此参数的值设置为 0，以在 Aurora MySQL 版本 3.03.1 及更高版本中开启增强型二进制日志。您只能在使用增强型二进制日志时关闭此参数。有关更多信息，请参阅 [为 Aurora MySQL 设置增强型二进制日志](AuroraMySQL.Enhanced.binlog.md)。 |
| `binlog_row_image` | 否 | |
| `binlog_row_metadata` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_row_value_options` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_rows_query_log_events` | 是 | |
| `binlog_transaction_compression` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_transaction_compression_level_zstd` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_transaction_dependency_history_size` | 是 | 此参数设置了保留在内存中的行哈希数的上限，这些哈希值用于查找上次修改给定行的事务。达到这个哈希数后，历史记录将被清除。 此参数适用于 Aurora MySQL 版本 2.12 及更高版本以及版本 3。 |
| `binlog_transaction_dependency_tracking` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `character-set-client-handshake` | 是 | |
| `character_set_client` | 是 | |
| `character_set_connection` | 是 | |
| `character_set_database` | 是 | |
| `character_set_filesystem` | 是 | |
| `character_set_results` | 是 | |
| `character_set_server` | 是 | |
| `collation_connection` | 是 | |
| `collation_server` | 是 | |
| `completion_type` | 是 | |
| `default_storage_engine` | 否 | Aurora MySQL 集群对所有数据使用 InnoDB 存储引擎。 |
| `enforce_gtid_consistency` | 有时 | 在 Aurora MySQL 版本 2 及更高版本中可修改。 |
| `event_scheduler` | 是 | 指示事件计划程序的状态。 在 Aurora MySQL 版本 3 中，只能在集群级别修改。 |
| `gtid-mode` | 有时 | 在 Aurora MySQL 版本 2 及更高版本中可修改。 |
| `information_schema_stats_expiry` | 是 | MySQL 数据库服务器从存储引擎获取数据并替换缓存中的数据前的秒数。允许的值为 `0`–`31536000`。 此参数适用于 Aurora MySQL 版本 3。 |
| `init_connect` | 是 | 服务器要对连接的每个客户端运行的命令。在设置中使用双引号（"）以避免连接失败，例如： SET optimizer_switch="hash_join=off"
在 Aurora MySQL 版本 3 中，此参数不适用于具有 `CONNECTION_ADMIN` 权限的用户。这包括 Aurora 主用户。有关更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。 |
| `innodb_adaptive_hash_index` | 是 | 在 Aurora MySQL 版本 2 和 3 中，您可以在数据库集群级别修改此参数。 读取器数据库实例不支持自适应哈希索引。 |
| `innodb_aurora_instant_alter_column_allowed` | 是 | 控制 `INSTANT` 算法是否可用于全局级别的 `ALTER COLUMN` 操作。允许的值如下所示： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 有关更多信息，请参阅 MySQL 文档中的[列操作](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations)。 此参数适用于 Aurora MySQL 版本 3.05 及更高版本。 |
| `innodb_autoinc_lock_mode` | 是 | |
| `innodb_checksums` | 不支持 | 已从 Aurora MySQL 版本 3 中删除。 |
| `innodb_cmp_per_index_enabled` | 是 | |
| `innodb_commit_concurrency` | 是 | |
| `innodb_data_home_dir` | 不支持 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `innodb_deadlock_detect` | 是 | 此选项用于在 Aurora MySQL 版本 2.11 及更高版本以及版本 3 中禁用死锁检测。 在高并发系统中，当许多线程等待同一个锁时，死锁检测可能会导致速度下降。有关此参数的更多信息，请参阅 MySQL 文档。 |
| `innodb_default_row_format` | 是 | 此参数定义 InnoDB 表（包括用户创建的 InnoDB 临时表）的原定设置行格式。它适用于 Aurora MySQL 版本 2 和 3。 其值可以是 `DYNAMIC`、`COMPACT` 或 `REDUNDANT.`。 |
| `innodb_file_per_table` | 是 | 此参数影响表存储的组织方式。有关更多信息，请参阅 [存储扩展](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling)。 |
| `innodb_flush_log_at_trx_commit` | 是 | 我们强烈建议您使用默认值 `1`。 在 Aurora MySQL 版本 3 中，在将此参数设置为 `1` 以外的值之前，必须先将 `innodb_trx_commit_allow_data_loss` 的值设置为 `1`。 有关更多信息，请参阅 [配置刷新日志缓冲区的频率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。 |
| `innodb_ft_max_token_size` | 是 | |
| `innodb_ft_min_token_size` | 是 | |
| `innodb_ft_num_word_optimize` | 是 | |
| `innodb_ft_sort_pll_degree` | 是 | |
| `innodb_online_alter_log_max_size` | 是 | |
| `innodb_optimize_fulltext_only` | 是 | |
| `innodb_page_size` | 否 | |
| `innodb_print_all_deadlocks` | 是 | 开启后，在 Aurora MySQL 错误日志中记录有关所有 InnoDB 死锁的信息。有关更多信息，请参阅 [最大限度地减少 Aurora MySQL 死锁以及排查相关问题](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks)。 |
| `innodb_purge_batch_size` | 是 | |
| `innodb_purge_threads` | 是 | |
| `innodb_rollback_on_timeout` | 是 | |
| `innodb_rollback_segments` | 是 | |
| `innodb_spin_wait_delay` | 是 | |
| `innodb_strict_mode` | 是 | |
| `innodb_support_xa` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `innodb_sync_array_size` | 是 | |
| `innodb_sync_spin_loops` | 是 | |
| `innodb_stats_include_delete_marked` | 是 | 启用此参数后，InnoDB 在计算持久优化器统计数据时会包括带有删除标记的记录。 此参数适用于 Aurora MySQL 版本 2.12 及更高版本以及版本 3。 |
| `innodb_table_locks` | 是 | |
| `innodb_trx_commit_allow_data_loss` | 是 | 在 Aurora MySQL 版本 3 中，将此参数的值设置为 `1`，这样您就可以更改 `innodb_flush_log_at_trx_commit` 的值。 `innodb_trx_commit_allow_data_loss` 的默认值为 `0`。 有关更多信息，请参阅 [配置刷新日志缓冲区的频率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。 |
| `innodb_undo_directory` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `internal_tmp_disk_storage_engine` | 是 | 控制哪个内存存储引擎用于内部临时表。允许的值包括 `INNODB`和 `MYISAM`。 此参数适用于 Aurora MySQL 版本 2。 |
| `internal_tmp_mem_storage_engine` | 是 | 控制哪个内存存储引擎用于内部临时表。允许的值包括 `MEMORY`和 `TempTable`。 此参数适用于 Aurora MySQL 版本 3。 |
| `key_buffer_size` | 是 | MyISAM 表的密钥缓存。有关更多信息，请参阅[密钥缓存 -> cache\$1lock 互斥锁](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)。 |
| `lc_time_names` | 是 | |
| `log_error_suppression_list` | 是 | 指定未在 MySQL 错误日志中记录的错误代码列表。这允许您忽略某些非关键错误条件，以帮助保持错误日志干净整洁。有关更多信息，请参阅 MySQL 文档中的 [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)。 此参数适用于 Aurora MySQL 3.03 及更高版本。 |
| `low_priority_updates` | 是 | `INSERT`、`UPDATE`、`DELETE` 和 `LOCK TABLE WRITE` 操作会等待，直至没有待处理的 `SELECT` 操作。此参数仅影响仅使用表级锁定的存储引擎（MyISAM、MEMORY、MERGE）。 此参数适用于 Aurora MySQL 版本 3。 |
| `lower_case_table_names` | 是（Aurora MySQL 版本 2） 仅在集群创建时（Aurora MySQL 版本 3） | 在 Aurora MySQL 版本 2.10 及更高的 2.x 版本中，请确保在更改此设置并重启写入器实例后重启所有读取器实例。有关详细信息，请参阅[在具有读取可用性的情况下重启 Aurora 集群](aurora-mysql-survivable-replicas.md)。 在 Aurora MySQL 版本 3 中，此参数的值在创建集群时永久设置。如果对此选项使用非默认值，请在升级之前设置 Aurora MySQL 版本 3 自定义参数组，然后在创建版本 3 集群的快照还原操作期间指定参数组。 使用基于 Aurora MySQL 的 Aurora 全局数据库时，如果开启了 `lower_case_table_names` 参数，则无法执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。有关可以使用的方法的更多信息，请参阅[主要版本升级。](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)。 |
| `master-info-repository` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `master_verify_checksum` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `source_verify_checksum`。 |
| `max_delayed_threads` | 是 | 设置处理 `INSERT DELAYED` 语句的最大线程数。 此参数适用于 Aurora MySQL 版本 3。 |
| `max_error_count` | 是 | 存储以供显示的错误、警告和备注消息的最大数量。 此参数适用于 Aurora MySQL 版本 3。 |
| `max_execution_time` | 是 | 运行 `SELECT` 语句的超时时间，以毫秒为单位。值可以为 `0` – `18446744073709551615`。设置为 `0` 时，没有超时。 有关更多信息，请参阅 MySQL 文档中的 [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)。 |
| `min_examined_row_limit` | 是 | 使用此参数可防止记录所检查的行数少于指定行数的查询。 此参数适用于 Aurora MySQL 版本 3。 |
| `partial_revokes` | 否 | 此参数适用于 Aurora MySQL 版本 3。 |
| `preload_buffer_size` | 是 | 预加载索引时分配的缓冲区的大小。 此参数适用于 Aurora MySQL 版本 3。 |
| `query_cache_type` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `read_only` | 是 | 启用此参数时，除副本线程执行的更新外，服务器不允许任何更新。 对于 Aurora MySQL 版本 2，有效值如下所示： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 对于 Aurora MySQL 版本 3，有效值如下所示： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 在 Aurora MySQL 版本 3 中，此参数不适用于具有 `CONNECTION_ADMIN` 权限的用户。这包括 Aurora 主用户。有关更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。 |
| `relay-log-space-limit` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replica_parallel_type` | 是 | 此参数对已处于准备阶段的所有未提交线程的副本启用并行执行，而不会违反一致性。它适用于 Aurora MySQL 版本 3。 在 Aurora MySQL 版本 3.03.\$1 及更低版本中，默认值为 DATABASE。在 Aurora MySQL 版本 3.04 及更高版本中，默认值为 LOGICAL\$1CLOCK。 |
| `replica_preserve_commit_order` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replica_transaction_retries` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replica_type_conversions` | 是 | 此参数决定了副本上使用的类型转换。允许的值为：`ALL_LOSSY`、`ALL_NON_LOSSY`、`ALL_SIGNED` 和 `ALL_UNSIGNED`。有关更多信息，请参阅 MySQL 文档中的[在源和副本上使用不同的表定义进行复制](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html)。 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-do-db` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-do-table` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-ignore-db` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-ignore-table` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-wild-do-table` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `replicate-wild-ignore-table` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `require_secure_transport` | 是 | 此参数适用于 Aurora MySQL 版本 2 和 3。有关更多信息，请参阅 [与 Aurora MySQL 数据库集群的 TLS 连接](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)。 |
| `rpl_read_size` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `server_audit_cw_upload` | 否 | 该参数在 Aurora MySQL 中已弃用。使用 `server_audit_logs_upload`。 有关更多信息，请参阅 [将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)。 |
| `server_audit_events` | 是 | 有关更多信息，请参阅 [在 Amazon Aurora MySQL 数据库集群中使用高级审计](AuroraMySQL.Auditing.md)。 |
| `server_audit_excl_users` | 是 | 有关更多信息，请参阅 [在 Amazon Aurora MySQL 数据库集群中使用高级审计](AuroraMySQL.Auditing.md)。 |
| `server_audit_incl_users` | 是 | 有关更多信息，请参阅 [在 Amazon Aurora MySQL 数据库集群中使用高级审计](AuroraMySQL.Auditing.md)。 |
| `server_audit_logging` | 是 | 有关将日志上传到 Amazon CloudWatch Logs 的说明，请参阅[将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)。 |
| `server_audit_logs_upload` | 是 | 您可以通过启用高级审核并将此参数设置为 `1`，将审核日志发布到 CloudWatch Logs。`server_audit_logs_upload` 参数的默认值为 `0`。 有关更多信息，请参阅 [将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)。 |
| `server_id` | 否 | |
| `skip-character-set-client-handshake` | 是 | |
| `skip_name_resolve` | 否 | |
| `slave-skip-errors` | 是 | 仅适用于 Aurora MySQL 版本 2 的集群，具备 MySQL 5.7 兼容性。 |
| `source_verify_checksum` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `sync_frm` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `thread_cache_size` | 是 | 要缓存的线程数。此参数适用于 Aurora MySQL 版本 2 和 3。 |
| `time_zone` | 是 | 默认情况下，Aurora 数据库集群的时区是协调世界时（UTC）。您可以改为将数据库群集中实例的时区设置为您的应用程序的本地时区。有关更多信息，请参阅 [Amazon Aurora 数据库集群的本地时区](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone)。 |
| `tls_version` | 是 | 有关更多信息，请参阅“[Aurora MySQL 的 TLS 版本](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version)”。 |
## 实例级参数
下表显示了适用于 Aurora MySQL 数据库集群中特定数据库实例的所有参数。
| 参数名称 | 可修改 | 备注 |
| --- | --- | --- |
| `activate_all_roles_on_login` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `allow-suspicious-udfs` | 否 | |
| `aurora_disable_hash_join` | 是 | 将此参数设置为 `ON` 可在 Aurora MySQL 版本 2.09 或更高版本中关闭哈希联接优化。版本 3 不支持此参数。有关更多信息，请参阅 [Amazon Aurora MySQL 的并行查询](aurora-mysql-parallel-query.md)。 |
| `aurora_lab_mode` | 是 | 有关更多信息，请参阅 [Amazon Aurora MySQL 实验室模式](AuroraMySQL.Updates.LabMode.md)。已从 Aurora MySQL 版本 3 中删除。 |
| `aurora_oom_response` | 是 | Aurora MySQL 版本 2 和 3 支持此参数。有关更多信息，请参阅 [排查 Aurora MySQL 数据库内存不足问题](AuroraMySQLOOM.md)。 |
| `aurora_parallel_query` | 是 | 设置为 `ON` 可在 Aurora MySQL 版本 2.09 或更高版本中开启并行查询。旧的 `aurora_pq` 参数未在这些版本中使用。有关更多信息，请参阅“[Amazon Aurora MySQL 的并行查询](aurora-mysql-parallel-query.md)”。 |
| `aurora_pq` | 是 | 设置为 `OFF` 可在 2.09 之前的 Aurora MySQL 版本中为特定数据库实例关闭并行查询。在 2.09 或更高版本中，改为使用 `aurora_parallel_query` 打开和关闭并行查询。有关更多信息，请参阅 [Amazon Aurora MySQL 的并行查询](aurora-mysql-parallel-query.md)。 |
| `aurora_read_replica_read_committed` | 是 | 为 Aurora 副本启用 `READ COMMITTED` 隔离级别，并更改隔离行为，以在执行长时间运行的查询期间减少清除滞后。仅当您了解行为更改及其对查询结果的影响时，才启用该设置。例如，该设置使用了没有 MySQL 默认设置那么严格的隔离。启用该设置后，长时间运行的查询可能会看到同一行的多个副本，因为 Aurora 会在查询运行期间重组表数据。有关更多信息，请参阅 [Aurora MySQL 隔离级别](AuroraMySQL.Reference.IsolationLevels.md)。 |
| `aurora_tmptable_enable_per_table_limit` | 是 | 确定 `tmp_table_size` 参数是否控制 Aurora MySQL 版本 3.04 及更高版本中由 `TempTable` 存储引擎创建的内存中临时表的最大大小。 有关更多信息，请参阅 [限制内部内存中临时表的大小](ams3-temptable-behavior.md#ams3-temptable-behavior-limit)。 |
| `aurora_use_vector_instructions` | 是 | 启用此参数后，Aurora MySQL 将使用现代 CPU 提供的优化型矢量处理指令来提高 I/O 密集型工作负载的性能。 默认情况下，会在 Aurora MySQL 版本 3.05 及更高版本中启用该设置。 |
| `autocommit` | 是 | |
| `automatic_sp_privileges` | 是 | |
| `back_log` | 是 | |
| `basedir` | 不支持 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `binlog_cache_size` | 是 | |
| `binlog_max_flush_queue_time` | 是 | |
| `binlog_order_commits` | 是 | |
| `binlog_stmt_cache_size` | 是 | |
| `binlog_transaction_compression` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `binlog_transaction_compression_level_zstd` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `bulk_insert_buffer_size` | 是 | |
| `concurrent_insert` | 是 | |
| `connect_timeout` | 是 | |
| `core-file` | 不支持 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `datadir` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `default_authentication_plugin` | 否 | 此参数适用于 Aurora MySQL 版本 3。 |
| `default_time_zone` | 否 | |
| `default_tmp_storage_engine` | 是 | 临时表的原定设置存储引擎。 |
| `default_week_format` | 是 | |
| `delay_key_write` | 是 | |
| `delayed_insert_limit` | 是 | |
| `delayed_insert_timeout` | 是 | |
| `delayed_queue_size` | 是 | |
| `div_precision_increment` | 是 | |
| `end_markers_in_json` | 是 | |
| `eq_range_index_dive_limit` | 是 | |
| `event_scheduler` | 有时 | 指示事件计划程序的状态。 在 Aurora MySQL 版本 3 中，只能在集群级别修改。 |
| `explicit_defaults_for_timestamp` | 是 | |
| `flush` | 否 | |
| `flush_time` | 是 | |
| `ft_boolean_syntax` | 否 | |
| `ft_max_word_len` | 是 | |
| `ft_min_word_len` | 是 | |
| `ft_query_expansion_limit` | 是 | |
| `ft_stopword_file` | 是 | |
| `general_log` | 是 | 有关将日志上传到 CloudWatch Logs 的说明，请参阅 [将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)。 |
| `general_log_file` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `group_concat_max_len` | 是 | |
| `host_cache_size` | 是 | |
| `init_connect` | 是 | 服务器要对连接的每个客户端运行的命令。在设置中使用双引号（"）以避免连接失败，例如： SET optimizer_switch="hash_join=off"
在 Aurora MySQL 版本 3 中，此参数不适用于具有 `CONNECTION_ADMIN` 权限的用户，包括 Aurora 主用户。有关更多信息，请参阅 [基于角色的权限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。 |
| `innodb_adaptive_hash_index` | 是 | 在 Aurora MySQL 版本 2 中，您可以在数据库实例级别修改此参数。在 Aurora MySQL 版本 3 中，只能在数据库集群级别修改此参数。 读取器数据库实例不支持自适应哈希索引。 |
| `innodb_adaptive_max_sleep_delay` | 是 | 修改此参数不起作用，因为 Aurora 的 `innodb_thread_concurrency` 始终为 0。 |
| `innodb_aurora_max_partitions_for_range` | 是 | 在某些无法获得持久统计数据的情况下，您可以使用此参数来提高分区表的行计数估计性能。 您可以将其设置为 0–8192 之间的值，该值决定了在行计数估计期间要检查的分区数。默认值为 0，这将使用所有分区进行估计，与原定设置 MySQL 行为一致。 此参数适用于 Aurora MySQL 版本 3.03.1 及更高版本。 |
| `innodb_autoextend_increment` | 是 | |
| `innodb_buffer_pool_dump_at_shutdown` | 否 | |
| `innodb_buffer_pool_dump_now` | 否 | |
| `innodb_buffer_pool_filename` | 否 | |
| `innodb_buffer_pool_load_abort` | 否 | |
| `innodb_buffer_pool_load_at_startup` | 否 | |
| `innodb_buffer_pool_load_now` | 否 | |
| `innodb_buffer_pool_size` | 是 | 默认值由公式表示。有关公式中 `DBInstanceClassMemory` 值的计算方式详细信息，请参阅 [数据库参数公式变量](USER_ParamValuesRef.md#USER_FormulaVariables)。 |
| `innodb_change_buffer_max_size` | 否 | Aurora MySQL 完全不使用 InnoDB 更改缓冲区。 |
| `innodb_compression_failure_threshold_pct` | 是 | |
| `innodb_compression_level` | 是 | |
| `innodb_compression_pad_pct_max` | 是 | |
| `innodb_concurrency_tickets` | 是 | 修改此参数不起作用，因为 Aurora 的 `innodb_thread_concurrency` 始终为 0。 |
| `innodb_deadlock_detect` | 是 | 此选项用于在 Aurora MySQL 版本 2.11 及更高版本以及版本 3 中禁用死锁检测。 在高并发系统中，当许多线程等待同一个锁时，死锁检测可能会导致速度下降。有关此参数的更多信息，请参阅 MySQL 文档。 |
| `innodb_file_format` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `innodb_flushing_avg_loops` | 否 | |
| `innodb_force_load_corrupted` | 否 | |
| `innodb_ft_aux_table` | 是 | |
| `innodb_ft_cache_size` | 是 | |
| `innodb_ft_enable_stopword` | 是 | |
| `innodb_ft_server_stopword_table` | 是 | |
| `innodb_ft_user_stopword_table` | 是 | |
| `innodb_large_prefix` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `innodb_lock_wait_timeout` | 是 | |
| `innodb_log_compressed_pages` | 否 | |
| `innodb_lru_scan_depth` | 是 | |
| `innodb_max_purge_lag` | 是 | |
| `innodb_max_purge_lag_delay` | 是 | |
| `innodb_monitor_disable` | 是 | |
| `innodb_monitor_enable` | 是 | |
| `innodb_monitor_reset` | 是 | |
| `innodb_monitor_reset_all` | 是 | |
| `innodb_old_blocks_pct` | 是 | |
| `innodb_old_blocks_time` | 是 | |
| `innodb_open_files` | 是 | |
| `innodb_print_all_deadlocks` | 是 | 开启后，在 Aurora MySQL 错误日志中记录有关所有 InnoDB 死锁的信息。有关更多信息，请参阅 [最大限度地减少 Aurora MySQL 死锁以及排查相关问题](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks)。 |
| `innodb_random_read_ahead` | 是 | |
| `innodb_read_ahead_threshold` | 是 | |
| `innodb_read_io_threads` | 否 | |
| `innodb_read_only` | 否 | Aurora MySQL 根据集群类型管理数据库实例的只读和读/写状态。例如，预置的集群具有一个读/写数据库实例（*主实例*），并且集群中的所有其他实例都是只读的（Aurora 副本）。 |
| `innodb_replication_delay` | 是 | |
| `innodb_sort_buffer_size` | 是 | |
| `innodb_stats_auto_recalc` | 是 | |
| `innodb_stats_method` | 是 | |
| `innodb_stats_on_metadata` | 是 | |
| `innodb_stats_persistent` | 是 | |
| `innodb_stats_persistent_sample_pages` | 是 | |
| `innodb_stats_transient_sample_pages` | 是 | |
| `innodb_thread_concurrency` | 否 | |
| `innodb_thread_sleep_delay` | 是 | 修改此参数不起作用，因为 Aurora 的 `innodb_thread_concurrency` 始终为 0。 |
| `interactive_timeout` | 是 | Aurora 会估计 `interactive_timeout` 和 `wait_timeout` 的最小值，然后使用这个最小值作为超时来结束所有空闲会话，包括交互式会话和非交互式会话。 |
| `internal_tmp_disk_storage_engine` | 是 | 控制哪个内存存储引擎用于内部临时表。允许的值包括 `INNODB`和 `MYISAM`。 此参数适用于 Aurora MySQL 版本 2。 |
| `internal_tmp_mem_storage_engine` | 是 | 控制哪个内存存储引擎用于内部临时表。允许的值包括 `MEMORY`和 `TempTable`。 此参数适用于 Aurora MySQL 版本 3。 |
| `join_buffer_size` | 是 | |
| `keep_files_on_create` | 是 | |
| `key_buffer_size` | 是 | MyISAM 表的密钥缓存。有关更多信息，请参阅[密钥缓存 -> cache\$1lock 互斥锁](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)。 |
| `key_cache_age_threshold` | 是 | |
| `key_cache_block_size` | 是 | |
| `key_cache_division_limit` | 是 | |
| `local_infile` | 是 | |
| `lock_wait_timeout` | 是 | |
| `log-bin` | 否 | 将 `binlog_format` 设置为 `STATEMENT`、`MIXED` 或 `ROW` 会自动将 `log-bin` 设置为 `ON`。将 `binlog_format` 设置为 `OFF` 会自动将 `log-bin` 设置为 `OFF`。有关更多信息，请参阅“[Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)”。 |
| `log_bin_trust_function_creators` | 是 | |
| `log_bin_use_v1_row_events` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `log_error` | 否 | |
| `log_error_suppression_list` | 是 | 指定未在 MySQL 错误日志中记录的错误代码列表。这允许您忽略某些非关键错误条件，以帮助保持错误日志干净整洁。有关更多信息，请参阅 MySQL 文档中的 [log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)。 此参数适用于 Aurora MySQL 3.03 及更高版本。 |
| `log_output` | 是 | |
| `log_queries_not_using_indexes` | 是 | |
| `log_slave_updates` | 不支持 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `log_replica_updates`。 |
| `log_replica_updates` | 否 | Aurora MySQL 版本 3 |
| `log_throttle_queries_not_using_indexes` | 是 | |
| `log_warnings` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `long_query_time` | 是 | |
| `low_priority_updates` | 是 | `INSERT`、`UPDATE`、`DELETE` 和 `LOCK TABLE WRITE` 操作会等待，直至没有待处理的 `SELECT` 操作。此参数仅影响仅使用表级锁定的存储引擎（MyISAM、MEMORY、MERGE）。 此参数适用于 Aurora MySQL 版本 3。 |
| `max_allowed_packet` | 是 | |
| `max_binlog_cache_size` | 是 | |
| `max_binlog_size` | 否 | |
| `max_binlog_stmt_cache_size` | 是 | |
| `max_connect_errors` | 是 | |
| `max_connections` | 是 | 默认值由公式表示。有关公式中 `DBInstanceClassMemory` 值的计算方式详细信息，请参阅 [数据库参数公式变量](USER_ParamValuesRef.md#USER_FormulaVariables)。如需了解受实例类限制的默认值，请参阅 [至 Aurora MySQL 数据库实例的最大连接数](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections)。 |
| `max_delayed_threads` | 是 | 设置处理 `INSERT DELAYED` 语句的最大线程数。 此参数适用于 Aurora MySQL 版本 3。 |
| `max_error_count` | 是 | 存储以供显示的错误、警告和备注消息的最大数量。 此参数适用于 Aurora MySQL 版本 3。 |
| `max_execution_time` | 是 | 运行 `SELECT` 语句的超时时间，以毫秒为单位。值可以为 `0` – `18446744073709551615`。设置为 `0` 时，没有超时。 有关更多信息，请参阅 MySQL 文档中的 [max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)。 |
| `max_heap_table_size` | 是 | |
| `max_insert_delayed_threads` | 是 | |
| `max_join_size` | 是 | |
| `max_length_for_sort_data` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `max_prepared_stmt_count` | 是 | |
| `max_seeks_for_key` | 是 | |
| `max_sort_length` | 是 | |
| `max_sp_recursion_depth` | 是 | |
| `max_tmp_tables` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `max_user_connections` | 是 | |
| `max_write_lock_count` | 是 | |
| `metadata_locks_cache_size` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `min_examined_row_limit` | 是 | 使用此参数可防止记录所检查的行数少于指定行数的查询。 此参数适用于 Aurora MySQL 版本 3。 |
| `myisam_data_pointer_size` | 是 | |
| `myisam_max_sort_file_size` | 是 | |
| `myisam_mmap_size` | 是 | |
| `myisam_sort_buffer_size` | 是 | |
| `myisam_stats_method` | 是 | |
| `myisam_use_mmap` | 是 | |
| `net_buffer_length` | 是 | |
| `net_read_timeout` | 是 | |
| `net_retry_count` | 是 | |
| `net_write_timeout` | 是 | |
| `old-style-user-limits` | 是 | |
| `old_passwords` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `optimizer_prune_level` | 是 | |
| `optimizer_search_depth` | 是 | |
| `optimizer_switch` | 是 | 有关使用此开关的 Aurora MySQL 功能的信息，请参阅 [Amazon Aurora MySQL 的最佳实践](AuroraMySQL.BestPractices.md)。 |
| `optimizer_trace` | 是 | |
| `optimizer_trace_features` | 是 | |
| `optimizer_trace_limit` | 是 | |
| `optimizer_trace_max_mem_size` | 是 | |
| `optimizer_trace_offset` | 是 | |
| `performance-schema-consumer-events-waits-current` | 是 | |
| `performance-schema-instrument` | 是 | |
| `performance_schema` | 是 | |
| `performance_schema_accounts_size` | 是 | |
| `performance_schema_consumer_global_instrumentation` | 是 | |
| `performance_schema_consumer_thread_instrumentation` | 是 | |
| `performance_schema_consumer_events_stages_current` | 是 | |
| `performance_schema_consumer_events_stages_history` | 是 | |
| `performance_schema_consumer_events_stages_history_long` | 是 | |
| `performance_schema_consumer_events_statements_current` | 是 | |
| `performance_schema_consumer_events_statements_history` | 是 | |
| `performance_schema_consumer_events_statements_history_long` | 是 | |
| `performance_schema_consumer_events_waits_history` | 是 | |
| `performance_schema_consumer_events_waits_history_long` | 是 | |
| `performance_schema_consumer_statements_digest` | 是 | |
| `performance_schema_digests_size` | 是 | |
| `performance_schema_events_stages_history_long_size` | 是 | |
| `performance_schema_events_stages_history_size` | 是 | |
| `performance_schema_events_statements_history_long_size` | 是 | |
| `performance_schema_events_statements_history_size` | 是 | |
| `performance_schema_events_transactions_history_long_size` | 是 | |
| `performance_schema_events_transactions_history_size` | 是 | |
| `performance_schema_events_waits_history_long_size` | 是 | |
| `performance_schema_events_waits_history_size` | 是 | |
| `performance_schema_hosts_size` | 是 | |
| `performance_schema_max_cond_classes` | 是 | |
| `performance_schema_max_cond_instances` | 是 | |
| `performance_schema_max_digest_length` | 是 | |
| `performance_schema_max_file_classes` | 是 | |
| `performance_schema_max_file_handles` | 是 | |
| `performance_schema_max_file_instances` | 是 | |
| `performance_schema_max_index_stat` | 是 | |
| `performance_schema_max_memory_classes` | 是 | |
| `performance_schema_max_metadata_locks` | 是 | |
| `performance_schema_max_mutex_classes` | 是 | |
| `performance_schema_max_mutex_instances` | 是 | |
| `performance_schema_max_prepared_statements_instances` | 是 | |
| `performance_schema_max_program_instances` | 是 | |
| `performance_schema_max_rwlock_classes` | 是 | |
| `performance_schema_max_rwlock_instances` | 是 | |
| `performance_schema_max_socket_classes` | 是 | |
| `performance_schema_max_socket_instances` | 是 | |
| `performance_schema_max_sql_text_length` | 是 | |
| `performance_schema_max_stage_classes` | 是 | |
| `performance_schema_max_statement_classes` | 是 | |
| `performance_schema_max_statement_stack` | 是 | |
| `performance_schema_max_table_handles` | 是 | |
| `performance_schema_max_table_instances` | 是 | |
| `performance_schema_max_table_lock_stat` | 是 | |
| `performance_schema_max_thread_classes` | 是 | |
| `performance_schema_max_thread_instances` | 是 | |
| `performance_schema_session_connect_attrs_size` | 是 | |
| `performance_schema_setup_actors_size` | 是 | |
| `performance_schema_setup_objects_size` | 是 | |
| `performance_schema_show_processlist` | 是 | 此参数确定要使用哪个 SHOW PROCESSLIST 实现：[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)此参数适用于 Aurora MySQL 版本 2.12 及更高版本以及版本 3。 |
| `performance_schema_users_size` | 是 | |
| `pid_file` | 否 | |
| `plugin_dir` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `port` | 否 | Aurora MySQL 管理连接属性，并为集群中的所有数据库实例强制执行一致的设置。 |
| `preload_buffer_size` | 是 | 预加载索引时分配的缓冲区的大小。 此参数适用于 Aurora MySQL 版本 3。 |
| `profiling_history_size` | 是 | |
| `query_alloc_block_size` | 是 | |
| `query_cache_limit` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `query_cache_min_res_unit` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `query_cache_size` | 是 | 默认值由公式表示。有关公式中 `DBInstanceClassMemory` 值的计算方式详细信息，请参阅 [数据库参数公式变量](USER_ParamValuesRef.md#USER_FormulaVariables)。 已从 Aurora MySQL 版本 3 中删除。 |
| `query_cache_type` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `query_cache_wlock_invalidate` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `query_prealloc_size` | 是 | |
| `range_alloc_block_size` | 是 | |
| `read_buffer_size` | 是 | |
| `read_only` | 是 | 启用此参数时，除副本线程执行的更新外，服务器不允许任何更新。 对于 Aurora MySQL 版本 2，有效值如下所示： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 建议您在 Aurora MySQL 版本 2 中使用数据库集群参数组，以确保在故障转移时将 `read_only` 参数应用于新的写入器实例。 读取器实例始终是只读的，因为 Aurora MySQL 在所有读取器上将 `innodb_read_only` 设置为 `1`。因此，`read_only` 在读取器实例上是冗余的。 已从 Aurora MySQL 版本 3 的实例级别删除。 |
| `read_rnd_buffer_size` | 是 | |
| `relay-log` | 否 | |
| `relay_log_info_repository` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `relay_log_recovery` | 否 | |
| `replica_checkpoint_group` | 是 | Aurora MySQL 版本 3 |
| `replica_checkpoint_period` | 是 | Aurora MySQL 版本 3 |
| `replica_parallel_workers` | 是 | Aurora MySQL 版本 3 |
| `replica_pending_jobs_size_max` | 是 | Aurora MySQL 版本 3 |
| `replica_skip_errors` | 是 | Aurora MySQL 版本 3 |
| `replica_sql_verify_checksum` | 是 | Aurora MySQL 版本 3 |
| `safe-user-create` | 是 | |
| `secure_auth` | 是 | 在 Aurora MySQL 版本 2 中，此参数始终处于开启状态。尝试将其关闭会生成错误。 已从 Aurora MySQL 版本 3 中删除。 |
| `secure_file_priv` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `show_create_table_verbosity` | 是 | 启用此变量会导致 [SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) 显示 `ROW_FORMAT`，而不管它是否为原定设置格式。 此参数适用于 Aurora MySQL 版本 2.12 及更高版本以及版本 3。 |
| `skip-slave-start` | 否 | |
| `skip_external_locking` | 否 | |
| `skip_show_database` | 是 | |
| `slave_checkpoint_group` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `replica_checkpoint_group`。 |
| `slave_checkpoint_period` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `replica_checkpoint_period`。 |
| `slave_parallel_workers` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `replica_parallel_workers`。 |
| `slave_pending_jobs_size_max` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `replica_pending_jobs_size_max`。 |
| `slave_sql_verify_checksum` | 是 | Aurora MySQL 版本 2。在 Aurora MySQL 版本 3 中使用 `replica_sql_verify_checksum`。 |
| `slow_launch_time` | 是 | |
| `slow_query_log` | 是 | 有关将日志上传到 CloudWatch Logs 的说明，请参阅 [将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs](AuroraMySQL.Integrating.CloudWatch.md)。 |
| `slow_query_log_file` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `socket` | 否 | |
| `sort_buffer_size` | 是 | |
| `sql_mode` | 是 | |
| `sql_select_limit` | 是 | |
| `stored_program_cache` | 是 | |
| `sync_binlog` | 否 | |
| `sync_master_info` | 是 | |
| `sync_source_info` | 是 | 此参数适用于 Aurora MySQL 版本 3。 |
| `sync_relay_log` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `sync_relay_log_info` | 是 | |
| `sysdate-is-now` | 是 | |
| `table_cache_element_entry_ttl` | 否 | |
| `table_definition_cache` | 是 | 默认值由公式表示。有关公式中 `DBInstanceClassMemory` 值的计算方式详细信息，请参阅 [数据库参数公式变量](USER_ParamValuesRef.md#USER_FormulaVariables)。 |
| `table_open_cache` | 是 | 默认值由公式表示。有关公式中 `DBInstanceClassMemory` 值的计算方式详细信息，请参阅 [数据库参数公式变量](USER_ParamValuesRef.md#USER_FormulaVariables)。 |
| `table_open_cache_instances` | 是 | |
| `temp-pool` | 是 | 已从 Aurora MySQL 版本 3 中删除。 |
| `temptable_max_mmap` | 是 | 此参数适用于 Aurora MySQL 版本 3。有关详细信息，请参阅[Aurora MySQL 版本 3 中的新临时表行为](ams3-temptable-behavior.md)。 |
| `temptable_max_ram` | 是 | 此参数适用于 Aurora MySQL 版本 3。有关详细信息，请参阅[Aurora MySQL 版本 3 中的新临时表行为](ams3-temptable-behavior.md)。 |
| `temptable_use_mmap` | 是 | 此参数适用于 Aurora MySQL 版本 3。有关详细信息，请参阅[Aurora MySQL 版本 3 中的新临时表行为](ams3-temptable-behavior.md)。 |
| `thread_cache_size` | 是 | 要缓存的线程数。此参数适用于 Aurora MySQL 版本 2 和 3。 |
| `thread_handling` | 否 | |
| `thread_stack` | 是 | |
| `timed_mutexes` | 是 | |
| `tmp_table_size` | 是 | 在 Aurora MySQL 版本 3 中，定义由 `MEMORY` 存储引擎创建的内部内存中临时表的最大大小。 在 Aurora MySQL 版本 3.04 及更高版本中，定义当 `aurora_tmptable_enable_per_table_limit` 为 `ON` 时，由 `TempTable` 存储引擎创建的内部内存中临时表的最大大小。 有关更多信息，请参阅 [限制内部内存中临时表的大小](ams3-temptable-behavior.md#ams3-temptable-behavior-limit)。 |
| `tmpdir` | 否 | Aurora MySQL 使用不在其中直接访问文件系统的托管式实例。 |
| `transaction_alloc_block_size` | 是 | |
| `transaction_isolation` | 是 | 此参数适用于 Aurora MySQL 版本 3。它将代替 `tx_isolation`。 |
| `transaction_prealloc_size` | 是 | |
| `tx_isolation` | 是 | 已从 Aurora MySQL 版本 3 中删除。它将替换为 `transaction_isolation`。 |
| `updatable_views_with_limit` | 是 | |
| `validate-password` | 否 | |
| `validate_password_dictionary_file` | 否 | |
| `validate_password_length` | 否 | |
| `validate_password_mixed_case_count` | 否 | |
| `validate_password_number_count` | 否 | |
| `validate_password_policy` | 否 | |
| `validate_password_special_char_count` | 否 | |
| `wait_timeout` | 是 | Aurora 会估计 `interactive_timeout` 和 `wait_timeout` 的最小值，然后使用这个最小值作为超时来结束所有空闲会话，包括交互式会话和非交互式会话。 |
## 不适用于 Aurora MySQL 的 MySQL 参数
由于 Aurora MySQL 与 MySQL 之间存在架构差异，有些 MySQL 参数不适用于 Aurora MySQL。
以下 MySQL 参数不适用于 Aurora MySQL。此列表并不详尽。
+ `activate_all_roles_on_login` – 此参数不适用于 Aurora MySQL 版本 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_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout` – 此参数不适用于 Aurora MySQL。有关更多信息，请参阅 [配置刷新日志缓冲区的频率](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)。
+ `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_log_writer_threads`
+ `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_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Aurora MySQL 全局状态变量
Aurora MySQL 包括来自社区 MySQL 的状态变量和 Aurora 独有的变量。您可以检查这些变量，来了解数据库引擎内部正在发生的事情。有关社区 MySQL 中状态变量的更多信息，请参阅社区 MySQL 8.0 文档中的 [Server Status Variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html)。
您可以使用如下语句查找 Aurora MySQL 全局状态变量的当前值：
```
show global status like '%aurora%';
```
**注意**
数据库引擎重新启动时会清除全局状态变量。
下表描述了 Aurora MySQL 使用的全局状态变量。
| 名称 | 描述 |
| --- | --- |
| `AuroraDb_commits` | 自上次重启以来的提交总数。 |
| `AuroraDb_commit_latency` | 自上次重启以来的聚合提交延迟。 |
| `AuroraDb_ddl_stmt_duration` | 自上次重启以来的聚合 DDL 延迟。 |
| `AuroraDb_select_stmt_duration` | 自上次重启以来的聚合 `SELECT` 语句延迟。 |
| `AuroraDb_insert_stmt_duration` | 自上次重启以来的聚合 `INSERT` 语句延迟。 |
| `AuroraDb_update_stmt_duration` | 自上次重启以来的聚合 `UPDATE` 语句延迟。 |
| `AuroraDb_delete_stmt_duration` | 自上次重启以来的聚合 `DELETE` 语句延迟。 |
| `Aurora_binlog_io_cache_allocated` | 分配给二进制日志 I/O 缓存的字节数。 |
| `Aurora_binlog_io_cache_read_requests` | 向二进制日志 I/O 缓存发出的读取请求数。 |
| `Aurora_binlog_io_cache_reads` | 从二进制日志 I/O 缓存提供的读取请求数。 |
| `Aurora_enhanced_binlog` | 指示是为此数据库实例启用还是禁用了增强型二进制日志。有关更多信息，请参阅 [为 Aurora MySQL 设置增强型二进制日志](AuroraMySQL.Enhanced.binlog.md)。 |
| `Aurora_external_connection_count` | 与数据库实例的数据库连接数，不包括用于数据库运行状况检查的 RDS 服务连接。 |
| `Aurora_fast_insert_cache_hits` | 在成功检索和验证缓存游标时递增的计数器。有关快速插入缓存的更多信息，请参阅[Amazon Aurora MySQL 性能增强](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)。 |
| `Aurora_fast_insert_cache_misses` | 当缓存游标不再有效且 Aurora 执行常规索引遍历时递增的计数器。有关快速插入缓存的更多信息，请参阅[Amazon Aurora MySQL 性能增强](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)。 |
| `Aurora_fts_cache_memory_used` | InnoDB 全文搜索系统所使用的内存量（以字节为单位）。此变量适用于 Aurora MySQL 版本 3.07 及更高版本。 |
| `Aurora_fwd_master_dml_stmt_count` | 转发到此写入器数据库实例的 DML 语句总数。此变量适用于 Aurora MySQL 版本 2。 |
| `Aurora_fwd_master_dml_stmt_duration` | 转发到此写入器数据库实例的 DML 语句的总持续时间。此变量适用于 Aurora MySQL 版本 2。 |
| `Aurora_fwd_master_errors_rpc_timeout` | 在写入器上建立转发连接失败的次数。 |
| `Aurora_fwd_master_errors_session_limit` | 由于写入器上的 `session full` 而被拒绝的转发查询数。 |
| `Aurora_fwd_master_errors_session_timeout` | 由于写入器超时而结束转发会话的次数。 |
| `Aurora_fwd_master_open_sessions` | 写入器数据库实例上的转发会话数。此变量适用于 Aurora MySQL 版本 2。 |
| `Aurora_fwd_master_select_stmt_count` | 转发到此写入器数据库实例的 `SELECT` 语句总数。此变量适用于 Aurora MySQL 版本 2。 |
| `Aurora_fwd_master_select_stmt_duration` | 转发到此写入器数据库实例的 `SELECT` 语句的总持续时间。此变量适用于 Aurora MySQL 版本 2。 |
| `Aurora_fwd_writer_dml_stmt_count` | 转发到此写入器数据库实例的 DML 语句总数。此变量适用于 Aurora MySQL 版本 3。 |
| `Aurora_fwd_writer_dml_stmt_duration` | 转发到此写入器数据库实例的 DML 语句的总持续时间。此变量适用于 Aurora MySQL 版本 3。 |
| `Aurora_fwd_writer_errors_rpc_timeout` | 在写入器上建立转发连接失败的次数。 |
| `Aurora_fwd_writer_errors_session_limit` | 由于写入器上的 `session full` 而被拒绝的转发查询数。 |
| `Aurora_fwd_writer_errors_session_timeout` | 由于写入器超时而结束转发会话的次数。 |
| `Aurora_fwd_writer_open_sessions` | 写入器数据库实例上的转发会话数。此变量适用于 Aurora MySQL 版本 3。 |
| `Aurora_fwd_writer_select_stmt_count` | 转发到此写入器数据库实例的 `SELECT` 语句总数。此变量适用于 Aurora MySQL 版本 3。 |
| `Aurora_fwd_writer_select_stmt_duration` | 转发到此写入器数据库实例的 `SELECT` 语句的总持续时间。此变量适用于 Aurora MySQL 版本 3。 |
| `Aurora_lockmgr_buffer_pool_memory_used` | Aurora MySQL 锁定管理器正在使用的缓冲池内存量（以字节为单位）。 |
| `Aurora_lockmgr_memory_used` | Aurora MySQL 锁定管理器正在使用的内存量（以字节为单位）。 |
| `Aurora_ml_actual_request_cnt` | 在数据库实例用户运行的所有查询中，Aurora MySQL 对 Aurora 机器学习服务发出的请求次数总计。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_actual_response_cnt` | 在数据库实例用户运行的所有查询中，Aurora MySQL 从 Aurora 机器学习服务接收的响应次数总计。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_cache_hit_cnt` | 在数据库实例用户运行的所有查询中，Aurora MySQL 从 Aurora 机器学习服务接收的内部缓存命中次数总计。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_logical_request_cnt` | 自上次状态重置以来，数据库实例评估的要发送到 Aurora 机器学习服务的逻辑请求数。根据是否使用了批处理，此值可能高于 `Aurora_ml_actual_request_cnt`。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_logical_response_cnt` | 在数据库实例用户运行的所有查询中，Aurora MySQL 从 Aurora 机器学习服务接收的响应次数总计。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_retry_request_cnt` | 自上次状态重置以来，数据库实例已向 Aurora 机器学习服务发送的重试请求数。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `Aurora_ml_single_request_cnt` | 在数据库实例用户运行的所有查询中，非批处理模式评估的 Aurora 机器学习函数总计。有关更多信息，请参阅 [将 Amazon Aurora 机器学习与 Aurora MySQL 结合使用](mysql-ml.md)。 |
| `aurora_oom_avoidance_recovery_state` | 表示对于此数据库实例，Aurora 内存不足（OOM，Out-Of-Memory）避免恢复处于 `ACTIVE` 还是 `INACTIVE` 状态。 此变量适用于 Aurora MySQL 版本 3.06.0 及更高版本。 |
| `aurora_oom_reserved_mem_enter_kb` | 表示在 Aurora 的 OOM 处理机制中，进入 `RESERVED` 状态的阈值。 当服务器上的可用内存低于此阈值时，`aurora_oom_status` 会变为 `RESERVED`，表示服务器的内存使用量已接近临界水平。 此变量适用于 Aurora MySQL 版本 3.06.0 及更高版本。 |
| `aurora_oom_reserved_mem_exit_kb` | 表示在 Aurora 的 OOM 处理机制中，退出 `RESERVED` 状态的阈值。 当服务器上的可用内存上升超过此阈值时，`aurora_oom_status` 将恢复为 `NORMAL`，表示服务器已恢复到更稳定的状态，具有足够的内存资源。 此变量适用于 Aurora MySQL 版本 3.06.0 及更高版本。 |
| `aurora_oom_status` | 表示此数据库实例的当前 OOM 状态。当该值为 `NORMAL` 时，表示有足够的内存资源。 如果该值更改为 `RESERVED`，则表示服务器的可用内存不足。根据 `aurora_oom_response` 参数配置来采取操作。 有关更多信息，请参阅 [排查 Aurora MySQL 数据库内存不足问题](AuroraMySQLOOM.md)。 此变量适用于 Aurora MySQL 版本 3.06.0 及更高版本。 |
| `Aurora_pq_bytes_returned` | 在并行查询期间传输到头节点的元组数据结构的字节数。除以 16,384 以与 `Aurora_pq_pages_pushed_down` 进行比较。 |
| `Aurora_pq_max_concurrent_requests` | 可以在该 Aurora 数据库实例上并发运行的最大并行查询会话数。这是一个取决于 AWS 数据库实例类的固定数字。 |
| `Aurora_pq_pages_pushed_down` | 并行查询避免通过网络传输到头节点的数据页面数量（每个页面具有 16 KiB 的固定大小）。 |
| `Aurora_pq_request_attempted` | 请求的并行查询会话数。该值可能表示每个查询具有多个会话，具体取决于 SQL 结构，如子查询和联接。 |
| `Aurora_pq_request_executed` | 成功运行的并行查询会话数。 |
| `Aurora_pq_request_failed` | 向客户端返回错误的并行查询会话数。在某些情况下，并行查询请求可能会失败，例如，由于在存储层中出现问题。在这些情况下，将使用非并行查询机制重试失败的查询部分。如果重试的查询也失败，则会向客户端返回错误并增加该计数器。 |
| `Aurora_pq_request_in_progress` | 当前运行的并行查询会话数。该数字适用于您连接到的特定 Aurora 数据库实例，而不适用于整个 Aurora 数据库集群。要查看数据库实例是否接近其并发限制，请将该值与 `Aurora_pq_max_concurrent_requests` 进行比较。 |
| `Aurora_pq_request_not_chosen` | 未选择并行查询以满足查询条件的次数。该值是几个其他更精细的计数器的总和。即使没有实际执行查询，`EXPLAIN` 语句也可能增加此计数器。 |
| `Aurora_pq_request_not_chosen_below_min_rows` | 由于表中的行数而未选择并行查询的次数。即使没有实际执行查询，`EXPLAIN` 语句也可能增加此计数器。 |
| `Aurora_pq_request_not_chosen_column_bit` | 由于投影列的列表中的数据类型不受支持而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_column_geometry` | 由于表具有 `GEOMETRY` 数据类型的列而使用非并行查询处理路径的并行查询请求数。有关删除此限制的 Aurora MySQL 版本的信息，请参阅 [将并行查询集群升级到 Aurora MySQL 版本 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2)。 |
| `Aurora_pq_request_not_chosen_column_lob` | 由于表具有 `LOB` 数据类型的列或具有（由于声明的长度）而在外部存储的 `VARCHAR` 列，因此使用非并行查询处理路径的并行查询请求数。有关删除此限制的 Aurora MySQL 版本的信息，请参阅 [将并行查询集群升级到 Aurora MySQL 版本 3](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2)。 |
| `Aurora_pq_request_not_chosen_column_virtual` | 由于表包含虚拟列而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_custom_charset` | 由于表具有带自定义字符集的列而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_fast_ddl` | 由于表当前正在被快速 DDL `ALTER` 语句更改而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | 由于没有足够的未缓冲表数据以值得运行并行查询而未选择并行查询的次数，即使缓冲池中的表数据少于 95%。 |
| `Aurora_pq_request_not_chosen_full_text_index` | 由于表具有全文索引而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | 由于在缓冲池中具有较高比例的表数据（目前大于 95%）而未选择并行查询的次数。在这些情况下，优化程序确定从缓冲池中读取数据更高效。即使没有实际执行查询，`EXPLAIN` 语句也可能增加此计数器。 |
| `Aurora_pq_request_not_chosen_index_hint` | 由于查询包含索引提示而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_innodb_table_format` | 由于表使用不受支持的 InnoDB 行格式，因此使用非并行查询处理路径的并行查询请求数。Aurora 并行查询仅适用于 `COMPACT`、`REDUNDANT` 和 `DYNAMIC` 行格式。 |
| `Aurora_pq_request_not_chosen_long_trx` | 由于正在长时间运行的事务中启动查询而使用非并行查询处理路径的并行查询请求数。即使没有实际执行查询，`EXPLAIN` 语句也可能增加此计数器。 |
| `Aurora_pq_request_not_chosen_no_where_clause` | 由于查询不包含任何 `WHERE` 子句而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_range_scan` | 由于查询对索引使用范围扫描而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_row_length_too_long` | 由于所有列的总组合长度过长而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_small_table` | 由于表的总大小（由行数和平均行长度确定）而未选择并行查询的次数。即使没有实际执行查询，`EXPLAIN` 语句也可能增加此计数器。 |
| `Aurora_pq_request_not_chosen_temporary_table` | 由于查询引用了临时表（这些临时表使用不受支持的 `MyISAM` 或 `memory` 表类型）而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_tx_isolation` | 由于查询使用不受支持的事务隔离级别而使用非并行查询处理路径的并行查询请求数。在读取器数据库实例上，并行查询仅适用于 `REPEATABLE READ` 和 `READ COMMITTED` 隔离级别。 |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | 由于查询是 `UPDATE` 或 `DELETE` 语句的一部分而使用非并行查询处理路径的并行查询请求数。 |
| `Aurora_pq_request_not_chosen_unsupported_access` | 由于 `WHERE` 子句不符合并行查询条件而使用非并行查询处理路径的并行查询请求数。如果查询不需要数据密集型扫描，或者查询是 `DELETE` 或 `UPDATE` 语句，则会出现该结果。 |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | 由于 Aurora MySQL 数据库集群未使用支持的 Aurora 集群存储配置，而使用非并行查询处理路径的并行查询请求的数量。有关更多信息，请参阅 [限制](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations)。 此参数适用于 Aurora MySQL 版本 3.04 及更高版本。 |
| `Aurora_pq_request_throttled` | 由于在特定 Aurora 数据库实例上已运行的最大并发并行查询数而未选择并行查询的次数。 |
| `Aurora_repl_bytes_received` | 自上次重启以来复制到 Aurora MySQL 读取器数据库实例的字节数。有关更多信息，请参阅 [使用 Amazon Aurora MySQL 进行复制](AuroraMySQL.Replication.md)。 |
| `Aurora_reserved_mem_exceeded_incidents` | 自上次重启以来引擎超过预留内存限制的次数。如果配置了 `aurora_oom_response`，则此阈值定义何时触发避免内存不足（OOM）的活动。有关 Aurora MySQL OOM 响应的更多信息，请参阅[排查 Aurora MySQL 数据库内存不足问题](AuroraMySQLOOM.md)。 |
| `aurora_temptable_max_ram_allocation` | 自上次重启以来内部临时表在任一时候使用的最大内存量（以字节为单位）。 |
| `aurora_temptable_ram_allocation` | 内部临时表使用的当前内存量（以字节为单位）。 |
| `Aurora_in_memory_relaylog_status` | 内存中继日志功能的当前状态，值可以为 ENABLED 或 DISABLED。 |
| `Aurora_in_memory_relaylog_disabled_reason` | 显示当前内存中继日志功能状态的原因，如果禁用该功能，则显示一条消息来解释有关禁用该功能的原因。 |
| `Aurora_in_memory_relaylog_fallback_count` | 显示内存中继日志功能回退到持久中继日志模式（旧版）的总数。回退可能是由于单个事件大于缓存大小（当前为 128 MB）或事务重试超过副本事务重试限制 replica\$1transaction\$1retries 所致。 |
| `Aurora_in_memory_relaylog_recovery_count` | 显示自动执行的内存中继日志恢复总数。此计数包括回退总数以及临时回退后自动模式切换回内存中继日志模式的次数。 |
| `Aurora_thread_pool_thread_count` | Aurora 线程池中的当前线程数。有关 Aurora MySQL 中线程池的更多信息，请参阅[线程池](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool)。 |
| `Aurora_tmz_version` | 表示数据库集群使用的时区信息的当前版本。这些值遵循互联网号码分配机构（IANA）格式：`YYYYsuffix`，例如 `2022a` 和 `2023c`。 此参数适用于 Aurora MySQL 版本 2.12 及更高版本和版本 3.04 及更高版本。 |
| `Aurora_zdr_oom_threshold` | 表示内存阈值，以千字节（KB）为单位，达到该阈值时，Aurora 数据库实例将启动零停机重启（ZDR，Zero Downtime Restart），以便从潜在的内存相关问题中恢复。 |
| `server_aurora_das_running` | 表示在此数据库实例上是启用还是禁用了数据库活动流（DAS）。有关更多信息，请参阅 [使用数据库活动流监控 Amazon Aurora](DBActivityStreams.md)。 |
## 不适用于 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_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 版本 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 的一些常见等待事件。
**注意**
有关使用等待事件调整 Aurora MySQL 性能的信息，请参阅[使用等待事件优化 Aurora MySQL](AuroraMySQL.Managing.Tuning.wait-events.md)。
有关 MySQL 等待事件中使用的命名约定的信息，请参阅 MySQL 文档中的[性能架构测试命名约定](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html)。
**cpu**
准备运行的活动连接数一直高于 vCPU 的数量。有关更多信息，请参阅 [cpu](ams-waits.cpu.md)。
**io/aurora\$1redo\$1log\$1flush**
会话将数据持久存储到 Aurora 存储。通常，该等待事件针对 Aurora MySQL 中的写入 I/O 操作。有关更多信息，请参阅 [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)。
**io/aurora\$1respond\$1to\$1client**
以下 Aurora MySQL 版本的查询处理已完成，结果将返回到应用程序客户端：2.10.2 及更高的 2.10 版本、2.09.3 及更高的 2.09 版本和 2.07.7 及更高的 2.07 版本。将数据库实例类的网络带宽与返回的结果集的大小进行比较。另外，请检查客户端响应时间。如果客户端无响应且无法处理 TCP 数据包，则可能会发生数据包丢弃和 TCP 重新传输。这种情况会对网络带宽产生负面影响。在低于 2.10.2、2.09.3 和 2.07.7 的版本中，等待事件错误地包含空闲时间。要了解如何在此等待突出时优化数据库，请参阅 [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md)。
**io/file/csv/data**
线程以逗号分隔值 (CSV) 格式写入表。检查您的 CSV 表使用情况。此事件的典型原因是在表上设置 `log_output`。
**io/file/sql/binlog**
线程在等待正写入磁盘的二进制日志 (binlog) 文件。
**io/redo\$1log\$1flush**
会话将数据持久存储到 Aurora 存储。通常，该等待事件针对 Aurora MySQL 中的写入 I/O 操作。有关更多信息，请参阅 [io/redo\$1log\$1flush](ams-waits.io-redologflush.md)。
**io/socket/sql/client\$1connection**
`mysqld` 程序正忙于创建线程来处理传入的新客户端连接。有关更多信息，请参阅 [io/socket/sql/client\$1connection](ams-waits.client-connection.md)。
**io/table/sql/handler**
引擎正在等待访问表格。无论数据是缓存在缓冲池中还是可在磁盘上访问，都会发生此事件。有关更多信息，请参阅 [io/table/sql/handler](ams-waits.waitio.md)。
**lock/table/sql/handler**
该等待事件是表锁定等待事件处理程序。有关性能架构中的“原子”和“分子”事件的更多信息，请参阅 MySQL 文档中的[性能架构原子和分子事件](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html)。
**synch/cond/innodb/row\$1lock\$1wait**
多个数据操作语言 (DML) 语句同时访问相同的数据库行。有关更多信息，请参阅 [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md)。
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
多条 DML 语句同时访问相同的数据库行。有关更多信息，请参阅 [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md)。
**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**
线程正等待表元数据锁定。引擎使用这种类型的锁定来管理对数据库架构的并发访问并确保数据的一致性。有关更多信息，请参阅 MySQL 文档中的[优化锁定操作](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html)。要了解如何在此事件突出时优化数据库，请参阅 [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md)。
**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**
您已开启二进制日志记录。可能存在较高的提交吞吐量、大量事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中，使用全局数据库而不是二进制日志复制，或者使用 `aurora_binlog_*` 参数。
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
多条 DML 语句同时访问相同的数据库行。有关更多信息，请参阅 [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)。
**synch/mutex/innodb/buf\$1pool\$1mutex**
缓冲池不够大，无法容纳正常工作的数据集。或者，工作负载访问特定表中的页面，这会导致缓冲池中的争用。有关更多信息，请参阅 [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md)。
**synch/mutex/innodb/fil\$1system\$1mutex**
该进程正在等待对表空间内存缓存的访问。有关更多信息，请参阅 [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md)。
**synch/mutex/innodb/trx\$1sys\$1mutex**
操作正在以一致或受控的方式在 InnoDB 中检查、更新、删除或添加事务 ID。这些操作需要 `trx_sys` 互斥调用，该调用由性能架构工具跟踪。操作包括在数据库启动或关闭时管理事务系统、回滚、撤消清理、行读取访问和缓冲池加载。高数据库负载和大量事务导致此等待事件频繁出现。有关更多信息，请参阅 [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md)。
**synch/mutex/mysys/KEY\$1CACHE::cache\$1lock**
`keycache->cache_lock` 互斥控制对 MyISAM 表的密钥缓存的访问。虽然 Aurora MySQL 不允许使用 MyISAM 表来存储持久数据，但它们用于存储内部临时表。考虑检查 `created_tmp_tables` 或 `created_tmp_disk_tables` 状态计数器，因为在某些情况下，当临时表不再适合放入内存中时，会将其写入磁盘。
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1offsets**
在打开或创建表元数据文件时，引擎会获取此互斥。当此等待事件发生频率过高时，创建或打开的表的数量会激增。
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**
引擎在跟踪打开的表的内部结构上执行以下操作（如 `reset_size`、`detach_contents` 或 `add_contents`）时获取此互斥。该互斥可同步对列表内容的访问。当此等待事件以高频发生时，它表示之前访问的表集突然发生变化。引擎需要访问新表或放弃与之前访问的表相关的上下文。
**synch/mutex/sql/LOCK\$1open**
会话打开的表数超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息，请参阅 [MySQL 如何打开和关闭表](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)。
**synch/mutex/sql/LOCK\$1table\$1cache**
会话打开的表数量超过了表定义缓存或表打开缓存的大小。增加这些缓存的大小。有关更多信息，请参阅 [MySQL 如何打开和关闭表](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)。
**synch/mutex/sql/LOG**
在该等待事件中，有正等待日志锁定的线程。例如，线程可能等待锁定写入慢速查询日志文件。
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**
在该等待事件中，有正等待带着提交到二进制日志的意图获取锁定的线程。二进制日志记录争用可能出现在更改率非常高的数据库上。根据您的 MySQL 版本，有特定锁定用于保护二进制日志的一致性和持续性。在 RDS for MySQL 中，二进制日志用于复制和自动备份过程。在 Aurora MySQL 中，本机复制或备份不需要二进制日志。它们默认情况下处于禁用状态，但可以启用或用于外部复制或更改数据捕获。有关更多信息，请参阅 MySQL 文档中的[二进制日志](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1dump\$1thread\$1metrics\$1collection**
如果打开了二进制日志记录，则当引擎将活动转储线程指标打印到引擎错误日志和内部操作映射时，将获得此互斥。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1inactive\$1binlogs\$1map**
如果打开了二进制日志记录，引擎在添加、删除或搜索最新二进制日志文件后面的二进制日志文件列表时获取此互斥。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1io\$1cache**
如果打开二进制日志记录，引擎将在以下 Aurora 二进制日志 IO 缓存操作期间获取此互斥：分配、调整大小、释放、写入、读取、清除和访问缓存信息。如果此事件频繁发生，则引擎在访问存储二进制日志事件的缓存。为了减少等待时间，请减少提交。尝试将多个语句分组到一个事务中。
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**
您已开启二进制日志记录。可能存在较高的提交吞吐量、很多事务提交或读取二进制日志的副本。考虑使用多行语句或将语句捆绑到一个事务中。在 Aurora 中，使用全局数据库而不是二进制日志复制，或使用 `aurora_binlog_*` 参数。
**synch/mutex/sql/SERVER\$1THREAD::LOCK\$1sync**
互斥锁 `SERVER_THREAD::LOCK_sync` 在调度、处理或启动线程以进行文件写入的过程中获取。此等待事件发生过多表示数据库中的写入活动增加。
**synch/mutex/sql/TABLESPACES:lock**
引擎在以下表空间操作期间获取 `TABLESPACES:lock` 互斥：创建、删除、截断和扩展。此等待事件发生过多表示表空间操作频率很高。例如，将大量数据加载到数据库中。
**synch/rwlock/innodb/dict**
在该等待事件中，有正等待 InnoDB 数据字典中保留的 rwlock 的线程。
**synch/rwlock/innodb/dict\$1operation\$1lock**
在该等待事件中，有在 InnoDB 数据字典操作中保留锁定的线程。
**synch/rwlock/innodb/dict sys RW lock**
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
大量类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外，将工作负载分散到不同的数据库对象上。例如，实施分区。
**synch/sxlock/innodb/dict\$1operation\$1lock**
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
**synch/sxlock/innodb/dict\$1sys\$1lock**
同时触发数据定义语言代码 (DDL) 中的大量并发数据控制语言语句 (DCL)。在常规应用程序活动期间，减少应用程序对 DDL 的依赖。
**synch/sxlock/innodb/hash\$1table\$1locks**
会话在缓冲池中找不到页面。引擎要么需要读取文件，要么需要修改缓冲池的最近使用最少 (LRU) 列表。考虑增加缓冲区缓存大小并改进相关查询的访问路径。
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
很多类似的数据操作语言 (DML) 语句同时访问相同的数据库对象。尝试使用多行语句。此外，将工作负载分散到不同的数据库对象上。例如，实施分区。
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
当会话等待获取用于管理会话临时表空间池的互斥锁时，会发生此等待事件。
有关同步等待事件问题排查的更多信息，请参阅[为什么我的 MySQL 数据库实例在 Performance Insights 中的 SYNCH 等待事件显示有大量活动会话正在等待？](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/)
# 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` 子句。有关更多信息，请参阅 [创建排序索引](ams-states.sort-index.md)。
**创建表**
该线程正在创建一个永久表或临时表。
**延迟提交确定完成**
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` 语句的行，但尚未开始向客户端发送数据。该过程是确定哪些页面包含满足查询所需的结果。有关更多信息，请参阅 [发送数据](ams-states.sending-data.md)。
**发送给客户端**
服务器正在向客户端写入数据包。在早期的 MySQL 版本中，此等待事件被标记为 `writing to net`。
**starting**
这是语句执行开始的第一阶段。
**statistics**
服务器正在计算统计数据以制定查询执行计划。如果线程长期处于此状态，则在执行其他工作时，服务器可能会绑定磁盘。
**将结果存储在查询缓存中**
服务器正在将查询结果存储在查询缓存中。
**系统锁定**
线程已调用 `mysql_lock_tables`，但是自调用以来，线程状态尚未更新。出现这种普遍状态的原因很多。
**更新**
线程正在准备开始更新表格。
**更新**
线程正在搜索行并更新它们。
**用户锁定**
该线程发出 `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 中的工作方式与在 RDS for MySQL 中的工作方式相同。
## 读取器实例的 REPEATABLE READ 隔离级别
默认情况下，配置为只读 Aurora 副本的 Aurora MySQL 数据库实例始终使用 `REPEATABLE READ` 隔离级别。这些数据库实例会忽略任何 `SET TRANSACTION ISOLATION LEVEL` 语句并继续使用 `REPEATABLE READ` 隔离级别。
## 读取器实例的 READ COMMITTED 隔离级别
如果您的应用程序包括主实例上的写入密集型工作负载和 Aurora 副本上的长时间运行的查询，则可能会产生大量的清除滞后。当内部垃圾回收被长时间运行的查询阻止时，就会发生*清除滞后*。您看到的症状是 `SHOW ENGINE INNODB STATUS` 命令输出中的 `history list length` 值很高。可以使用 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 中使用写入转发](aurora-global-database-write-forwarding.md)。
### 对读取器使用 READ COMMITTED
要对 Aurora 副本使用 `READ COMMITTED` 隔离级别，请将 `aurora_read_replica_read_committed` 配置设置设为 `ON`。在连接到特定的 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` 设置。如果没有长时间运行的查询和写入密集型工作负载的组合，就不太可能遇到历史记录列表长度的问题。
**Example 显示 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\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | Q1：SELECT COUNT(\$1) FROM big\$1table; | Q2：SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | 如果 Q1 现在完成，则结果为 1,000,000。 | 如果 Q2 现在完成，则结果为 1,000,000 或 1,000,001。 |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | 如果 Q1 现在完成，则结果为 1,000,000。 | 如果 Q2 现在完成，则结果为 1,000,000 或 1,000,001 或 999,999 或 999,998。 |
| T7 | UPDATE big\$1table 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(\$1) FROM big\$1table; | Q4：SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | 如果 Q3 现在完成，则结果为 999,999。 | 如果 Q4 现在完成，则结果为 999,999。 |
| T11 | | Q5：SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6：SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (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 参考手册》**中的[优化程序提示](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)。
以下提示在 Aurora MySQL 版本 2 中可用。这些提示适用于使用 Aurora MySQL 版本 2 中的哈希联接功能的查询，尤其是使用并行查询优化的查询。
**PQ、NO\$1PQ**
指定是否强制优化程序在每个表或每个查询的基础上使用并行查询。
`PQ` 强制优化程序对指定的表或整个查询（块）使用并行查询。`NO_PQ` 防止优化程序对指定表或整个查询（块）使用并行查询。
此提示在 Aurora MySQL 版本 2.11 及更高版本中可用。以下示例向您显示如何使用此提示。
指定表名称会强制优化程序仅对那些选择的表应用 `PQ/NO_PQ` 提示。不指定表名称会强制对受查询块影响的所有表应用 `PQ/NO_PQ` 提示。
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN、NO\$1HASH\$1JOIN**
开启或关闭并行查询优化程序的功能来选择是否对查询使用哈希联接优化方法。`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\$1JOIN\$1PROBING、NO\$1HASH\$1JOIN\$1PROBING**
在哈希联接查询中，指定是否将指定的表用于联接的探查端。查询测试构建表中的列值是否存在于探查表中，而不是读取探查表的全部内容。您可以使用 `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\$1JOIN\$1BUILDING、NO\$1HASH\$1JOIN\$1BUILDING**
在哈希联接查询中，指定是否将指定的表用于联接的构建端。查询处理此表中的所有行来构建列值列表，以便与其他表进行交叉引用。您可以使用 `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\$1FIXED\$1ORDER**
指定查询中的表按它们在查询中的列出顺序进行联接。它对于涉及三个或更多表的查询很有用。它旨在替代 MySQL `STRAIGHT_JOIN` 提示，作用等同于 MySQL [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 提示。此提示在 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\$1ORDER**
指定查询中表的联接顺序。它对于涉及三个或更多表的查询很有用。它等效于 MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 提示。此提示在 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\$1PREFIX**
指定联接顺序中首先放置的表。它对于涉及三个或更多表的查询很有用。它等效于 MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 提示。此提示在 Aurora MySQL 版本 2.08 及更高版本中可用。
以下示例向您显示如何使用此提示。
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
指定联接顺序中最后放置的表。它对于涉及三个或更多表的查询很有用。它等效于 MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) 提示。此提示在 Aurora MySQL 版本 2.08 及更高版本中可用。
以下示例向您显示如何使用此提示。
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
有关使用哈希联接查询的信息，请参阅[使用哈希联接优化大型 Aurora MySQL 联接查询](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin)。
# Aurora MySQL 存储过程参考
您可以通过调用内置的存储过程管理 Aurora MySQL 数据库集群。
**Topics**
+ [收集和维护全局状态历史记录](mysql-stored-proc-gsh.md)
+ [配置、启动和停止二进制日志（binlog）复制](mysql-stored-proc-replicating.md)
+ [结束会话或查询](mysql-stored-proc-ending.md)
+ [使用 GTID 复制事务](mysql-stored-proc-gtid.md)
+ [轮换查询日志](mysql-stored-proc-logging.md)
+ [设置和显示二进制日志配置](mysql-stored-proc-configuring.md)
# 收集和维护全局状态历史记录
Amazon RDS 提供了一组过程，这些过程可以随时间推移对状态变量的值创建快照，并将它们及上次创建快照后所做的任何更改写入一个表中。该基础设施称为全局状态历史记录。有关更多信息，请参阅[管理全局状态历史记录](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)。
以下存储过程管理全局状态历史记录的收集和维护方式。
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
按需为全局状态历史记录创建快照。
### 语法
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
关闭全局状态历史记录创建的快照。
### 语法
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
关闭 `mysql.global_status_history` 表的交替。
### 语法
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
开启全局状态历史记录，以 `rds_set_gsh_collector` 指定的间隔创建原定设置快照。
### 语法
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
按照 `rds_set_gsh_rotation` 指定的间隔，开启将 `mysql.global_status_history` 表的内容交替到 `mysql.global_status_history_old`
### 语法
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
根据需求将 `mysql.global_status_history` 表的内容交替到 `mysql.global_status_history_old`。
### 语法
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
指定全局状态历史记录创建的快照之间的间隔，以分钟为单位。
### 语法
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### 参数
*intervalPeriod*
快照之间的间隔，以分钟为单位。默认值为 `5`。
## mysql.rds\$1set\$1gsh\$1rotation
指定 `mysql.global_status_history` 表轮换之间的间隔，以天为单位。
### 语法
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### 参数
*intervalPeriod*
表轮换之间的间隔，以天为单位。默认值为 `7`。
# 配置、启动和停止二进制日志（binlog）复制
您可以在连接到 Aurora MySQL 集群中的主实例时，调用以下存储过程。这些过程控制事务如何从外部数据库复制到 Aurora MySQL，或从 Aurora MySQL 复制到外部数据库。
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog（Aurora MySQL 版本 2）](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog（Aurora MySQL 版本 2）](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log（Aurora MySQL 版本 2）](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log（Aurora MySQL 版本 3）](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master（Aurora MySQL 版本 2）](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source（Aurora MySQL 版本 3）](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl（Aurora MySQL 版本 3）](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master（Aurora MySQL 版本 2）](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source（Aurora MySQL 版本 3）](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position（Aurora MySQL 版本 2）](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position（Aurora MySQL 版本 3）](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position（Aurora MySQL 版本 2）](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only（Aurora MySQL 版本 3）](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format（Aurora MySQL 版本 2）](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position（Aurora MySQL 版本 3）](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog（Aurora MySQL 版本 2）
通过将 `sql_log_bin` 变量设置为 `OFF` 来关闭当前会话的二进制日志记录。
### 语法
```
CALL mysql.rds_disable_session_binlog;
```
### 参数
无
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
对于 Aurora，Aurora MySQL 版本 2.12 及更高的与 MySQL 5.7 兼容的版本支持此过程。
**注意**
在 Aurora MySQL 版本 3 中，如果您具有 `SESSION_VARIABLES_ADMIN` 权限，则可以使用以下命令禁用当前会话的二进制日志记录：
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog（Aurora MySQL 版本 2）
通过将 `sql_log_bin` 变量设置为 `ON` 来开启当前会话的二进制日志记录。
### 语法
```
CALL mysql.rds_enable_session_binlog;
```
### 参数
无
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
对于 Aurora，Aurora MySQL 版本 2.12 及更高的与 MySQL 5.7 兼容的版本支持此过程。
**注意**
在 Aurora MySQL 版本 3 中，如果您具有 `SESSION_VARIABLES_ADMIN` 权限，则可以使用以下命令启用当前会话的二进制日志记录：
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
将证书颁发机构证书、客户端证书和客户端密钥导入到 Aurora MySQL 数据库集群中。SSL 通信和加密复制需要此类信息。
**注意**
目前，Aurora MySQL 版本 2（2.09.2、2.10.0、2.10.1 和 2.11.0）以及版本 3（3.01.1 及更高版本）支持此过程。
### 语法
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### 参数
*ssl\$1material*
包含 MySQL 客户端的以下 .pem 格式文件内容的 JSON 负载：
+ "ssl\$1ca":"*证书颁发机构证书*"
+ "ssl\$1cert":"*客户端证书*"
+ "ssl\$1key":"*客户端密钥*"
### 使用说明
在运行该过程之前，为加密复制做好以下准备：
+ 如果您没有在外部 MySQL 源数据库实例上启用 SSL，并且没有准备客户端密钥和客户端证书，请在 MySQL 数据库服务器上启用 SSL 并生成所需的客户端密钥和客户端证书。
+ 如果在外部源数据库实例上启用了 SSL，请提供 Aurora MySQL 数据库集群的客户端密钥和证书。如果未提供，请为 Aurora MySQL 数据库集群生成新密钥和证书。要对客户端证书进行签名，您必须拥有您用来在外部 MySQL 源数据库实例上配置 SSL 的证书颁发机构密钥。
有关更多信息，请参阅 MySQL 文档中的[使用 openssl 创建 SSL 证书和密钥](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)。
**重要**
为加密复制做好准备后，使用 SSL 连接来运行该过程。不得通过不安全的连接传输客户端密钥。
该过程会将 SSL 信息从外部 MySQL 数据库导入到 Aurora MySQL 数据库集群中。SSL 信息是 .pem 格式文件，其中包含 Aurora MySQL 数据库集群的 SSL 信息。在加密复制期间，Aurora MySQL 数据库集群充当 MySQL 数据库服务器的客户端。Aurora MySQL 客户端的证书和密钥必须是 .pem 格式的文件。
您可以将这些文件中的信息复制到正确 JSON 负载的 `ssl_material` 参数中。要支持加密复制，请将此类 SSL 信息导入到 Aurora MySQL 数据库集群中。
JSON 负载必须为以下格式。
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### 示例
以下示例将 SSL 信息导入到 Aurora MySQL。在 .pem 格式文件中，主体代码通常比示例中显示的主体代码长。
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## mysql.rds\$1next\$1master\$1log（Aurora MySQL 版本 2）
将源数据库实例日志位置更改为源数据库实例上的下一个二进制日志的开始位置。只有在只读副本上收到复制 I/O 错误 1236 时，才能使用该过程。
### 语法
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### 参数
*curr\$1master\$1log*
当前主日志文件的索引。例如，如果当前文件名为 `mysql-bin-changelog.012345`，则索引为 12345。若要确定当前主日志文件名，请运行 `SHOW REPLICA STATUS` 命令并查看 `Master_Log_File` 字段。
### 使用说明
主用户必须运行 `mysql.rds_next_master_log` 过程。
**警告**
仅在对作为复制源的多可用区数据库实例进行故障转移后复制失败，并且 `mysql.rds_next_master_log` 的 `Last_IO_Errno` 字段报告 I/O 错误 1236 时调用 `SHOW REPLICA STATUS`。
如果在发生失效转移事件之前，源实例中的事务未写入到磁盘上的二进制日志，调用 `mysql.rds_next_master_log` 可能会导致只读副本丢失数据。
### 示例
假设复制在 Aurora MySQL 只读副本上失败。对只读副本运行 `SHOW REPLICA STATUS\G` 会返回以下结果：
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` 字段显示该实例收到 I/O 错误 1236。`Master_Log_File` 字段显示文件名为 `mysql-bin-changelog.012345`，这意味着日志文件索引为 `12345`。要纠正该错误，您可以使用以下参数调用 `mysql.rds_next_master_log`：
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log（Aurora MySQL 版本 3）
将源数据库实例日志位置更改为源数据库实例上的下一个二进制日志的开始位置。只有在只读副本上收到复制 I/O 错误 1236 时，才能使用该过程。
### 语法
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### 参数
*curr\$1source\$1log*
当前源日志文件的索引。例如，如果当前文件名为 `mysql-bin-changelog.012345`，则索引为 12345。要确定当前源日志文件名，请运行 `SHOW REPLICA STATUS` 命令并查看 `Source_Log_File` 字段。
### 使用说明
管理用户必须运行 `mysql.rds_next_source_log` 过程。
**警告**
仅在对作为复制源的多可用区数据库实例进行故障转移后复制失败，并且 `mysql.rds_next_source_log` 的 `Last_IO_Errno` 字段报告 I/O 错误 1236 时调用 `SHOW REPLICA STATUS`。
如果在发生失效转移事件之前，源实例中的事务未写入到磁盘上的二进制日志，调用 `mysql.rds_next_source_log` 可能会导致只读副本丢失数据。可以通过将源实例参数 `sync_binlog` 和 `innodb_support_xa` 设置为 `1` 来减少发生这种情况的几率，尽管这可能会降低性能。
### 示例
假设复制在 Aurora MySQL 只读副本上失败。对只读副本运行 `SHOW REPLICA STATUS\G` 会返回以下结果：
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` 字段显示该实例收到 I/O 错误 1236。`Source_Log_File` 字段显示文件名为 `mysql-bin-changelog.012345`，这意味着日志文件索引为 `12345`。要纠正该错误，您可以使用以下参数调用 `mysql.rds_next_source_log`：
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
删除用于 SSL 通信和加密复制的证书颁发机构证书、客户端证书与客户端密钥。此类信息可通过使用 [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 来导入。
### 语法
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master（Aurora MySQL 版本 2）
重新配置 Aurora MySQL 数据库实例，使其不再是在 Amazon RDS 之外运行的某个 MySQL 实例的只读副本。
**重要**
要运行此过程，必须启用 `autocommit`。要启用它，请将 `autocommit` 参数设置为 `1`。有关修改参数的信息，请参阅 [在 Amazon Aurora 中修改数据库参数组中的参数](USER_WorkingWithParamGroups.Modifying.md)。
### 语法
```
CALL mysql.rds_reset_external_master;
```
### 使用说明
主用户必须运行 `mysql.rds_reset_external_master` 过程。此过程必须运行于一个 MySQL 数据库实例上，后者要作为在 Amazon RDS 之外运行的 MySQL 实例的只读副本而被删除。
**注意**
我们提供这些存储过程主要是为了与在 Amazon RDS 外部运行的 MySQL 实例之间启用复制。建议您尽可能使用 Aurora 副本来管理 Aurora MySQL 数据库集群中的复制。有关在 Aurora MySQL 数据库集群中管理复制的信息，请参阅 [使用 Aurora 副本](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)。
想要了解更多有关使用复制从在 Aurora MySQL 之外运行的 MySQL 实例导入数据的信息，请参阅[Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
## mysql.rds\$1reset\$1external\$1source（Aurora MySQL 版本 3）
重新配置 Aurora MySQL 数据库实例，使其不再是在 Amazon RDS 之外运行的某个 MySQL 实例的只读副本。
**重要**
要运行此过程，必须启用 `autocommit`。要启用它，请将 `autocommit` 参数设置为 `1`。有关修改参数的信息，请参阅 [在 Amazon Aurora 中修改数据库参数组中的参数](USER_WorkingWithParamGroups.Modifying.md)。
### 语法
```
CALL mysql.rds_reset_external_source;
```
### 使用说明
管理用户必须运行 `mysql.rds_reset_external_source` 过程。此过程必须运行于一个 MySQL 数据库实例上，后者要作为在 Amazon RDS 之外运行的 MySQL 实例的只读副本而被删除。
**注意**
我们提供这些存储过程主要是为了与在 Amazon RDS 外部运行的 MySQL 实例之间启用复制。建议您尽可能使用 Aurora 副本来管理 Aurora MySQL 数据库集群中的复制。有关在 Aurora MySQL 数据库集群中管理复制的信息，请参阅 [使用 Aurora 副本](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)。
## mysql.rds\$1set\$1binlog\$1source\$1ssl（Aurora MySQL 版本 3）
为二进制日志复制启用 `SOURCE_SSL` 加密。有关更多信息，请参阅 MySQL 文档中的 [CHANGE REPLICATION SOURCE TO statement](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)。
### 语法
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### 参数
*mode*
指示是否启用 `SOURCE_SSL` 加密的值：
+ `0` – `SOURCE_SSL` 加密已禁用。默认值为 `0`。
+ `1` – `SOURCE_SSL` 加密已启用。您可以使用 SSL 或 TLS 配置加密。
### 使用说明
Aurora MySQL 版本 3.06 及更高版本支持该过程。
## mysql.rds\$1set\$1external\$1master（Aurora MySQL 版本 2）
将 Aurora MySQL 数据库实例配置为在 Amazon RDS 之外运行的 MySQL 实例的只读副本。
`mysql.rds_set_external_master` 过程已弃用，并会在将来的版本中删除。请改用 `mysql.rds\$1set\$1external\$1source`。
**重要**
要运行此过程，必须启用 `autocommit`。要启用它，请将 `autocommit` 参数设置为 `1`。有关修改参数的信息，请参阅 [在 Amazon Aurora 中修改数据库参数组中的参数](USER_WorkingWithParamGroups.Modifying.md)。
### 语法
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### 参数
*host\$1name*
在 Amazon RDS 之外运行以变为源数据库实例的 MySQL 实例的主机名或 IP 地址。
*host\$1port*
在 Amazon RDS 之外运行的要配置为源数据库实例的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
*replication\$1user\$1name*
对在 Amazon RDS 外部运行的 MySQL 实例具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的用户的 ID。建议您向专用于复制的账户提供外部实例。
*replication\$1user\$1password*
在 `replication_user_name` 中指定的用户 ID 的密码。
*mysql\$1binary\$1log\$1file\$1name*
源数据库实例上包含复制信息的二进制日志的名称。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` 二进制日志中复制将开始读取复制信息的位置。
您可以通过在源数据库实例上运行 `SHOW MASTER STATUS` 来确定二进制日志文件名和位置。
*ssl\$1encryption*
指定是否在复制连接中使用安全套接字层（SSL）加密的值。1 表示使用 SSL 加密，0 表示不使用加密。默认值为 0。
不支持 `MASTER_SSL_VERIFY_SERVER_CERT` 选项。此选项设置为 0，这意味着连接已加密，但未验证证书。
### 使用说明
主用户必须运行 `mysql.rds_set_external_master` 过程。必须在要配置为在 Amazon RDS 外部运行的 MySQL 实例的只读副本的 MySQL 数据库实例上运行该过程。
运行 `mysql.rds_set_external_master` 之前，您必须先将在 Amazon RDS 之外运行的 MySQL 实例配置为源数据库实例。要连接到在 Amazon RDS 之外运行的 MySQL 实例，您必须指定 `replication_user_name` 和 `replication_user_password` 值，这些值指示对 MySQL 的外部实例具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的复制用户。
**将 MySQL 的外部实例配置为源数据库实例**
1. 通过使用所选的 MySQL 客户端，连接到 MySQL 的外部实例并创建要用于复制的用户账户。示例如下：
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**注意**
作为安全最佳实践，请指定除此处所示提示以外的密码。
1. 对于 MySQL 的外部实例，向复制用户授予 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限。以下示例向您所在域的“repl\$1user”用户授予对所有数据库的 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限。
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
要使用加密复制，请将源数据库实例配置为使用 SSL 连接。此外，使用 [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 过程，将证书颁发机构证书、客户端证书和客户端密钥导入到数据库实例或数据库集群中。
**注意**
我们提供这些存储过程主要是为了与在 Amazon RDS 外部运行的 MySQL 实例之间启用复制。建议您尽可能使用 Aurora 副本来管理 Aurora MySQL 数据库集群中的复制。有关在 Aurora MySQL 数据库集群中管理复制的信息，请参阅 [使用 Aurora 副本](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)。
在调用 `mysql.rds_set_external_master` 将 Amazon RDS 数据库实例配置为只读副本后，可对该只读副本调用 [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) 开始复制过程。您可以调用 [mysql.rds\$1reset\$1external\$1master（Aurora MySQL 版本 2）](#mysql_rds_reset_external_master) 删除只读副本配置。
调用 `mysql.rds_set_external_master` 时，Amazon RDS 将时间、用户和 `set master` 的操作记录在 `mysql.rds_history` 和 `mysql.rds_replication_status` 表中。
### 示例
在 MySQL 数据库实例上运行时，下例将该数据库实例配置为在 Amazon RDS 之外运行的某个 MySQL 实例的只读副本。
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source（Aurora MySQL 版本 3）
将 Aurora MySQL 数据库实例配置为在 Amazon RDS 之外运行的 MySQL 实例的只读副本。
**重要**
要运行此过程，必须启用 `autocommit`。要启用它，请将 `autocommit` 参数设置为 `1`。有关修改参数的信息，请参阅 [在 Amazon Aurora 中修改数据库参数组中的参数](USER_WorkingWithParamGroups.Modifying.md)。
### 语法
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### 参数
*host\$1name*
在 Amazon RDS 之外运行以变为源数据库实例的 MySQL 实例的主机名或 IP 地址。
*host\$1port*
在 Amazon RDS 之外运行的要配置为源数据库实例的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
*replication\$1user\$1name*
对在 Amazon RDS 外部运行的 MySQL 实例具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的用户的 ID。建议您向专用于复制的账户提供外部实例。
*replication\$1user\$1password*
在 `replication_user_name` 中指定的用户 ID 的密码。
*mysql\$1binary\$1log\$1file\$1name*
源数据库实例上包含复制信息的二进制日志的名称。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` 二进制日志中复制将开始读取复制信息的位置。
您可以通过在源数据库实例上运行 `SHOW MASTER STATUS` 来确定二进制日志文件名和位置。
*ssl\$1encryption*
指定是否在复制连接中使用安全套接字层（SSL）加密的值。1 表示使用 SSL 加密，0 表示不使用加密。默认值是 0。
要启用此选项，您必须已使用 [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 导入自定义 SSL 证书。如果您尚未导入自定义 SSL 证书，请将此参数设置为 0，然后使用 [mysql.rds\$1set\$1binlog\$1source\$1ssl（Aurora MySQL 版本 3）](#mysql_rds_set_binlog_source_ssl)启用 SSL 以进行二进制日志复制。
不支持 `SOURCE_SSL_VERIFY_SERVER_CERT` 选项。此选项设置为 0，这意味着连接已加密，但未验证证书。
### 使用说明
管理用户必须运行 `mysql.rds_set_external_source` 过程。该过程必须在以下 Aurora MySQL 数据库实例上运行：也即，该实例将配置为在 Amazon RDS 外部运行的 MySQL 实例的只读副本。
运行 `mysql.rds_set_external_source` 之前，必须先将在 Amazon RDS 之外运行的 MySQL 实例配置为源数据库实例。要连接到在 Amazon RDS 之外运行的 MySQL 实例，您必须指定 `replication_user_name` 和 `replication_user_password` 值，这些值指示对 MySQL 的外部实例具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的复制用户。
**将 MySQL 的外部实例配置为源数据库实例**
1. 通过使用所选的 MySQL 客户端，连接到 MySQL 的外部实例并创建要用于复制的用户账户。示例如下：
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注意**
作为安全最佳实践，请指定除此处所示提示以外的密码。
1. 对于 MySQL 的外部实例，向复制用户授予 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限。以下示例向您所在域的“repl\$1user”用户授予对所有数据库的 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
要使用加密复制，请将源数据库实例配置为使用 SSL 连接。此外，使用 [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) 过程，将证书颁发机构证书、客户端证书和客户端密钥导入到数据库实例或数据库集群中。
**注意**
我们提供这些存储过程主要是为了与在 Amazon RDS 外部运行的 MySQL 实例之间启用复制。建议您尽可能使用 Aurora 副本来管理 Aurora MySQL 数据库集群中的复制。有关在 Aurora MySQL 数据库集群中管理复制的信息，请参阅 [使用 Aurora 副本](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)。
在调用 `mysql.rds_set_external_source` 将 Aurora MySQL 数据库实例配置为只读副本后，可对该只读副本调用 [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) 以开始复制过程。您可以调用 [mysql.rds\$1reset\$1external\$1source（Aurora MySQL 版本 3）](#mysql_rds_reset_external_source) 来删除只读副本配置。
调用 `mysql.rds_set_external_source` 时，Amazon RDS 将时间、用户和 `set master` 的操作记录在 `mysql.rds_history` 和 `mysql.rds_replication_status` 表中。
### 示例
在 Aurora MySQL 数据库实例上运行时，以下示例将该数据库实例配置为在 Amazon RDS 外部运行的某个 MySQL 实例的只读副本。
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position（Aurora MySQL 版本 2）
将 Aurora MySQL 主实例配置为接受来自外部 MySQL 实例的传入复制。此过程还会根据全局事务标识符 (GTID) 配置复制。
此过程不会配置延迟复制，因为 Aurora MySQL 不支持延迟复制。
### 语法
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### 参数
*host\$1name*
在 Aurora 之外运行以变为复制源的 MySQL 实例的主机名或 IP 地址。
*host\$1port*
在 Aurora 之外运行的要配置为复制源的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
*replication\$1user\$1name*
在对 Aurora 外部运行的 MySQL 实例上具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的用户的 ID。建议您向专用于复制的账户提供外部实例。
*replication\$1user\$1password*
在 `replication_user_name` 中指定的用户 ID 的密码。
*ssl\$1encryption*
目前未实施该选项。默认值是 0。
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
主用户必须运行 `mysql.rds_set_external_master_with_auto_position` 过程。主用户在充当复制目标的 Aurora MySQL 数据库集群的主实例上运行此过程。这可能是外部 MySQL 数据库实例或 Aurora MySQL 数据库集群的复制目标。
Aurora MySQL 版本 2 支持该过程。对于 Aurora MySQL 版本 3，请改为使用程序 [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position（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 实例配置为复制源**
1. 通过使用所选的 MySQL 客户端，连接到外部 MySQL 实例并创建要用于复制的用户账户。以下是示例。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. 在外部 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\$1skip\$1transaction\$1with\$1gtid（Aurora MySQL 版本 2 和 3）](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) 存储过程。有关使用基于 GTID 的复制的更多信息，请参阅[使用基于 GTID 的复制](mysql-replication-gtid.md)。
### 示例
在 Aurora 主实例上运行时，以下示例将 Aurora 集群配置为充当在 Aurora 之外运行的某个 MySQL 实例的只读副本。
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position（Aurora MySQL 版本 3）
将 Aurora MySQL 主实例配置为接受来自外部 MySQL 实例的传入复制。此过程还会根据全局事务标识符 (GTID) 配置复制。
### 语法
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### 参数
*host\$1name*
在 Aurora 之外运行以变为复制源的 MySQL 实例的主机名或 IP 地址。
*host\$1port*
在 Aurora 之外运行的要配置为复制源的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制，请指定由 SSH 公开的端口号。
*replication\$1user\$1name*
在对 Aurora 外部运行的 MySQL 实例上具有 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的用户的 ID。建议您向专用于复制的账户提供外部实例。
*replication\$1user\$1password*
在 `replication_user_name` 中指定的用户 ID 的密码。
*ssl\$1encryption*
目前未实施该选项。默认值是 0。
使用 [mysql.rds\$1set\$1binlog\$1source\$1ssl（Aurora MySQL 版本 3）](#mysql_rds_set_binlog_source_ssl)启用 SSL 以进行二进制日志复制。
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
管理用户必须运行 `mysql.rds_set_external_source_with_auto_position` 过程。管理用户在充当复制目标的 Aurora MySQL 数据库集群的主实例上运行此过程。这可能是外部 MySQL 数据库实例或 Aurora MySQL 数据库集群的复制目标。
仅 Aurora MySQL 版本 3 支持此过程。此过程不会配置延迟复制，因为 Aurora MySQL 不支持延迟复制。
在运行 `mysql.rds_set_external_source_with_auto_position` 前，请将外部 MySQL 数据库实例配置为复制源。要连接到外部 MySQL 实例，应指定 `replication_user_name` 和 `replication_user_password` 值。这些值必须指示具有外部 MySQL 实例上的 `REPLICATION CLIENT` 和 `REPLICATION SLAVE` 权限的复制用户。
**要将外部 MySQL 实例配置为复制源**
1. 通过使用所选的 MySQL 客户端，连接到外部 MySQL 实例并创建要用于复制的用户账户。以下是示例。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
1. 在外部 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\$1skip\$1transaction\$1with\$1gtid（Aurora MySQL 版本 2 和 3）](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) 存储过程。有关使用基于 GTID 的复制的更多信息，请参阅[使用基于 GTID 的复制](mysql-replication-gtid.md)。
### 示例
在 Aurora 主实例上运行时，以下示例将 Aurora 集群配置为充当在 Aurora 之外运行的某个 MySQL 实例的只读副本。
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position（Aurora MySQL 版本 2）
将复制模式设置为基于二进制日志文件位置或全局事务标识符 (GTID)。
### 语法
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### 参数
*auto\$1position\$1mode*
该值指示是使用日志文件位置复制还是基于 GTID 的复制：
+ `0` – 使用基于二进制日志文件位置的复制方法。默认为 `0`。
+ `1` – 使用基于 GTID 的复制方法。
### 使用说明
主用户必须运行 `mysql.rds_set_master_auto_position` 过程。
Aurora MySQL 版本 2 支持此过程。
## mysql.rds\$1set\$1read\$1only（Aurora MySQL 版本 3）
为数据库实例全局开启或关闭 `read_only` 模式。
### 语法
```
CALL mysql.rds_set_read_only(mode);
```
### 参数
*mode*
指示是否为数据库实例全局启用 `read_only` 模式的值：
+ `0` – `OFF`。默认值为 `0`。
+ `1` – `ON`
### 使用说明
`mysql.rds_set_read_only` 存储过程仅修改 `read_only` 参数。无法在读取器数据库实例上更改 `innodb_read_only` 参数。
`read_only` 参数更改在重启时不会保留。要对 `read_only` 进行永久更改，必须使用 `read_only` 数据库集群参数。
Aurora MySQL 版本 3.06 及更高版本支持此过程。
## mysql.rds\$1set\$1session\$1binlog\$1format（Aurora MySQL 版本 2）
设置当前会话的二进制日志格式。
### 语法
```
CALL mysql.rds_set_session_binlog_format(format);
```
### 参数
*format*
一个表示当前会话的二进制日志格式的值：
+ `STATEMENT` – 复制源基于 SQL 语句将事件写入二进制日志。
+ `ROW` – 复制源将事件写入二进制日志，指示各个表行发生更改。
+ `MIXED` – 日志记录通常基于 SQL 语句，但在某些条件下切换到行。有关更多信息，请参阅 MySQL 文档中的[混合二进制日志记录格式](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html)。
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
要使用此存储过程，必须为当前会话配置二进制日志记录。
对于 Aurora，Aurora MySQL 版本 2.12 及更高的与 MySQL 5.7 兼容的版本支持此过程。
## mysql.rds\$1set\$1source\$1auto\$1position（Aurora MySQL 版本 3）
将复制模式设置为基于二进制日志文件位置或全局事务标识符 (GTID)。
### 语法
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### 参数
*auto\$1position\$1mode*
该值指示是使用日志文件位置复制还是基于 GTID 的复制：
+ `0` – 使用基于二进制日志文件位置的复制方法。默认为 `0`。
+ `1` – 使用基于 GTID 的复制方法。
### 使用说明
对于 Aurora MySQL 数据库集群，您将在连接到主实例时调用此存储过程。
管理用户必须运行 `mysql.rds_set_source_auto_position` 过程。
## mysql.rds\$1skip\$1repl\$1error
跳过并删除 MySQL 数据库只读副本上的复制错误。
### 语法
```
CALL mysql.rds_skip_repl_error;
```
### 使用说明
主用户必须对只读副本运行 `mysql.rds_skip_repl_error` 过程。有关此过程的更多信息，请参阅[跳过当前的复制错误](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError)。
要确定是否存在错误，请运行 MySQL `SHOW REPLICA STATUS\G` 命令。如果复制错误不太严重，您可以运行 `mysql.rds_skip_repl_error` 以跳过该错误。如果有多个错误，`mysql.rds_skip_repl_error` 会删除第一个错误，并警告存在其他错误。然后，您可以使用 `SHOW REPLICA STATUS\G` 确定要对下一个错误采取的适当操作。有关返回的值的信息，请参阅 MySQL 文档中的 [SHOW REPLICA STATUS 语法](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html)。
有关解决 Aurora MySQL 的复制错误的信息，请参阅[诊断并解决 MySQL 读取复制故障](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR)。
#### 复制已停止错误
调用 `mysql.rds_skip_repl_error` 过程时，您可能会收到一条错误消息，指出副本已关闭或禁用。
如果您对于主实例而不是只读副本运行该过程，则会出现此错误消息。您必须对只读副本运行此过程，该过程才能正常运行。
如果您对只读副本运行该过程，但无法成功重新启动复制，也可能会出现此错误消息。
如果您需要跳过大量错误，复制滞后时间可能会超出二进制日志 (binlog) 文件的默认保留期。在这种情况下，您可能会遇到一个因二进制日志文件在只读副本上进行重放之前被清除而引发的严重错误。此清除会导致复制停止，而您将无法再调用 `mysql.rds_skip_repl_error` 命令以跳过复制错误。
您可以增加在源数据库实例上保留 binlog 文件的小时数以缓解该问题。在增加二进制日志保留时间后，您可以重新启动复制进程，并根据需要调用 `mysql.rds_skip_repl_error` 命令。
要设置 binlog 保留时间，请使用 [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) 过程，并指定 `'binlog retention hours'` 配置参数以及在数据库集群上保留 binlog 文件的小时数。以下示例将 binlog 文件的保留期设置为 48 个小时。
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
从 Aurora MySQL 数据库集群发起复制。
**注意**
您可以使用 [mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）](#mysql_rds_start_replication_until) 或 [mysql.rds\$1start\$1replication\$1until\$1gtid（Aurora MySQL 版本 3）](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) 存储过程从 Aurora MySQL 数据库实例中启动复制，并在指定的二进制日志文件位置停止复制。
### 语法
```
CALL mysql.rds_start_replication;
```
### 使用说明
主用户必须运行 `mysql.rds_start_replication` 过程。
要从 Amazon RDS 外部的 MySQL 实例导入数据，请在调用 [mysql.rds\$1set\$1external\$1master（Aurora MySQL 版本 2）](#mysql_rds_set_external_master) 或 [mysql.rds\$1set\$1external\$1source（Aurora MySQL 版本 3）](#mysql_rds_set_external_source) 以构建复制配置后，再对只读副本调用 `mysql.rds_start_replication` 以开始复制过程。有关更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
要将数据导出到 Amazon RDS 外部的 MySQL 实例，请对只读副本调用 `mysql.rds_start_replication` 和 `mysql.rds_stop_replication` 以控制某些复制操作，如清除二进制日志。有关更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
您还可以对只读副本调用 `mysql.rds_start_replication`，以便重新启动您先前通过调用 `mysql.rds_stop_replication` 停止的任何复制过程。有关更多信息，请参阅 [复制已停止错误](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped)。
## mysql.rds\$1start\$1replication\$1until（Aurora MySQL 版本 3）
从 Aurora MySQL 数据库集群发起复制，并在指定的二进制日志文件位置停止复制。
### 语法
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### 参数
*replication\$1log\$1file*
源数据库实例上包含复制信息的二进制日志的名称。
*replication\$1stop\$1point *
`replication_log_file` 二进制日志中复制将停止的位置。
### 使用说明
主用户必须运行 `mysql.rds_start_replication_until` 过程。
Aurora MySQL 版本 3.04 及更高版本支持该过程。
托管式复制不支持 `mysql.rds_start_replication_until` 存储过程，其中包括以下内容：
+ [跨 AWS 区域复制 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Replication.CrossRegion.md)
+ [使用 Aurora 只读副本将数据从 RDS for MySQL 数据库实例迁移到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
为 `replication_log_file` 参数指定的文件名必须与源数据库实例二进制日志文件名匹配。
当 `replication_stop_point` 参数指定位于过去的某个停止位置时，即会立即停止复制。
### 示例
以下示例将启动复制并复制更改，直到它到达 `120` 二进制日志文件中的 `mysql-bin-changelog.000777` 位置。
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
停止从 MySQL 数据库实例中进行复制。
### 语法
```
CALL mysql.rds_stop_replication;
```
### 使用说明
主用户必须运行 `mysql.rds_stop_replication` 过程。
如果要配置复制，使其从在 Amazon RDS 外部运行的 MySQL 实例导入数据，则要在导入完成后，再对只读副本调用 `mysql.rds_stop_replication` 以停止复制过程。有关更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
如果要配置复制，使其将数据导出到在 Amazon RDS 外部运行的 MySQL 实例，则要对只读副本调用 `mysql.rds_start_replication` 和 `mysql.rds_stop_replication` 以控制某些复制操作，如清除二进制日志。有关更多信息，请参阅 [Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）](AuroraMySQL.Replication.MySQL.md)。
托管式复制不支持 `mysql.rds_stop_replication` 存储过程，其中包括以下内容：
+ [跨 AWS 区域复制 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Replication.CrossRegion.md)
+ [使用 Aurora 只读副本将数据从 RDS for MySQL 数据库实例迁移到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# 结束会话或查询
以下存储过程结束会话或查询。
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
结束与 MySQL 服务器的连接。
### 语法
```
CALL mysql.rds_kill(processID);
```
### 参数
*processID*
要结束的连接线程的标识。
### 使用说明
与 MySQL 服务器的每个连接在单独的线程中运行。要结束连接，请使用 `mysql.rds_kill` 过程并传入该连接的线程 ID。要获取线程 ID，请使用 MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) 命令。
### 示例
以下示例结束线程 ID 为 4243 的连接：
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
结束针对 MySQL 服务器运行的查询。
### 语法
```
CALL mysql.rds_kill_query(processID);
```
### 参数
*processID*
运行正要结束的查询的进程或线程的身份。
### 使用说明
要停止针对 MySQL 服务器运行的查询，请使用 `mysql_rds_kill_query` 过程并传入正在运行查询的线程的连接 ID。然后，该过程将终止连接。
要获取 ID，请查询 MySQL [INFORMATION\$1SCHEMA PROCESSLIST 表](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html)或使用 MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) 命令。`SHOW PROCESSLIST` 或 `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` 中 ID 列的值为 *processID*。
### 示例
以下示例停止查询线程 ID 为 230040 的查询：
```
CALL mysql.rds_kill_query(230040);
```
# 使用 GTID 复制事务
以下存储过程控制如何使用 Aurora MySQL 中的全局事务标识符（GTID）复制事务。要了解如何根据 Aurora MySQL 中的 GTID 使用复制，请参阅[使用基于 GTID 的复制](mysql-replication-gtid.md)。
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions（Aurora MySQL 版本 3）](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged（Aurora MySQL 版本 3）](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid（Aurora MySQL 版本 2 和 3）](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid（Aurora MySQL 版本 3）](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions（Aurora MySQL 版本 3）
配置 `CHANGE REPLICATION SOURCE TO` 语句的 `ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS` 选项。它使得复制通道将 GTID 分配给没有 GTID 的复制事务。这样，您就可以将二进制日志从不使用基于 GTID 的复制的源复制到使用该复制的副本。有关更多信息，请参阅 *MySQL 参考手册*中的 [CHANGE REPLICATION SOURCE TO 语句](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)和[从没有 GTID 的源复制到有 GTID 的副本](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html)。
### 语法
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### 参数
*gtid\$1option*
字符串值。允许的值为 `OFF`、`LOCAL` 或者指定的 UUID。
### 使用说明
此过程与在社群 MySQL 中发布语句 `CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option` 的效果相同。
GTID 必须转向 `ON` 才能使 *gtid\$1option* 设置为 `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\$1gtid\$1purged（Aurora MySQL 版本 3）
将系统变量 `gtid_purged` 的全局值设置为给定的全局事务标识符（GTID）集。`gtid_purged` 系统变量是一个 GTID 集，由服务器上已提交但不存在于服务器上任何二进制日志文件中的所有事务的 GTID 组成。
为了与 MySQL 8.0 兼容，有两种方法可以设置 `gtid_purged` 的值：
+ 将 `gtid_purged` 的值替换为指定的 GTID 集。
+ 将您指定的 GTID 集附加到 `gtid_purged` 已经包含的 GTID 集。
### 语法
要将 `gtid_purged` 的值替换为您指定的 GTID 集，请执行以下操作：
```
CALL mysql.rds_gtid_purged (gtid_set);
```
要将 `gtid_purged` 的值附加到您指定的 GTID 集，请执行以下操作：
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### 参数
*gtid\$1set*
*gtid\$1set* 的值必须是 `gtid_purged` 的当前值的超集，并且不能与 `gtid_subtract(gtid_executed,gtid_purged)` 相交。也就是说，新的 GTID 集必须包括 `gtid_purged` 中已经存在的任何 GTID，并且不能包括 `gtid_executed` 中尚未清除的任何 GTID。*gtid\$1set* 参数也不能包括全局 `gtid_owned` 集中的任何 GTID，即当前服务器上正在处理的事务的 GTID。
### 使用说明
主用户必须运行 `mysql.rds_gtid_purged` 过程。
Aurora MySQL 版本 3.04 及更高版本支持此过程。
### 示例
以下示例将 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` 分配给 `gtid_purged` 全局变量。
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid（Aurora MySQL 版本 2 和 3）
在 Aurora 主实例上跳过复制具有指定全局事务标识符 (GTID) 的事务。
在已知特定 GTID 事务导致问题时，您可以使用该过程进行灾难恢复。请使用该存储过程跳过有问题的事务。有问题的事务示例包括禁用复制、删除重要数据或导致数据库实例变得不可用的事务。
### 语法
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### 参数
*gtid\$1to\$1skip*
要跳过的复制事务的 GTID。
### 使用说明
主用户必须运行 `mysql.rds_skip_transaction_with_gtid` 过程。
Aurora MySQL 版本 2 和 3 支持此过程。
### 示例
以下示例将跳过复制具有 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` 的事务。
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid（Aurora MySQL 版本 3）
从 Aurora MySQL 数据库集群中启动复制，并在指定的全局事务标识符（GTID）后面立即停止复制。
### 语法
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### 参数
*gtid*
停止复制前的 GTID。
### 使用说明
主用户必须运行 `mysql.rds_start_replication_until_gtid` 过程。
Aurora MySQL 版本 3.04 及更高版本支持该过程。
托管式复制不支持 `mysql.rds_start_replication_until_gtid` 存储过程，其中包括以下内容：
+ [跨 AWS 区域复制 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Replication.CrossRegion.md)
+ [使用 Aurora 只读副本将数据从 RDS for MySQL 数据库实例迁移到 Amazon Aurora MySQL 数据库集群](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
在 `gtid` 参数指定副本已运行的事务时，将会立即停止复制。
### 示例
以下示例启动复制并复制更改，直至到达 GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`。
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# 轮换查询日志
以下存储过程将 MySQL 日志交替到备份表。有关更多信息，请参阅 [AuroraMySQL 数据库日志文件](USER_LogAccess.Concepts.MySQL.md)。
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
将 `mysql.general_log` 表轮换到备份表。
### 语法
```
CALL mysql.rds_rotate_general_log;
```
### 使用说明
您可以通过调用 `mysql.general_log` 过程将 `mysql.rds_rotate_general_log` 表轮换到备份表。轮换日志表时，会将当前日志表复制到备份日志表，随后删除当前日志表中的条目。如果备份日志表已存在，则先将其删除，然后将当前日志表复制到备份。如果需要，您可以查询备份日志表。`mysql.general_log` 表的备份日志表名为 `mysql.general_log_backup`。
只有当 `log_output` 参数设置为 `TABLE` 时，您才能运行此过程。
## mysql.rds\$1rotate\$1slow\$1log
将 `mysql.slow_log` 表轮换到备份表。
### 语法
```
CALL mysql.rds_rotate_slow_log;
```
### 使用说明
您可以通过调用 `mysql.slow_log` 过程将 `mysql.rds_rotate_slow_log` 表轮换到备份表。轮换日志表时，会将当前日志表复制到备份日志表，随后删除当前日志表中的条目。如果备份日志表已存在，则先将其删除，然后将当前日志表复制到备份。
如果需要，您可以查询备份日志表。`mysql.slow_log` 表的备份日志表名为 `mysql.slow_log_backup`。
# 设置和显示二进制日志配置
以下存储过程设置和显示配置参数，例如用于二进制日志文件保留。
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
指定要保留二进制日志的小时数或要延迟复制的秒数。
### 语法
```
CALL mysql.rds_set_configuration(name,value);
```
### 参数
*name*
要设置的配置参数的名称。
*值*
配置参数的值。
### 使用说明
`mysql.rds_set_configuration` 过程支持以下配置参数：
+ [二进制日志保留小时数](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
配置参数将永久存储，可在任何数据库实例重启或失效转移后继续使用。
#### 二进制日志保留小时数
`binlog retention hours` 参数用于指定要保留二进制日志文件的小时数。Amazon Aurora 通常会尽快清除一个二进制日志，但对于 Amazon 外部的 MySQL 数据库的复制，该二进制日志可能仍是必需的。
`binlog retention hours` 的默认值为 `NULL`。对于 Aurora MySQL，`NULL` 表示延时清理二进制日志。Aurora MySQL 二进制日志可能会在系统中保留一段时间，但这通常不超过一天。
要指定在数据库集群上保留二进制日志的小时数，请使用 `mysql.rds_set_configuration` 存储过程并指定足以让复制发生的时段，如以下示例中所示。
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**注意**
不能将值 `0` 用于 `binlog retention hours`。
对于 Aurora MySQL 版本 2.11.0 及更高版本和版本 3 数据库集群，最大 `binlog retention hours` 值为 2160（90 天）。
在设置保留期后，监视数据库实例的存储用量以确认保留的二进制日志不会占用太多存储空间。
## mysql.rds\$1show\$1configuration
保留二进制日志的小时数。
### 语法
```
CALL mysql.rds_show_configuration;
```
### 使用说明
要验证 Amazon RDS 保留二进制日志的小时数，请使用 `mysql.rds_show_configuration` 存储过程。
### 示例
以下示例显示了保留期：
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Aurora MySQL 特定的 information\$1schema 表
Aurora MySQL 有一些特定于 Aurora 的 `information_schema` 表。
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
`information_schema.aurora_global_db_instance_status` 表包含有关全局数据库主数据库集群和辅助数据库集群中所有数据库实例状态的信息。下表显示了您可以使用的列。其余列仅供 Aurora 内部使用。
**注意**
此信息模式表仅适用于 Aurora MySQL 版本 3.04.0 及更高版本的全局数据库。
| 列 | 数据类型 | 描述 |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | 数据库实例的标识符。 |
| SESSION\$1ID | varchar(100) | 当前会话的唯一标识符。MASTER\$1SESSION\$1ID 的值标识写入器（主要）数据库实例。 |
| AWS\$1REGION | varchar(100) | 运行此全局数据库实例的 AWS 区域。有关区域列表，请参阅[区域可用性](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)。 |
| DURABLE\$1LSN | bigint unsigned | 在存储中变得持久的日志序列号（LSN）。日志序列号 (LSN) 是标识数据库事务日志中的记录的唯一序列号。对 LSN 进行排序，以便较大的 LSN 表示较晚的事务。 |
| HIGHEST\$1LSN\$1RCVD | bigint unsigned | 数据库实例从写入器数据库实例收到的最高 LSN。 |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | 写入器数据库实例可以清除到的最早事务的 ID。 |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | 数据库实例从存储中读取所用的最早 LSN。 |
| VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | 对于主数据库集群中的读取器，此数据库实例滞后于写入器数据库实例的时间（以毫秒为单位）。对于辅助数据库集群中的读取器，此数据库实例滞后于辅助卷的时间（以毫秒为单位）。 |
## information\$1schema.aurora\$1global\$1db\$1status
`information_schema.aurora_global_db_status` 表包含有关 Aurora 全局数据库滞后各方面的信息，特别是底层 Aurora 存储的滞后（所谓持久性滞后）以及恢复点目标（RPO）之间的滞后。下表显示了您可以使用的列。其余列仅供 Aurora 内部使用。
**注意**
此信息模式表仅适用于 Aurora MySQL 版本 3.04.0 及更高版本的全局数据库。
| 列 | 数据类型 | 描述 |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | 运行此全局数据库实例的 AWS 区域。有关区域列表，请参阅[区域可用性](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)。 |
| HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | 此数据库集群上当前存在的最高日志序列号（LSN）。日志序列号 (LSN) 是标识数据库事务日志中的记录的唯一序列号。对 LSN 进行排序，以便较大的 LSN 表示较晚的事务。 |
| DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | 辅助数据库集群上的 HIGHEST\$1LSN\$1WRITTEN 与主数据库集群上的 HIGHEST\$1LSN\$1WRITTEN 之间的时间戳值差异。在 Aurora 全局数据库的主数据库集群上，该值始终为 0。 |
| RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | 恢复点目标（RPO）滞后。RPO 滞后是最近的用户事务在存储在 Aurora 全局数据库的主数据库集群上之后，执行 COMMIT 操作以便存储在辅助数据库集群上所需的时间。在 Aurora 全局数据库的主数据库集群上，该值始终为 0。 简而言之，该指标计算 Aurora 全局数据库中每个 Aurora MySQL 数据库集群的恢复点目标，也就是说，如果发生中断，可能会丢失多少数据。与滞后一样，RPO 是按时间计量的。 |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | 指定上次为 DURABILITY\$1LAG\$1IN\$1MILLISECONDS 和 RPO\$1LAG\$1IN\$1MILLISECONDS 计算值的时间的时间戳。时间值（如 1970-01-01 00:00:00\$100）表示这是主数据库集群。 |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | 写入器数据库实例可以清除到的最早事务的 ID。 |
## information\$1schema.replica\$1host\$1status
`information_schema.replica_host_status` 表包含复制信息。您可以使用的列如下表所示。其余列仅供 Aurora 内部使用。
| 列 | 数据类型 | 描述 |
| --- | --- | --- |
| CPU | double | 副本主机的 CPU 使用百分比。 |
| IS\$1CURRENT | tinyint | 副本是否为最新副本。 |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | 上次更新发生的时间。用于确定记录是否过时。 |
| REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | 副本滞后，以毫秒为单位。 |
| SERVER\$1ID | varchar(100) | 数据库服务器的 ID。 |
| SESSION\$1ID | varchar(100) | 数据库会话的 ID。用于确定数据库实例是写入器实例还是读取器实例。 |
**注意**
当副本实例滞后时，从其 `information_schema.replica_host_status` 表中查询到的信息可能已过时。在这种情况下，我们建议您改为从写入器实例进行查询。
虽然 `mysql.ro_replica_status` 表具有相似的信息，但我们不建议使用它。
## information\$1schema.aurora\$1forwarding\$1processlist
`information_schema.aurora_forwarding_processlist` 表包含有关写入转发所涉及的进程的信息。
此表的内容仅在开启全局或集群内写入转发的数据库集群的写入器数据库实例上可见。读取器数据库实例上返回一个空的结果集。
| 字段 | 数据类型 | 描述 |
| --- | --- | --- |
| ID | bigint | 写入器数据库实例上连接的标识符。该标识符与 SHOW PROCESSLIST 语句的 Id 列中显示的值相同，并由线程中的 CONNECTION\$1ID() 函数返回。 |
| USER | varchar(32) | 发出语句的 MySQL 用户。 |
| HOST | varchar(255) | 发出语句的 MySQL 客户端。对于转发的语句，此字段显示在转发读取器数据库实例上建立连接的应用程序客户端主机地址。 |
| DB | varchar(64) | 线程的原定设置数据库。 |
| COMMAND | varchar(16) | 线程代表客户端执行的命令的类型，或者，如果会话空闲，则为 Sleep。有关线程命令的描述，请参阅 MySQL 文档中有关[线程命令值](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html)的部分。 |
| TIME | int | 线程处于其当前状态的时间（以秒为单位）。 |
| STATE | varchar(64) | 指示线程正在做什么的操作、事件或状态。有关状态值的描述，请参阅 MySQL 文档中的[常规线程状态](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html)。 |
| 信息 | longtext | 线程正在执行的语句，或者，如果线程未执行语句，则为 NULL。该语句可能是发送到服务器的语句，或者，如果该语句执行其他语句，则为最内层的语句。 |
| IS\$1FORWARDED | bigint | 表示线程是不是从读取器数据库实例转发的。 |
| REPLICA\$1SESSION\$1ID | bigint | Aurora 副本上的连接标识符。该标识符与转发 Aurora 读取器数据库实例上 SHOW PROCESSLIST 语句的 Id 列中显示的值相同。 |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varchar(64) | 转发线程的数据库实例标识符。 |
| REPLICA\$1CLUSTER\$1NAME | varchar(64) | 转发线程的数据库集群标识符。对于集群内写入转发，此标识符与写入器数据库实例的数据库集群相同。 |
| REPLICA\$1REGION | varchar(64) | 转发线程源自的 AWS 区域。对于集群内写入转发，此区域与写入器数据库实例的 AWS 区域相同。 |