Amazon Aurora MySQL のリファレンス

このリファレンスには、Aurora MySQL パラメータ、ステータス変数、一般的な SQL 拡張に関する情報や、コミュニティ MySQL データベースエンジンとの相違点が含まれます。

Aurora MySQL 設定パラメータ

Amazon Aurora MySQL DB クラスターの管理には、他の Amazon RDS DB インスタンスを管理するのと同じ方法で、DB パラメータグループのパラメータを使用します。Amazon Aurora は、複数の DB インスタンスを含む DB クラスターを使用する点が、他の DB エンジンとは異なります。そのため、Aurora MySQL DB クラスターの管理に使用するパラメータの中には、クラスター全体に適用されるものがあります。それ以外のパラメータは、DB クラスターの特定の DB インスタンスにのみ適用されます。

クラスターレベルのパラメータを管理するには、DB クラスターのパラメータグループを使用します。インスタンスレベルのパラメータを管理するには、DB パラメータグループを使用します。Aurora MySQL DB クラスターの各 DB インスタンスは、MySQL データベースエンジンと互換性があります。ただし、クラスターレベルでは MySQL データベースエンジンのパラメータの一部を適用します。これらのパラメータは、DB クラスターのパラメータグループを使用して管理します。Aurora DB クラスター内のインスタンスの DB パラメータグループにクラスターレベルのパラメータが見つかりません。クラスターレベルのパラメータの一覧は、このトピックの後半で紹介します。

クラスターレベルとインスタンスレベルのパラメータは、いずれも AWS Management Console、AWS CLI、または Amazon RDS API を使用して管理できます。クラスターレベルのパラメータとインスタンスレベルのパラメータの管理には、別々のコマンドを使用します。例えば、DB クラスターパラメータグループのクラスターレベルのパラメータを管理するには、CLI の modify-db-cluster-parameter-group コマンドを使用します。DB クラスターの DB インスタンスの DB パラメータグループのインスタンスレベルのパラメータを管理するには、CLI の modify-db-parameter-group コマンドを使用します。

クラスターレベルのパラメータとインスタンスレベルのパラメータはいずれも、コンソール、CLI、または RDS API を使用して表示できます。例えば、DB クラスターパラメータグループのクラスターレベルのパラメータを表示するには、AWS CLI の describe-db-cluster-parameters コマンドを使用します。DB クラスターの DB インスタンスの DB パラメータグループのインスタンスレベルのパラメータを表示するには、CLI の describe-db-parameters コマンドを使用します。

注記

各デフォルトのパラメータグループには、パラメータグループ内のすべてのパラメータのデフォルト値が含まれます。パラメータのこの値に「エンジンのデフォルト」がある場合は、実際のデフォルト値については、バージョン固有の MySQL または PostgreSQL のドキュメントを参照してください。

DB パラメータグループの詳細については、「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。Aurora Serverless クラスターのルールおよび制限については、「パラメータグループと Aurora Serverless v1」を参照してください。

トピック

• クラスターレベルのパラメータ
• インスタンスレベルのパラメータ

クラスターレベルのパラメータ

次の表は、Aurora MySQL DB クラスター全体に適用されるすべてのパラメータを示しています。

パラメータ名	変更可能	コメント
aurora_binlog_read_buffer_size	はい	バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
aurora_binlog_replication_max_yield_seconds	はい	バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
aurora_binlog_use_large_read_buffer	はい	バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
aurora_enable_replica_log_compression	はい	詳細については、「Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項」を参照してください。Aurora グローバルデータベースの一部であるクラスターには適用されません。
aurora_enable_repl_bin_log_filtering	はい	詳細については、「Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項」を参照してください。Aurora グローバルデータベースの一部であるクラスターには適用されません。
aurora_enable_zdr	はい	Aurora MySQL 2.10 以降では、この設定はデフォルトでオンになっています。詳細については、「ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)」を参照してください。
aurora_load_from_s3_role	はい	詳細については、「Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード」を参照してください。
aurora_select_into_s3_role	はい	詳細については、「Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存」を参照してください。
auto_increment_increment	はい
auto_increment_offset	はい
aws_default_lambda_role	はい	詳細については、「Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し」を参照してください。
aws_default_s3_role	はい
binlog_checksum	はい	このパラメータが設定されていない場合、AWS CLI および RDS API は None の値をレポートします。この場合、Aurora MySQL はエンジンのデフォルト値である CRC32 を使用します。これは、チェックサムを無効化する明示的な NONE の設定とは異なります。このパラメータに関連するバグ修正については、Aurora MySQL データベースエンジンの更新 2020-09-02 (バージョン 1.23.0) および Aurora MySQL データベースエンジンの更新プログラム 2020-03-05 (バージョン 1.22.2) を参照してください。
binlog_format	はい	詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
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 ストレージエンジンを使用します。
gtid-mode	時々	Aurora MySQL バージョン 2.04 以降で変更可能です。
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	はい	詳細については、「Aurora MySQL DB クラスターでの SSL/TLS の使用」を参照してください。
server_audit_events	はい
server_audit_excl_users	はい
server_audit_incl_users	はい
server_audit_logging	はい	Amazon CloudWatch Logs へのログのアップロードの手順については、Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行 を参照してください。
server_id	いいえ
skip-character-set-client-handshake	はい
skip_name_resolve	いいえ
slave-skip-errors	はい	MySQL 5.7 の互換性を備えた Aurora MySQL バージョン 2 クラスターにのみ適用されます。
sync_frm	はい
time_zone	はい
tls_version	はい	詳細については、「Aurora MySQL の TLS バージョン」を参照してください。

インスタンスレベルのパラメータ

次の表は、Aurora MySQL DB クラスターの特定の DB インスタンスに適用されるパラメータの一覧です。

パラメータ名	変更可能	コメント
allow-suspicious-udfs	いいえ
aurora_lab_mode	はい	詳細については、「Amazon Aurora MySQL ラボモード」を参照してください。
aurora_oom_response	はい	このパラメータは、Aurora MySQL バージョン 1.18 以降にのみ適用されます。これは、Aurora MySQL バージョン2では使用されていません。詳細については、「 Amazon Aurora MySQL のメモリ不足の問題 」を参照してください。
aurora_parallel_query	はい	Aurora MySQL バージョン 1.23 および 2.09 以降で並列クエリを有効にするには、ON に設定します。これらのバージョンでは、古い aurora_pq パラメータは使用されません。詳細については、「Amazon Aurora MySQL の並列クエリの使用」を参照してください。
aurora_pq	はい	Aurora MySQL バージョン 1.23 および 2.09 より前の特定の DB インスタンスの並列クエリをオフにするには、OFF に設定します。1.23 および 2.09 以降では、代わりに aurora_parallel_query を使用してパラレルクエリのオンとオフを切り替えます。詳細については、「Amazon 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 CloudWatch Logs への Amazon Aurora MySQL ログの発行 を参照してください。
general_log_file	いいえ	Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。
group_concat_max_len	はい
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 は、クラスターの種類に基づき、DB インスタンスの読み取り専用と読み書きの状態を管理します。例えば、プロビジョンされたクラスターに読み書きの DB インスタンス (プライマリインスタンス) が 1 つあり、クラスターのそれ以外のインスタンスは読み取り専用 (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 の最小値を評価し、その最小値をタイムアウトとして使用して、対話型と非対話型の両方のアイドル状態のセッションをすべて終了します。
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 を STATEMENT、MIXED、または ROW に設定すると、log-bin は自動的に ON に設定されます。binlog_format を OFF に設定すると、log-bin は自動的に OFF に設定されます。詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
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 DB インスタンスへの最大接続数」を参照してください。
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 は接続プロパティを管理し、クラスター内のすべての DB インスタンスに対して一貫した設定を適用します。
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 は、クラスターの種類に基づき、DB インスタンスの読み取り専用と読み書きの状態を管理します。例えば、プロビジョンされたクラスターに読み書きの DB インスタンス (プライマリインスタンス) が 1 つあり、クラスターのそれ以外のインスタンスは読み取り専用 (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 CloudWatch Logs への Amazon Aurora MySQL ログの発行 を参照してください。
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	はい	Aurora は、interactive_timeout および 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 ドキュメントの「Performance Schemaインストゥルメント命名規則」を参照してください。

io/aurora_redo_log_flush

この待機イベントの場合、セッションは Aurora ストレージにデータを書き込み中です。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。

io/aurora_respond_to_client

この待機イベントの場合、スレッドはクライアントに結果セットを返すプロセス中です。

io/file/csv/data

この待機イベントの場合、Comma Separated Value (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 イベントなどのネストイベントが続きます。Performance Schemaの「原始的」イベントと「分子的」イベントの詳細については、MySQL ドキュメントの「Performance Schemaの原子的および分子的イベント」を参照してください。

lock/table/sql/handler

この待機イベントは、テーブルロック待機イベントハンドラです。Performance Schemaの「原始的」イベントと「分子的」イベントの詳細については、MySQL ドキュメントの「Performance Schemaの原子的および分子的イベント」を参照してください。

synch/cond/mysys/my_thread_var::suspend

この待機イベントの場合、スレッドは条件の待機中に停止されます。例えば、スレッドがテーブルレベルのロックを待機しているときに、このイベントが発生します。ワークロードを調査し、DB インスタンスのテーブルロックを取得する可能性があるスレッドを確認することをお勧めします。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 Locking」を参照してください。

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 for 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 クラスターの DB インスタンスが分離のデータベースプロパティを実装する方法について説明します。これにより、Aurora MySQL のデフォルトの動作で厳密な一貫性と高いパフォーマンスのバランスがどのように取られるかを理解することができます。ワークロードの特性に基づいて、デフォルト設定を変更するタイミングを判断することもできます。

ライターインスタンスで使用可能な分離レベル

Aurora MySQL 単一マスタークラスターのプライマリインスタンスでは、分離レベル REPEATABLE READ、READ COMMITTED、READ UNCOMMITTED、および SERIALIZABLE を使用できます。分離レベル REPEATABLE READ、READ COMMITTED、および READ UNCOMMITTED は、Aurora MySQL マルチマスタークラスターの任意の DB インスタンスで使用できます。これらの分離レベルは、Aurora MySQL と RDS for MySQL で同じように機能します。

リーダーインスタンスでの REPEATABLE READ の分離レベル

Aurora レプリカとして設定された Aurora MySQL DB インスタンスは、デフォルトでは、常に REPEATABLE READ 分離レベルを使用します。これらの DB インスタンスは、SET TRANSACTION ISOLATION LEVEL ステートメントを無視し、引き続き REPEATABLE READ 分離レベルを使用します。

リーダーインスタンスでの READ COMMITTED の分離レベル

アプリケーションのプライマリインスタンスに書き込み集中型のワークロードが含まれ、Aurora レプリカに長時間実行されるクエリが含まれている場合、かなりのパージラグが発生する可能性があります。パージラグは、長時間実行されるクエリによって内部ガベージコレクションがブロックされた場合に発生します。確認できる症状として、history list length コマンドからの出力で SHOW ENGINE INNODB STATUS の値が大きくなります。この値をモニタリングするには、CloudWatch の RollbackSegmentHistoryListLength メトリクスを使用します。この条件が発生すると、セカンダリインデックスの有効性が低下し、全体的なクエリパフォーマンスの低下とストレージ領域の浪費が起きる可能性があります。

このような問題が発生した場合は、Aurora レプリカで aurora_read_replica_read_committed 分離レベルを使用するために、Aurora MySQL セッションレベルの構成設定、READ COMMITTED を使用します。この設定を使用すると、テーブルを変更するトランザクションと同時に長時間実行されるクエリを実行した場合に発生する可能性のある、速度低下と領域の浪費を軽減できます。

この設定を使用するには、Aurora MySQL MySQL の READ COMMITTED 分離に固有の動作を理解しておくことをお勧めします。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 グローバルデータベースの書き込み転送を使用する」を参照してください。

リーダーでの 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;

この構成設定を一時的に有効にして、インタラクティブなアドホック（1 回限りの）クエリを実行できます。また、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 設定は、Aurora レプリカで READ COMMITTED 分離レベルを使用可能にし、長時間実行されるトランザクション用に最適化された一貫性動作を実現します。Aurora レプリカでの READ COMMITTED 分離レベルの厳密性は、Aurora プライマリインスタンスまたはマルチマスターインスタンスでの厳密性より劣ります。そのため、クエリが特定のタイプの一貫性のない結果を受け入れられることがわかっている Aurora レプリカでのみ、この設定を有効にしてください。

aurora_read_replica_read_committed 設定がオンのときに、クエリで特定の種類の読み取り異常が発生する可能性があります。アプリケーションコードについて理解して処理するためには、2 種類の異常が特に重要です。クエリの実行中に別のトランザクションがコミットすると、繰り返し不可のリードが発生します。長時間実行されるクエリでは、クエリの開始時に、終了時に表示されるデータとは異なるデータが表示されることがあります。ファントムリードは、クエリの実行中に他のトランザクションによって既存の行が再編成され、1 つ以上の行がクエリによって 2 回読み取られると発生します。

ファントムリードの結果として、クエリで一貫性のない行カウントが実行される場合があります。繰り返し不可のリードが原因で、クエリから不完全または一貫性のない結果が返されることもあります。例えば、結合操作が SQL ステートメント（INSERT、DELETE など）によって同時に変更されるテーブルを参照するとします。この場合、結合クエリは、あるテーブルの行を読み取りますが、別のテーブルの対応する行は読み取らない可能性があります。

ANSI SQL 標準では、READ COMMITTED 分離レベルでこれらの両方の動作が許可されます。ただしこれらの動作は、READ COMMITTED の一般的な MySQL 実装とは異なります。そのため、aurora_read_replica_read_committed 設定を有効にする前に、既存の SQL コードを調べて、よりあいまいな整合性モデルで期待どおりに動作するかどうかを確認します。

この設定が有効になっている場合、READ COMMITTED 分離レベルでは、行カウントとその他の結果の一貫性があまりない場合があります。したがって通常は、大量のデータを集計し、絶対的な精度を必要としない分析クエリを実行しているときにのみ、設定を有効にします。これらの種類の長時間実行クエリを、書き込み集中型のワークロードと組み合わせて使用しない場合、aurora_read_replica_read_committed 設定は不要である可能性があります。長時間実行されるクエリと書き込み集中型のワークロードの組み合わせがなければ、履歴リストの長さに問題が発生することはほとんどありません。

例 Aurora レプリカでの READ COMMITTED の分離動作を示すクエリ

次の例は、トランザクションが関連するテーブルを同時に変更した場合に、Aurora レプリカで実行された READ COMMITTED クエリが繰り返し不可能な結果を返す方法を示しています。テーブル BIG_TABLE には、クエリ開始の前に 100 万行が含まれています。他のデータ操作言語（DML）ステートメントは、実行中に行を追加、削除、または変更します。

Aurora プライマリインスタンスにおける READ COMMITTED 分離レベルでのクエリは、予測可能な結果を生成します。ただし、長時間実行されるすべてのクエリのライフタイムにわたって一貫した読み取りビューを維持するオーバーヘッドにより、後で高コストのガベージコレクションが発生する可能性があります。

Aurora レプリカにおける READ COMMITTED 分離レベルでのクエリは、このガベージコレクションのオーバーヘッドを最小限に抑えるように最適化されます。トレードオフは、クエリの実行中にコミットするトランザクションによって追加、削除、または再編成された行をクエリが取得するかどうかによって結果が異なる場合があることを指します。クエリではこれらの行を考慮することができますが、必須ではありません。デモンストレーションの目的で、クエリは COUNT(*) 関数を使用してテーブル内の行数のみをチェックします。

時間	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 レプリカでも同じ結果になります。

プライマリインスタンスでの READ COMMITTED は REPEATABLE READ 分離レベルと同様の強力な一貫性モデルを使用するため、Q1 の結果の予測可能性が非常に高くなります。

Q2 の結果は、そのクエリの実行中にコミットするトランザクションに応じて異なる場合があります。例えば、他のトランザクションが DML ステートメントを実行し、クエリの実行中にコミットするとします。この場合、Aurora レプリカでの READ COMMITTED 分離レベルを使用したクエリでは、変更が考慮される場合と考慮されない場合があります。行数は、REPEATABLE READ 分離レベルの場合と同じ方法では予測できません。さらに、プライマリインスタンスまたは RDS for MySQL インスタンスにおいて READ COMMITTED 分離レベルで実行されるクエリほど予測可能ではありません。

T7 の UPDATE ステートメントは、実際にはテーブル内の行数を変更しません。ただし、可変長列の長さを変更すると、このステートメントによって行が内部的に再編成される可能性があります。長時間実行される READ COMMITTED トランザクションでは、古いバージョンの行が表示され、同じクエリ内で後から同じ行の新しいバージョンが表示される場合があります。クエリでは、行の古いバージョンと新しいバージョンの両方をスキップすることもできます。したがって、行カウントは予想と異なる場合があります。

Q5 と Q6 の結果は、同じである場合と、わずかに異なる場合があります。Aurora レプリカにおける READ COMMITTED でのクエリ Q6 は、クエリの実行中にコミットされた新しい行を表示できますが、表示する必要はありません。また、一方のテーブルの行は表示され、もう一方のテーブルの行は表示されないこともあります。結合クエリは、両方のテーブルで一致する行を見つけられない場合、ゼロのカウントを返します。クエリは、PARENT_TABLE と CHILD_TABLE の両方で新しい行を検出した場合、カウント 1 を返します。長時間実行されるクエリでは、結合されたテーブルからの検索が行われる時間に大きな開きが生じる可能性があります。

注記

これらの動作の違いは、トランザクションがコミットされるタイミングと、基になるテーブル行をクエリが処理するタイミングによって異なります。したがって、このような違いが見られる可能性が最も高くなるのは、数分または数時間かかるレポートクエリ、および OLTP トランザクションを同時に処理する Aurora クラスターで実行されるレポートクエリです。これらは、Aurora レプリカでの READ COMMITTED 分離レベルのメリットを最も享受する種類の混合ワークロードです。

Aurora MySQL のヒント

Aurora MySQL クエリで SQL ヒントを使用して、パフォーマンスを微調整できます。ヒントを使用して、重要なクエリの実行計画が予測不可能な条件に基づいて変更されないようにすることもできます。

ヒント

ヒントがクエリに与える影響を確認するには、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_PROBING および HASH_JOIN_BUILDING を使用して、クエリテキスト内のテーブルを並べ替えることなく、ハッシュ結合クエリの処理方法を指定できます。このヒントは、Aurora MySQL 2.08 以降で使用可能です。

以下の例では、このヒントの使用方法を示します。テーブル HASH_JOIN_PROBING の T2 ヒントを指定することは、テーブル NO_HASH_JOIN_PROBING に T1 を指定するのと同じ効果があります。

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

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

HASH_JOIN_BUILDING、NO_HASH_JOIN_BUILDING

ハッシュ結合クエリで、結合のビルド側に指定されたテーブルを使用するかどうかを指定します。クエリは、このテーブルのすべての行を処理し、他のテーブルと相互参照する列値のリストを作成します。HASH_JOIN_PROBING および HASH_JOIN_BUILDING を使用して、クエリテキスト内のテーブルを並べ替えることなく、ハッシュ結合クエリの処理方法を指定できます。このヒントは、Aurora MySQL 2.08 以降で使用可能です。

以下の例では、このヒントの使用方法を示します。テーブル HASH_JOIN_BUILDING の T2 ヒントを指定することは、テーブル NO_HASH_JOIN_BUILDING に T1 を指定するのと同じ効果があります。

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

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

JOIN_FIXED_ORDER

クエリ内のテーブルが、クエリにリストされている順序に基づいて結合されるように指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。これは、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

クエリ内のテーブルの結合順序を指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。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

結合順序の先頭に配置するテーブルを指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。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

結合順で最後に配置するテーブルを指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。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 を使用して、グローバルトランザクション ID (GTID) に基づきレプリケーションを使用する方法については、「Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

トピック

• mysql.rds_set_master_auto_position
• mysql.rds_set_external_master_with_auto_position
• mysql.rds_skip_transaction_with_gtid

mysql.rds_set_master_auto_position

バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTID) ベースのレプリケーションモードを設定します。

Syntax

CALL mysql.rds_set_master_auto_position (auto_position_mode);

Parameters

auto_position_mode

ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値。

• 0 – バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルト: 0。

• 1 – GTID ベースのレプリケーション方法を使用します。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

マスターユーザーが mysql.rds_set_master_auto_position を実行する必要があります。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.04 以降の MySQL 5.7 互換バージョンでサポートされています。GTID ベースのレプリケーションは、Aurora MySQL 1.1 または 1.0 ではサポートされていません。

mysql.rds_set_external_master_with_auto_position

外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTID) に基づき、レプリケーションが設定されます。

このプロシージャは RDS for MySQL と Aurora MySQL のいずれでも使用できます。動作は、コンテキストによって異なります。Aurora MySQL とともに使用した場合、この手順では遅延レプリケーションは設定されません。このように制限されるのは、遅延レプリケーションが RDS for MySQL ではサポートされているが Aurora MySQL ではサポートされていないためです。

Syntax

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

Parameters

host_name

レプリケーションマスターとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。

host_port

Aurora の外部で動作する MySQL インスタンス (レプリケーションマスター) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。

replication_user_name

Aurora の外部で実行される MySQL インスタンスの REPLICATION CLIENT および REPLICATION SLAVE のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。

replication_user_password

replication_user_name で指定されたユーザー ID のパスワード。

ssl_encryption

このオプションは、現在実装されていません。デフォルトは 0 です。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

マスターユーザーが mysql.rds_set_external_master_with_auto_position を実行する必要があります。マスターユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこの手順を実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.04 以降の MySQL 5.7 互換バージョンでサポートされています。GTID ベースのレプリケーションは、Aurora MySQL 1.1 または 1.0 ではサポートされていません。

mysql.rds_set_external_master_with_auto_position を実行する前に、外部の MySQL DB インスタンスがレプリケーションマスターになるように設定します。外部の 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'
   

2. 外部の MySQL インスタンスで、REPLICATION CLIENT と REPLICATION SLAVE の特権をレプリケーションユーザーに付与します。次の例では、ドメインの REPLICATION CLIENT ユーザーに、すべてのデータベースの REPLICATION SLAVE および 'repl_user' 特権を付与します。

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

mysql.rds_set_external_master_with_auto_position を呼び出すと、Amazon RDS によって特定の情報が記録されます。この情報には、時刻、ユーザー、"set master" の mysql.rds_history テーブルの mysql.rds_replication_status のアクションがあります。

問題の原因となることが知られている特定の GTID ベースの処理をスキップするには、mysql.rds_skip_transaction_with_gtid ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

Examples

Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。

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 トランザクションが問題の原因となることが知られている場合、障害復旧のためにこのプロシージャを使用できます。このストアドプロシージャを使用して、問題となるトランザクションをスキップします。問題のあるトランザクションの例には、レプリケーションを無効にしたり、重要なデータを削除したり、DB インスタンスを利用不可にするトランザクションが含まれます。

Syntax

CALL mysql.rds_skip_transaction_with_gtid (gtid_to_skip);

Parameters

gtid_to_skip

スキップするレプリケーショントランザクションの GTID。

使用に関する注意事項

Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。

マスターユーザーが mysql.rds_skip_transaction_with_gtid を実行する必要があります。

Aurora では、このプロシージャは Aurora MySQL バージョン 2.04 以降の MySQL 5.7 互換バージョンでサポートされています。GTID ベースのレプリケーションは、Aurora MySQL 1.1 または 1.0 ではサポートされていません。