Amazon Aurora MySQL 参考 - Amazon Aurora
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 AWS 服务入门

Amazon Aurora MySQL 参考

此参考包括有关 Aurora MySQL 参数、状态变量和常规 SQL 扩展或与社区 MySQL 数据库引擎的差异的信息。

Aurora MySQL 参数

您可以使用数据库参数组中的参数按照与管理其他 Amazon RDS 数据库实例相同的方法管理 Amazon Aurora MySQL 数据库集群。Amazon Aurora 不同于其他数据库引擎,因为您具有一个包含多个数据库实例的数据库集群。因此,您用于管理 Aurora MySQL 数据库集群的有些参数将应用于整个集群。其他参数则仅应用于数据库集群中的特定数据库实例。

要管理集群级参数,请使用数据库集群参数组。要管理实例级参数,请使用数据库参数组。Aurora MySQL 数据库集群中的每个数据库实例均与 MySQL 数据库引擎兼容。不过,您在集群级别应用某些 MySQL 数据库引擎参数,并使用数据库集群参数组管理这些参数。您无法在 Aurora 数据库集群中实例的数据库参数组中查找集群级参数。本主题后面提供了集群级参数的列表。

您可以使用 AWS 管理控制台、AWS CLI 或 Amazon RDS API 管理集群级参数和实例级参数。您可以使用单独的命令管理集群级参数和实例级参数。例如,您可以使用 modify-db-cluster-parameter-group CLI 命令来管理数据库集群参数组中的集群级参数。您可以使用 modify-db-parameter-group CLI 命令来为数据库集群中的数据库实例管理数据库参数组中的实例级参数。

您可以在控制台中或者使用 CLI 或 RDS API 查看集群级别和实例级别的参数。例如,您可以使用 describe-db-cluster-parameters AWS CLI 命令来查看数据库集群参数组中的集群级参数。您可以使用 describe-db-parameters CLI 命令来查看数据库集群中数据库实例的数据库参数组中的实例级参数。

有关数据库参数组的更多信息,请参阅 使用数据库参数组和数据库集群参数组。有关 Aurora Serverless 集群的规则和限制,请参阅Aurora Serverless 和参数组

集群级参数

下表显示了适用于整个 Aurora MySQL 数据库集群的所有参数。

参数名称 可修改 备注

aurora_binlog_read_buffer_size

仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息,请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

aurora_binlog_replication_max_yield_seconds

仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息,请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

aurora_binlog_use_large_read_buffer

仅影响使用二进制日志 (binlog) 复制的集群。有关二进制日志复制的信息,请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

aurora_enable_replica_log_compression

不适用于作为 Aurora 全局数据库的一部分的集群。

aurora_enable_repl_bin_log_filtering

不适用于作为 Aurora 全局数据库的一部分的集群。

aurora_enable_zdr

有关更多信息,请参阅Amazon Aurora MySQL 复制的高可用性注意事项

aurora_load_from_s3_role

有关更多信息,请参阅将数据从 Amazon S3 存储桶中的文本文件加载到 Amazon Aurora MySQL 数据库集群

aurora_select_into_s3_role

有关更多信息,请参阅将数据从 Amazon Aurora MySQL 数据库集群保存到 Amazon S3 存储桶中的文本文件

auto_increment_increment

auto_increment_offset

aws_default_lambda_role

有关更多信息,请参阅从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数

aws_default_s3_role

binlog_checksum

binlog_format

有关更多信息,请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

binlog_row_image

binlog_rows_query_log_events

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 存储引擎。

innodb_autoinc_lock_mode

innodb_checksums

innodb_cmp_per_index_enabled

innodb_commit_concurrency

innodb_data_home_dir

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

innodb_file_per_table

innodb_flush_log_at_trx_commit

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_purge_batch_size

innodb_purge_threads

innodb_rollback_on_timeout

innodb_rollback_segments

innodb_spin_wait_delay

innodb_strict_mode

innodb_support_xa

innodb_sync_array_size

innodb_sync_spin_loops

innodb_table_locks

innodb_undo_directory

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

innodb_undo_logs

innodb_undo_tablespaces

lc_time_names

lower_case_table_names

master-info-repository

master_verify_checksum

require_secure_transport

有关更多信息,请参阅 将 SSL/TLS 与 Aurora MySQL 数据库集群配合使用

server_audit_events

server_audit_excl_users

server_audit_incl_users

server_audit_logging

有关将日志上传到 Amazon CloudWatch Logs 的说明,请参阅将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs

server_id

skip-character-set-client-handshake

skip_name_resolve

sync_frm

time_zone

实例级参数

下表显示了适用于 Aurora MySQL 数据库集群中特定数据库实例的所有参数。

参数名称 可修改 备注

allow-suspicious-udfs

aurora_lab_mode

有关更多信息,请参阅Amazon Aurora MySQL 实验室模式

aurora_oom_response

有关更多信息,请参阅 Amazon Aurora MySQL 内存不足问题

aurora_read_replica_read_committed

为 Aurora 副本启用 READ COMMITTED 隔离级别,并更改隔离行为,以减少长时间运行的查询期间的清除滞后。仅当您了解行为更改及其对查询结果的影响时,才启用该设置。例如,该设置使用了没有 MySQL 默认设置那么严格的隔离。启用该设置后,长时间运行的查询可能会看到同一行的多个副本,因为 Aurora 会在查询运行期间重组表数据。有关更多信息,请参阅Aurora MySQL 隔离级别

autocommit

automatic_sp_privileges

back_log

basedir

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

binlog_cache_size

binlog_max_flush_queue_time

binlog_order_commits

binlog_stmt_cache_size

bulk_insert_buffer_size

concurrent_insert

connect_timeout

core-file

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

datadir

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

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

enforce_gtid_consistency

有时

在 Aurora MySQL 版本 2.04 及更高版本中可修改。

eq_range_index_dive_limit

event_scheduler

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

general_log_file

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

group_concat_max_len

gtid-mode

有时

在 Aurora MySQL 版本 2.04 及更高版本中可修改。

host_cache_size

init_connect

innodb_adaptive_hash_index

innodb_adaptive_max_sleep_delay

修改此参数不起作用,因为 Aurora 的 innodb_thread_concurrency 始终为 0。

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

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_file_format

innodb_flush_log_at_timeout

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

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

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

join_buffer_size

keep_files_on_create

key_buffer_size

key_cache_age_threshold

key_cache_block_size

key_cache_division_limit

local_infile

lock_wait_timeout

log-bin

binlog_format 设置为 STATEMENTMIXEDROW 会自动将 log-bin 设置为 ON。将 binlog_format 设置为 OFF 会自动将 log-bin 设置为 OFF。有关更多信息,请参阅Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

log_bin_trust_function_creators

log_bin_use_v1_row_events

log_error

log_output

log_queries_not_using_indexes

log_slave_updates

log_throttle_queries_not_using_indexes

log_warnings

long_query_time

low_priority_updates

max_allowed_packet

max_binlog_cache_size

max_binlog_size

max_binlog_stmt_cache_size

max_connect_errors

max_connections

有关更多信息,请参阅至 Aurora MySQL 数据库实例的最大连接数

max_delayed_threads

max_error_count

max_heap_table_size

max_insert_delayed_threads

max_join_size

max_length_for_sort_data

max_prepared_stmt_count

max_seeks_for_key

max_sort_length

max_sp_recursion_depth

max_tmp_tables

max_user_connections

max_write_lock_count

metadata_locks_cache_size

min_examined_row_limit

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

optimizer_prune_level

optimizer_search_depth

optimizer_switch

有关使用此开关的 Aurora MySQL 功能的信息,请参阅 Amazon Aurora MySQL 最佳实践

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

仅限 Aurora MySQL 2.x

performance_schema_events_transactions_history_size

仅限 Aurora MySQL 2.x

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

仅限 Aurora MySQL 2.x

performance_schema_max_memory_classes

仅限 Aurora MySQL 2.x

performance_schema_max_metadata_locks

仅限 Aurora MySQL 2.x

performance_schema_max_mutex_classes

performance_schema_max_mutex_instances

performance_schema_max_prepared_statements_instances

仅限 Aurora MySQL 2.x

performance_schema_max_program_instances

仅限 Aurora MySQL 2.x

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

仅限 Aurora MySQL 2.x

performance_schema_max_stage_classes

performance_schema_max_statement_classes

performance_schema_max_statement_stack

仅限 Aurora MySQL 2.x

performance_schema_max_table_handles

performance_schema_max_table_instances

performance_schema_max_table_lock_stat

仅限 Aurora MySQL 2.x

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_users_size

pid_file

plugin_dir

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

port

Aurora MySQL 管理连接属性,并为集群中的所有数据库实例强制执行一致的设置。

preload_buffer_size

profiling_history_size

query_alloc_block_size

query_cache_limit

query_cache_min_res_unit

query_cache_size

query_cache_type

query_cache_wlock_invalidate

query_prealloc_size

range_alloc_block_size

read_buffer_size

read_only

Aurora MySQL 根据集群类型管理数据库实例的只读和读/写状态。例如,预置的集群具有一个读/写数据库实例(主实例),并且集群中的所有其他实例都是只读的(Aurora 副本)。

read_rnd_buffer_size

relay-log

relay_log_info_repository

relay_log_recovery

safe-user-create

secure_auth

secure_file_priv

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

skip-slave-start

skip_external_locking

skip_show_database

slave_checkpoint_group

slave_checkpoint_period

slave_parallel_workers

slave_pending_jobs_size_max

slave_sql_verify_checksum

slow_launch_time

slow_query_log

有关将日志上传到 CloudWatch Logs 的说明,请参阅 将 Amazon Aurora MySQL 日志发布到 Amazon CloudWatch Logs

slow_query_log_file

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

socket

sort_buffer_size

sql_mode

sql_select_limit

stored_program_cache

sync_binlog

sync_master_info

sync_relay_log

sync_relay_log_info

sysdate-is-now

table_cache_element_entry_ttl

table_definition_cache

table_open_cache

table_open_cache_instances

temp-pool

thread_handling

thread_stack

timed_mutexes

tmp_table_size

tmpdir

Aurora MySQL 使用不在其中直接访问文件系统的托管实例。

transaction_alloc_block_size

transaction_prealloc_size

tx_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

不适用的 MySQL 参数和状态变量

由于 Aurora MySQL 与 MySQL 之间存在架构差异,某些 MySQL 参数和状态变量不适用于 Aurora MySQL。

以下 MySQL 参数不适用于 Aurora MySQL:

  • innodb_adaptive_flushing

  • innodb_adaptive_flushing_lwm

  • innodb_change_buffering

  • innodb_checksum_algorithm

  • innodb_doublewrite

  • 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_max_dirty_pages_pct

  • innodb_use_native_aio

  • innodb_write_io_threads

  • thread_cache_size

以下 MySQL 状态变量不适用于 Aurora MySQL:

  • innodb_buffer_pool_bytes_dirty

  • innodb_buffer_pool_pages_dirty

  • innodb_buffer_pool_pages_flushed

注意

这些列表并不详尽。

Aurora MySQL 事件

以下是 Aurora MySQL 的一些常见等待事件。

注意

有关 MySQL 等待事件中使用的命名约定的信息,请参阅 MySQL 文档中的性能架构测试命名约定

io/aurora_redo_log_flush

在该等待事件中,某个会话正等待数据写入 Aurora 存储。通常,该等待事件针对 Aurora MySQL 中的写入 I/O 操作。

io/aurora_respond_to_client

在该等待事件中,线程正将结果集返回给客户端。

io/file/csv/data

在此等待事件中,有些线程以逗号分隔值 (CSV) 格式写入表。检查您的 CSV 表使用情况。此事件的典型原因是在表上设置 log_output

io/file/innodb/innodb_data_file

在该等待事件中,有正等待至存储的 I/O 操作的线程。此事件在 I/O 密集型工作负载中更普遍。显示此等待事件较大部分的 SQL 语句可能运行磁盘密集型查询。或者,它们可能请求无法从 InnoDB 缓冲池得到满足的数据。要查明情况,请检查查询计划和缓存命中率。有关更多信息,请参阅 MySQL 文档中的缓冲和缓存

io/file/sql/binlog

在该等待事件中,有等待正写入磁盘的二进制日志文件的线程。

io/socket/sql/client_connection

在该等待事件中,线程正处理新连接。

io/table/sql/handler

这是表 I/O 等待事件。通常,这些类型的事件可以后接嵌套事件(如文件 I/O 事件)。有关性能架构中的“原子”和“分子”事件的更多信息,请参阅 MySQL 文档中的性能架构原子和分子事件

lock/table/sql/handler

该等待事件是表锁定等待事件处理程序。有关性能架构中的“原子”和“分子”事件的更多信息,请参阅 MySQL 文档中的性能架构原子和分子事件

synch/cond/mysys/my_thread_var::suspend

在该等待事件中,将在线程等待条件时暂停线程。例如,此事件发生在线程等待表级别锁定时。建议调查工作负载,以了解哪些线程可能正获取数据库实例上的表锁定。有关 MySQL 中的表锁定的更多信息,请参阅 MySQL 文档中的表锁定问题

synch/cond/sql/MDL_context::COND_wait_status

在该等待事件中,有正等待表元数据锁定的线程。有关更多信息,请参阅 MySQL 文档中的优化锁定操作

synch/cond/sql/MYSQL_BIN_LOG::COND_done

在该等待事件中,有等待正写入磁盘的二进制日志文件的线程。二进制日志记录争用可能出现在更改率非常高的数据库上。

synch/mutex/innodb/aurora_lock_thread_slot_futex

在该等待事件中,一个线程正在等待 InnoDB 记录锁定。如果看到该事件,请检查数据库是否存在发生冲突的工作负载。有关更多信息,请参阅 MySQL 文档中的 InnoDB 锁定

synch/mutex/innodb/buf_pool_mutex

在该等待事件中,线程已在 InnoDB 缓冲池上获取锁定。

synch/mutex/sql/LOCK_open

在该等待事件中,LOCK_open 正用于保护数据字典中的各个对象。该等待事件指示有正等待获取这些锁定的线程。通常,此事件由数据字典争用导致。

synch/mutex/sql/LOCK_table_cache

在该等待事件中,有正等待在表缓存实例上获取锁定的线程。有关更多信息,请参阅 MySQL 文档中的 MySQL 如何打开和关闭表

synch/mutex/sql/LOG

在该等待事件中,有正等待日志锁定的线程。例如,线程可能等待锁定写入慢速查询日志文件。

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit

在该等待事件中,有正等待带着提交到二进制日志的意图获取锁定的线程。二进制日志记录争用可能出现在更改率非常高的数据库上。根据您的 MySQL 版本,有特定锁定用于保护二进制日志的一致性和持续性。在 RDS MySQL 中,二进制日志用于复制和自动备份过程。在 Aurora MySQL 中,本机复制或备份不需要二进制日志。它们默认情况下处于禁用状态,但可以启用或用于外部复制或更改数据捕获。有关更多信息,请参阅 MySQL 文档中的二进制日志

synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log

在该等待事件中,线程正积极锁定二进制日志文件。二进制日志记录争用可能出现在更改率非常高的数据库上。根据您的 MySQL 版本,有特定锁定用于保护二进制日志的一致性和持续性。

synch/rwlock/innodb/dict

在该等待事件中,有正等待 InnoDB 数据字典中保留的 rwlock 的线程。

synch/rwlock/innodb/dict sys RW lock

在该等待事件中,有正等待 InnoDB 数据字典中保留的 rwlock 的线程。

synch/rwlock/innodb/dict_operation_lock

在该等待事件中,有在 InnoDB 数据字典操作中保留锁定的线程。

Aurora MySQL 隔离级别

接下来,您可以了解 Aurora MySQL 集群中的数据库实例如何实现隔离的数据库属性。这样做有助于您了解 Aurora MySQL 默认行为如何在严格一致性和高性能之间取得平衡。您还可以根据工作负载的特性决定何时更改默认设置。

写入器实例的可用隔离级别

您可以在 Aurora MySQL 单主集群的主实例或 Aurora MySQL 多主集群的任何数据库实例上使用隔离级别 REPEATABLE READREAD COMMITTEDREAD UNCOMMITTEDSERIALIZABLE。这些隔离级别在 Aurora MySQL 中的工作方式与在 RDS 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 主实例或 Amazon RDS MySQL 上的 READ COMMITTED 下的同一查询的结果不同。您可以将 aurora_read_replica_read_committed 设置用于诸如扫描超大型数据库的综合报告之类的用例。在精度和可重复性很重要的小型结果集的短查询中,您可能会避免使用它。

READ COMMITTED 隔离级别不适用于 Aurora 全局数据库的辅助集群中使用写入转发功能的会话。有关写入转发的信息,请参阅 具有 Aurora 全局数据库的辅助 AWS 区域的写入转发

对读取器启用 READ COMMITTED

要对 Aurora 副本启用 READ COMMITTED 隔离级别,请启用 aurora_read_replica_read_committed 配置设置。在连接特定的 Aurora 副本时,在会话级别启用此设置。为此,请运行以下 SQL 命令。

set session aurora_read_replica_read_committed = ON; set session transaction isolation level read committed;

您可能会暂时启用此配置设置,以执行交互式临时(一次性)查询。您可能还想运行一个从 READ COMMITTED 隔离级别中受益的报告或数据分析应用程序,而其他应用程序的默认设置保持不变。

您可以为集群中的一个或多个 Aurora 副本永久启用此功能。为此,请在关联数据库实例使用的数据库参数组中打开 aurora_read_replica_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 语句并发修改的表,如 INSERTDELETE。在这种情况下,联接查询可能从一个表读取一行,但不从另一个表读取对应的行。

ANSI SQL 标准允许 READ COMMITTED 隔离级别存在这两种行为。但是,这些行为与 READ COMMITTED 的典型 MySQL 实现不同。因此,启用 aurora_read_replica_read_committed 设置之前,请先检查任何现有的 SQL 代码,以验证其在更宽松的一致性模型下是否按预期运行。

启用此设置时,READ COMMITTED 隔离级别下的行数和其他结果可能不具有强一致性。因此,通常只在运行聚合大量数据且无需绝对精度的分析查询时才启用该设置。如果没有这些类型的长时间运行的查询以及写入密集型工作负载,则可能不需要 aurora_read_replica_read_committed 设置。如果没有长时间运行的查询和写入密集型工作负载的组合,就不太可能遇到历史记录列表长度的问题。

例 显示 READ COMMITTED 隔离行为的针对 Aurora 副本的查询

以下示例展示了如果事务同时修改关联表,针对 Aurora 副本的 READ COMMITTED 查询如何返回不可重复的结果。表 BIG_TABLE 在任何查询开始之前包含 100 万行。其他数据操作语言 (DML) 语句在运行时会添加、删除或更改行。

READ COMMITTED 隔离级别下针对 Aurora 主实例的查询生成可预测的结果。但是,在每个长时间运行的查询的生命周期内保持一致的读取视图,这样所产生的开销可能会导致以后的垃圾回收成本高昂。

我们优化了 READ COMMITTED 隔离级别下对 Aurora 副本的查询,以最大程度减少这种垃圾回收开销。权衡之下,结果可能有所不同,具体取决于查询是否检索查询运行期间提交的事务所添加、删除或重组的行。允许查询考虑这些行,但不要求这样做。出于演示目的,查询仅使用 COUNT(*) 函数检查表中的行数。

Time Aurora 主实例上的 DML 语句 针对 Aurora 主实例(具有 READ COMMITTED)的查询 针对 Aurora 副本(具有 READ COMMITTED)的查询
T1 INSERT INTO big_table SELECT * FROM other_table LIMIT 1000000; COMMIT;
T2 Q1:SELECT COUNT(*) FROM big_table; Q2:SELECT COUNT(*) FROM big_table;
T3 INSERT INTO big_table (c1, c2) VALUES (1, 'one more row'); COMMIT;
T4 如果 Q1 现在完成,则结果为 1,000,000。 如果 Q2 现在完成,则结果为 1,000,000 或 1,000,001。
T5 DELETE FROM big_table LIMIT 2; COMMIT;
T6 如果 Q1 现在完成,则结果为 1,000,000。 如果 Q2 现在完成,则结果为 1,000,000 或 1,000,001 或 999,999 或 999,998。
T7 UPDATE big_table SET c2 = CONCAT(c2,c2,c2); COMMIT;
T8 如果 Q1 现在完成,则结果为 1,000,000。 如果 Q2 现在完成,则结果为 1,000,000 或 1,000,001 或 999,999 或可能某个更大的数字。
T9 Q3:SELECT COUNT(*) FROM big_table; Q4:SELECT COUNT(*) FROM big_table;
T10 如果 Q3 现在完成,则结果为 999,999。 如果 Q4 现在完成,则结果为 999,999。
T11 Q5:SELECT COUNT(*) FROM parent_table p JOIN child_table c ON (p.id = c.id) WHERE p.id = 1000; Q6:SELECT COUNT(*) FROM parent_table p JOIN child_table c ON (p.id = c.id) WHERE p.id = 1000;
T12 INSERT INTO parent_table (id, s) VALUES (1000, 'hello'); INSERT INTO child_table (id, s) VALUES (1000, 'world'); COMMIT;
T13 如果 Q5 现在完成,则结果为 0。 如果 Q6 现在完成,则结果为 0 或 1。

如果查询快速完成,则在任何其他事务执行 DML 语句并提交之前,结果是可预测的,并且主实例与 Aurora 副本之间也是如此。

Q1 的结果高度可预测,因为主实例上的 READ COMMITTED 使用类似于 REPEATABLE READ 隔离级别的强一致性模型。

Q2 的结果可能会因查询运行期间提交的事务而异。例如,假设其他事务执行 DML 语句并在查询运行期间提交。在这种情况下,针对具有 READ COMMITTED 隔离级别的 Aurora 副本的查询可能考虑更改,也可能不考虑更改。不能像在 REPEATABLE READ 隔离级别下那样预测行数。它们也不像针对 READ COMMITTED 隔离级别下的主实例或针对 RDS MySQL 实例运行的查询那样可预测。

T7 处的 UPDATE 语句实际上并未更改表中的行数。但是,通过更改可变长度列的长度,该语句可能导致在内部对行进行重组。长时间运行的 READ COMMITTED 事务可能会看到某行的旧版本,随后又在同一查询中看到该行的新版本。查询还可以跳过该行的旧版本和新版本。因此,行数可能与预期不同。

Q5 和 Q6 的结果可能相同,也可能略有不同。READ COMMITTED 下针对 Aurora 副本的查询 Q6 可以查看(但不是必须查看)查询运行期间提交的新行。它也可能从一个表中看到该行,但从另一表中看不到该行。如果联接查询在两个表中均未找到匹配的行,则返回的计数为零。如果查询的确在 PARENT_TABLECHILD_TABLE 中找到了新行,则该查询返回的计数为一。在长时间运行的查询中,从联接的表进行查找的时间可能相隔很远。

注意

这些行为上的差异取决于事务何时提交以及查询何时处理底层表行。因此,在耗时数分钟或数小时的报告查询以及同时在处理 OLTP 事务的 Aurora 集群上运行的报表查询中,您最有可能看到这样的差异。这些类型的混合工作负载从 Aurora 副本上的 READ COMMITTED 隔离级别获益最大。

Aurora MySQL 提示

您可以将 SQL 提示与 Aurora MySQL 查询结合使用来微调性能。您还可以使用提示来防止重要查询的执行计划根据不可预知的条件进行更改。

提示

要验证提示对查询的影响,请查看 EXPLAIN 语句生成的查询计划。比较包含和不包含提示的查询计划。

以下提示适用于使用哈希联接功能的查询。这些提示在 Aurora MySQL 2.08 及更高版本中可用。

HASH_JOIN、NO_HASH_JOIN

开启或关闭优化程序的功能来选择是否对查询使用哈希联接优化方法。HASH_JOIN 允许优化程序使用哈希联接(如果该机制更高效)。NO_HASH_JOIN 阻止优化程序对查询使用哈希联接。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。

EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1;
HASH_JOIN_PROBING、NO_HASH_JOIN_PROBING

在哈希联接查询中,指定是否将指定的表用于联接的探查端。查询测试构建表中的列值是否存在于探查表中,而不是读取探查表的全部内容。您可以使用 HASH_JOIN_PROBINGHASH_JOIN_BUILDING 指定如何处理哈希联接查询,而无需重新排序查询文本中的表。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。为表 T2 指定 HASH_JOIN_PROBING 提示与为表 T1 指定 NO_HASH_JOIN_PROBING 具有相同的效果。

EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1;
HASH_JOIN_BUILDING、NO_HASH_JOIN_BUILDING

在哈希联接查询中,指定是否将指定的表用于联接的构建端。查询处理此表中的所有行来构建列值列表,以便与其他表进行交叉引用。您可以使用 HASH_JOIN_PROBINGHASH_JOIN_BUILDING 指定如何处理哈希联接查询,而无需重新排序查询文本中的表。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。为表 T2 指定 HASH_JOIN_BUILDING 提示与为表 T1 指定 NO_HASH_JOIN_BUILDING 具有相同的效果。

EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1; EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2 FROM t1, t2 WHERE t1.f1 = t2.f1;
JOIN_FIXED_ORDER

指定查询中的表按它们在查询中的列出顺序进行联接。对于涉及三个或更多表的查询,它特别有用。它旨在替代 MySQL STRAIGHT_JOIN 提示。等效于 MySQL JOIN_FIXED_ORDER 提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。

EXPLAIN SELECT /*+ JOIN_FIXED_ORDER */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
JOIN_ORDER

指定查询中表的联接顺序。对于涉及三个或更多表的查询,它特别有用。等效于 MySQL JOIN_ORDER 提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。

EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
JOIN_PREFIX

指定联接顺序中首先放置的表。对于涉及三个或更多表的查询,它特别有用。等效于 MySQL JOIN_PREFIX 提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。

EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
JOIN_SUFFIX

指定联接顺序中最后放置的表。对于涉及三个或更多表的查询,它特别有用。等效于 MySQL JOIN_SUFFIX 提示。此提示在 Aurora MySQL 2.08 及更高版本中可用。

以下示例显示如何使用此提示。

EXPLAIN SELECT /*+ JOIN_ORDER (t1, t3) */ f1, f2 FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);

有关使用哈希联接查询的信息,请参阅在 Aurora MySQL 中使用哈希联接

Aurora MySQL 存储过程

您可以在连接到 Aurora MySQL 集群中的主实例时,调用以下存储过程。这些过程控制事务如何从外部数据库复制到 Aurora MySQL,或从 Aurora MySQL 复制到外部数据库。要了解如何根据 Aurora MySQL 中的全局事务标识符 (GTID) 使用复制,请参阅 在 Aurora MySQL 中使用基于 GTID 的复制

mysql.rds_set_master_auto_position

将复制模式设置为基于二进制日志文件位置或全局事务标识符 (GTID)。

语法

CALL mysql.rds_set_master_auto_position (auto_position_mode);

参数

auto_position_mode

该值指示是使用日志文件位置复制还是基于 GTID 的复制:

  • 0 – 使用基于二进制日志文件位置的复制方法。默认为 0

  • 1 – 使用基于 GTID 的复制方法。

使用说明

对于 Aurora MySQL 数据库集群,您将在连接到主实例时调用此存储过程。

主用户必须运行 mysql.rds_set_master_auto_position 过程。

对于 Aurora,Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。

mysql.rds_set_external_master_with_auto_position

将 Aurora MySQL 主实例配置为接受来自外部 MySQL 实例的传入复制。此过程还会根据全局事务标识符 (GTID) 配置复制。

此过程对于 Amazon RDS MySQL 和 Aurora MySQL 均可用。它在不同上下文中的作用可能不同。在用于 Aurora MySQL 时,此过程不会配置延迟复制。此限制是由于 Amazon RDS MySQL 支持延迟复制,但 Aurora MySQL 不支持。

语法

CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption );

参数

host_name

在 Aurora 之外运行以变为复制主实例的 MySQL 实例的主机名或 IP 地址。

host_port

在 Aurora 之外运行的要配置为复制主实例的 MySQL 实例使用的端口。如果网络配置包括转换端口号的安全 Shell (SSH) 端口复制,请指定由 SSH 公开的端口号。

replication_user_name

在对 Aurora 外部运行的 MySQL 实例上具有 REPLICATION CLIENTREPLICATION SLAVE 权限的用户的 ID。建议您向专用于复制的账户提供外部实例。

replication_user_password

replication_user_name 中指定的用户 ID 的密码。

ssl_encryption

目前未实施该选项。默认值为 0。

使用说明

对于 Aurora MySQL 数据库集群,您将在连接到主实例时调用此存储过程。

主用户必须运行 mysql.rds_set_external_master_with_auto_position 过程。主用户在充当复制目标的 Aurora MySQL 数据库集群的主实例上运行此过程。这可能是外部 MySQL 数据库实例或 Aurora MySQL 数据库集群的复制目标。

对于 Aurora,Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。

在运行 mysql.rds_set_external_master_with_auto_position 前,请将外部 MySQL 数据库实例配置为复制主实例。要连接到外部 MySQL 实例,应指定 replication_user_namereplication_user_password 值。这些值必须指示具有外部 MySQL 实例上的 REPLICATION CLIENTREPLICATION SLAVE 权限的复制用户。

将外部 MySQL 实例配置为复制主实例

  1. 通过使用所选的 MySQL 客户端,连接到外部 MySQL 实例并创建要用于复制的用户账户。以下是示例。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
  2. 在外部 MySQL 实例上,向复制用户授予 REPLICATION CLIENTREPLICATION SLAVE 权限。以下示例为您的域的 'repl_user' 用户授予所有数据库的 REPLICATION CLIENTREPLICATION SLAVE 权限。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'

在调用 mysql.rds_set_external_master_with_auto_position 时,Amazon RDS 将记录某些信息。这些信息包括 mysql.rds_historymysql.rds_replication_status 表中的时间、用户和 "set master" 操作。

要跳过已知会导致问题的基于 GTID 的特定事务,您可以使用 mysql.rds_skip_transaction_with_gtid 存储过程。有关使用基于 GTID 的复制的更多信息,请参阅在 Aurora MySQL 中使用基于 GTID 的复制

示例

在 Aurora 主实例上运行时,以下示例将 Aurora 集群配置为充当在 Aurora 之外运行的某个 MySQL 实例的只读副本。

call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user'@'mydomain.com', 'SomePassW0rd');

mysql.rds_skip_transaction_with_gtid

在 Aurora 主实例上跳过复制具有指定全局事务标识符 (GTID) 的事务。

在已知特定 GTID 事务导致问题时,您可以使用该过程进行灾难恢复。请使用该存储过程跳过有问题的事务。有问题的事务示例包括禁用复制、删除重要数据或导致数据库实例变得不可用的事务。

语法

CALL mysql.rds_skip_transaction_with_gtid (gtid_to_skip);

参数

gtid_to_skip

要跳过的复制事务的 GTID。

使用说明

对于 Aurora MySQL 数据库集群,您将在连接到主实例时调用此存储过程。

主用户必须运行 mysql.rds_skip_transaction_with_gtid 过程。

对于 Aurora,Aurora MySQL 版本 2.04 及更高版本的 MySQL 5.7 兼容版本支持此过程。Aurora MySQL 1.1 或 1.0 不支持基于 GTID 的复制。