設定パラメータ Aurora MySQL に適用されない MySQL パラメータ Aurora MySQL に適応されない MySQL ステータス可変 Aurora MySQL の待機イベント Aurora MySQL スレッド状態 Aurora MySQL の分離レベル Aurora MySQL のヒント Aurora MySQL ストアドプロシージャ Aurora MySQL information_schema テーブル

Amazon Aurora MySQL のリファレンス

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

トピック

Aurora MySQL 設定パラメータ
Aurora MySQL に適用されない MySQL パラメータ
Aurora MySQL に適応されない MySQL ステータス可変
Aurora MySQL の待機イベント
Aurora MySQL スレッド状態
Aurora MySQL の分離レベル
Aurora MySQL のヒント
Aurora MySQL ストアドプロシージャ
Aurora MySQL — 固有の information_schema テーブル

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 の DB クラスターパラメータグループを変更するコマンドを使用します。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 パラメータグループの詳細については、「パラメータグループを使用する」を参照してください。Aurora Serverless クラスターのルールおよび制限については、「Aurora Serverless v1 のパラメータグループ」を参照してください。

トピック

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

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

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

パラメータ名	変更可能	コメント
`aurora_binlog_read_buffer_size`	はい	バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。Aurora MySQL バージョン 3 から削除されました。
`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 MySQL バージョン 3 から削除されました。
`aurora_enable_replica_log_compression`	はい	詳細については、「Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項」を参照してください。Aurora Global Database の一部であるクラスターには適用されません。Aurora MySQL バージョン 3 から削除されました。
`aurora_enable_repl_bin_log_filtering`	はい	詳細については、「Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項」を参照してください。Aurora Global Database の一部であるクラスターには適用されません。Aurora MySQL バージョン 3 から削除されました。
`aurora_enable_staggered_replica_restart`	はい	この設定は Aurora MySQL バージョン 1 と 3 で使用できますが、使用されていません。
`aurora_enable_zdr`	はい	Aurora MySQL 2.10 以降では、この設定はデフォルトでオンになっています。詳細については、「ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)」を参照してください。
`aurora_load_from_s3_role`	はい	詳細については、「Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード」を参照してください。現在、Aurora MySQL バージョン 3 では使用できません。`aws_default_s3_role` を使用します。
`aurora_select_into_s3_role`	はい	詳細については、「Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存」を参照してください。現在、Aurora MySQL バージョン 3 では使用できません。`aws_default_s3_role` を使用します。
`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 のリリースノートの「Aurora MySQL データベースエンジンの更新 2020-09-02 (バージョン 1.23.0)」および「Aurora MySQL データベースエンジンの更新 2020-03-05 (バージョン 1.22.2)」を参照してください。
`binlog-do-db`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`binlog_format`	はい	詳細については、「Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)」を参照してください。
`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_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 バージョン 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.04 以降で変更可能です。
`event_scheduler`	はい	イベントスケジューラのステータスを示します。 Aurora MySQL バージョン 3 では、クラスターレベルでのみ変更できます。
`gtid-mode`	時々	Aurora MySQL バージョン 2.04 以降で変更可能です。
`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 バージョン 3 でデッドロック検出を無効化するために使用されます。高並行性システムでは、多数のスレッドが同じロックを待機すると、デッドロック検出によって速度が低下する可能性があります。MySQL パラメータの詳細については、MySQL のドキュメントを参照してください。
`innodb_file_per_table`	はい	このパラメータは、テーブルストレージの編成方法に影響します。詳細については、「ストレージのスケーリング」を参照してください。
`innodb_flush_log_at_trx_commit`	Aurora MySQL バージョン 1 および 2: はい Aurora MySQL バージョン 3: いいえ	Aurora MySQL バージョン 1 と 2 では、デフォルト値の 1 を使用することを強く推奨します。 Aurora MySQL バージョン 3 では、Aurora は常にデフォルト値の 1 を使用します。詳細については、「ログバッファをフラッシュする頻度の設定」を参照してください。
`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`	はい	Aurora MySQL バージョン 3 から削除されました。
`innodb_sync_array_size`	はい
`innodb_sync_spin_loops`	はい
`innodb_table_locks`	はい
`innodb_undo_directory`	いいえ	Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。
`innodb_undo_logs`	はい	Aurora MySQL バージョン 3 から削除されました。
`innodb_undo_tablespaces`	いいえ	Aurora MySQL バージョン 3 から削除されました。
`internal_tmp_mem_storage_engine`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`key_buffer_size`	はい	MyISAM テーブルのキーキャッシュ。詳しい情報については、「keycache->cache_lock mutex ミューテックス」を参照してください。
`lc_time_names`	はい
`lower_case_table_names`	はい (Aurora MySQL バージョン 1 および 2)、クラスター作成時のみ (Aurora MySQL バージョン 3)	Aurora MySQL バージョン 2.10 以降では、この設定を変更し、ライターインスタンスを再起動した後、すべてのリーダーインスタンスを再起動してください。詳細については、「Aurora MySQL クラスタの再起動 (バージョン 2.10 以降)」を参照してください。Aurora MySQL バージョン 3 では、このパラメータ値はクラスターの作成時に永続的に設定されます。このオプションにデフォルト以外の値を使用する場合は、アップグレードする前に Aurora MySQL バージョン 3 カスタムパラメータグループを設定し、バージョン 3 クラスターを作成するスナップショットの復元操作中にパラメータグループを指定します。
`master-info-repository`	はい	Aurora MySQL バージョン 3 から削除されました。
`master_verify_checksum`	はい	Aurora MySQL バージョン 1 および 2。`source_verify_checksum` を Aurora MySQL バージョン 3 で使用する。
`partial_revokes`	いいえ	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`relay-log-space-limit`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`replica_preserve_commit_order`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`replica_transaction_retries`	はい	このパラメータは、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 DB クラスターでの SSL/TLS の使用」を参照してください。
`rpl_read_size`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`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 クラスターにのみ適用されます。
`source_verify_checksum`	はい	Aurora MySQL バージョン 3 以降
`sync_frm`	はい	Aurora MySQL バージョン 3 から削除されました。
`time_zone`	はい
`tls_version`	はい	詳細については、「Aurora MySQL の TLS バージョン」を参照してください。

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

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

パラメータ名	変更可能	コメント
`activate_all_roles_on_login`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`allow-suspicious-udfs`	いいえ
`aurora_lab_mode`	はい	詳細については、「Amazon Aurora MySQL ラボモード」を参照してください。Aurora MySQL バージョン 3 から削除されました。
`aurora_oom_response`	はい	このパラメータは、Aurora MySQL バージョン 1.18 以降にのみ適用されます。Aurora MySQL バージョン 2 または 3 では使用されません。詳細については、「 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`	はい
`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 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`	はい	デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「DB パラメータ式の変数」を参照してください。
`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 バージョン 3 でデッドロック検出を無効化するために使用されます。高並行性システムでは、多数のスレッドが同じロックを待機すると、デッドロック検出によって速度が低下する可能性があります。MySQL パラメータの詳細については、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`	はい
`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` の最小値を評価します。次に、その最小値をタイムアウトとして使用して、対話型と非対話型の両方のアイドル状態のセッションをすべて終了します。
`internal_tmp_mem_storage_engine`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。
`join_buffer_size`	はい
`keep_files_on_create`	はい
`key_buffer_size`	はい	MyISAM テーブルのキーキャッシュ。詳しい情報については、「keycache->cache_lock mutex ミューテックス」を参照してください。
`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`	はい	Aurora MySQL バージョン 3 から削除されました。
`log_error`	いいえ
`log_output`	はい
`log_queries_not_using_indexes`	はい
`log_slave_updates`	いいえ	Aurora MySQL バージョン 1 および 2。`log_replica_updates` を Aurora MySQL バージョン 3 で使用する。
`log_replica_updates`	いいえ	Aurora MySQL バージョン 3 以降
`log_throttle_queries_not_using_indexes`	はい
`log_warnings`	はい	Aurora MySQL バージョン 3 から削除されました。
`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`	はい	デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「DB パラメータ式の変数」を参照してください。インスタンスクラスに応じたデフォルト値については、「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`	はい	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`	はい
`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 を使用する際のベストプラクティス」を参照してください。
`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`	はい	Aurora MySQL バージョン 3 から削除されました。
`query_cache_min_res_unit`	はい	Aurora MySQL バージョン 3 から削除されました。
`query_cache_size`	はい	デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「DB パラメータ式の変数」を参照してください。 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 は、クラスターの種類に基づき、DB インスタンスの読み取り専用と読み書きの状態を管理します。例えば、プロビジョンされたクラスターに読み書きの DB インスタンス (プライマリインスタンス) が 1 つあり、クラスターのそれ以外のインスタンスは読み取り専用 (Aurora レプリカ) です。このパラメータを変更することで、ライターインスタンスを読み取り専用状態に切り替えることができます。このパラメータ値に関係なく、リーダーインスタンスは常に読み取り専用状態になります。
`read_rnd_buffer_size`	はい
`relay-log`	いいえ
`relay_log_info_repository`	はい	Aurora MySQL バージョン 3 から削除されました。
`relay_log_recovery`	いいえ
`safe-user-create`	はい
`secure_auth`	はい	Aurora MySQL バージョン 3 から削除されました。
`secure_file_priv`	いいえ	Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。
`skip-slave-start`	いいえ
`skip_external_locking`	いいえ
`skip_show_database`	はい
`slave_checkpoint_group`	はい	Aurora MySQL バージョン 1 および 2。`replica_checkpoint_group` を Aurora MySQL バージョン 3 で使用する。
`replica_checkpoint_group`	はい	Aurora MySQL バージョン 3 以降
`slave_checkpoint_period`	はい	Aurora MySQL バージョン 1 および 2。`replica_checkpoint_period` を Aurora MySQL バージョン 3 で使用する。
`replica_checkpoint_period`	はい	Aurora MySQL バージョン 3 以降
`slave_parallel_workers`	はい	Aurora MySQL バージョン 1 および 2。`replica_parallel_workers` を Aurora MySQL バージョン 3 で使用する。
`replica_parallel_workers`	はい	Aurora MySQL バージョン 3 以降
`slave_pending_jobs_size_max`	はい	Aurora MySQL バージョン 1 および 2。`replica_pending_jobs_size_max` を Aurora MySQL バージョン 3 で使用する。
`replica_pending_jobs_size_max`	はい	Aurora MySQL バージョン 3 以降
`replica_skip_errors`	はい	Aurora MySQL バージョン 3 以降
`slave_sql_verify_checksum`	はい	Aurora MySQL バージョン 1 および 2。`replica_sql_verify_checksum` を Aurora MySQL バージョン 3 で使用する。
`replica_sql_verify_checksum`	はい	Aurora MySQL バージョン 3 以降
`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_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` 値がどのように計算されるかにいては、「DB パラメータ式の変数」を参照してください。
`table_open_cache`	はい	デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「DB パラメータ式の変数」を参照してください。
`table_open_cache_instances`	はい
`temp-pool`	はい	Aurora MySQL バージョン 3 から削除されました。
`temptable_max_mmap`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。詳細については、「Aurora MySQL バージョン 3 での新しい一時テーブルの動作」を参照してください。
`temptable_max_ram`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。詳細については、「Aurora MySQL バージョン 3 での新しい一時テーブルの動作」を参照してください。
`temptable_use_mmap`	はい	このパラメータは、Aurora MySQL バージョン 3 以降にのみ適用されます。詳細については、「Aurora MySQL バージョン 3 での新しい一時テーブルの動作」を参照してください。
`thread_handling`	いいえ
`thread_stack`	はい
`timed_mutexes`	はい
`tmp_table_size`	はい
`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 バージョン 1 および 2 には適用されません。Aurora MySQL バージョン 3 で利用可能です。
big_tables
bind_address
character_sets_dir
innodb_adaptive_flushing
innodb_adaptive_flushing_lwm
innodb_buffer_pool_chunk_size
innodb_buffer_pool_instances
innodb_change_buffering
innodb_checksum_algorithm
innodb_data_file_path
innodb_deadlock_detect – このパラメータは、Aurora MySQL バージョン 1 および 2 には適用されません。Aurora MySQL バージョン 3 で利用可能です。
innodb_dedicated_server
innodb_default_row_format
innodb_doublewrite
innodb_flush_log_at_timeout – このパラメータは Aurora MySQL には適用されません。詳細については、「ログバッファをフラッシュする頻度の設定」を参照してください。
innodb_flush_method
innodb_flush_neighbors
innodb_io_capacity
innodb_io_capacity_max
innodb_log_buffer_size
innodb_log_file_size
innodb_log_files_in_group
innodb_log_spin_cpu_abs_lwm
innodb_log_spin_cpu_pct_hwm
innodb_max_dirty_pages_pct
innodb_numa_interleave
innodb_page_size
innodb_redo_log_capacity
innodb_redo_log_encrypt
innodb_undo_log_encrypt
innodb_undo_log_truncate
innodb_use_native_aio
innodb_write_io_threads
thread_cache_size

Aurora MySQL に適応されない MySQL ステータス可変

Aurora MySQL と MySQL ではアーキテクチャに違いがあるため、一部の MySQL パラメータのステータス可変は Aurora MySQL に適用されません。

以下の MySQL ステータス可変は Aurora MySQL には適用されません。これはすべてを網羅したリストではありません。

innodb_buffer_pool_bytes_dirty
innodb_buffer_pool_pages_dirty
innodb_buffer_pool_pages_flushed

Aurora MySQL バージョン 3 は、Aurora MySQL バージョン 2 にあった次のステータス可変を削除します。

AuroraDb_lockmgr_bitmaps0_in_use
AuroraDb_lockmgr_bitmaps1_in_use
AuroraDb_lockmgr_bitmaps_mem_used
AuroraDb_thread_deadlocks
available_alter_table_log_entries
Aurora_lockmgr_memory_used
Aurora_missing_history_on_replica_incidents
Aurora_new_lock_manager_lock_release_cnt
Aurora_new_lock_manager_lock_release_total_duration_micro
Aurora_new_lock_manager_lock_timeout_cnt
Aurora_oom_response
Aurora_total_op_memory
Aurora_total_op_temp_space
Aurora_used_alter_table_log_entries
Aurora_using_new_lock_manager
Aurora_volume_bytes_allocated
Aurora_volume_bytes_left_extent
Aurora_volume_bytes_left_total
Com_alter_db_upgrade
Compression
External_threads_connected
Innodb_available_undo_logs
Last_query_cost
Last_query_partial_plans
Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running
Time_since_zero_connections

これらの MySQL ステータス可変は Aurora MySQL バージョン 1 または 2 で使用できますが、Aurora MySQL バージョン 3 では使用できません。

Innodb_redo_log_enabled
Innodb_undo_tablespaces_total
Innodb_undo_tablespaces_implicit
Innodb_undo_tablespaces_explicit
Innodb_undo_tablespaces_active

Aurora MySQL の待機イベント

以下は、Aurora MySQL の代表的な待機イベントです。

注記

MySQL の待機イベントで使用される命名規則については、MySQL ドキュメントの「Performance Schema インストゥルメント命名規則」を参照してください。

cpu: 実行可能なアクティブな接続の数が vCPUs 数よりも一貫して多くなります。詳細については、「cpu」を参照してください。
io/aurora_redo_log_flush: セッションは Aurora ストレージにデータを保持しています。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。詳細については、「io/aurora_redo_log_flush」を参照してください。
io/aurora_respond_to_client: クエリ処理が完了し、次の Aurora MySQL バージョン 2.10.2 以降の 2.10 バージョン、2.09.3 以降の 2.09 バージョン、2.07.7 以降の 2.07 バージョン、1.22.6 以降の 1.22 バージョンで、結果がアプリケーションクライアントに返されます。DB インスタンスクラスのネットワーク帯域幅と、返される結果セットのサイズを比較します。また、クライアント側の応答時間もチェックしてください。クライアントが応答せず、TCP パケットを処理できない場合、パケットドロップと TCP 再送信が発生する可能性があります。この状況は、ネットワーク帯域幅に悪影響を及ぼします。2.10.2、2.09.3、2.09.3、2.07.7、および 1.22.6 より前のバージョンでは、この待機イベントにアイドル時間が誤って含まれます。この待機が目立つときにデータベースをチューニングする方法については、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 バッファプールからは満たすことができないデータをリクエストしている可能性があります。詳細については、「io/file/innodb/innodb_data_file」を参照してください。
io/file/sql/binlog: スレッドは、ディスクに書き込まれるバイナリログ (binlog) ファイルを待っています。
io/socket/sql/client_connection: mysqld プログラムは受信する新規クライアント接続を処理するためのスレッド作成でビジー状態です。詳細については、「io/socket/sql/client_connection」を参照してください。
io/table/sql/handler: エンジンは、テーブルへのアクセスを待っています。このイベントは、データがバッファプールにキャッシュされているか、ディスク上でアクセスされているかにかかわらず、発生します。詳細については、「io/table/sql/handler」を参照してください。
lock/table/sql/handler: この待機イベントは、テーブルロック待機イベントハンドラです。Performance Schema の原始的イベントと分子的イベントの詳細については、MySQL ドキュメントの Performance Schema の原子的および分子的イベントを参照してください。
synch/cond/mysys/my_thread_var::suspend: 別のスレッドが LOCK TABLES ... READ を発行したため、テーブルレベルのロックを待っている間にスレッドが中断されます。
synch/cond/sql/MDL_context::COND_wait_status: スレッドは、テーブルのメタデータロックを待っています。エンジンは、このタイプのロックを使用して、データベーススキーマへの同時アクセスを管理し、データの整合性を確保します。詳細については、MySQL ドキュメントの「ロック操作の最適化」を参照してください。この待機が目立つときにデータベースをチューニングする方法については、synch/cond/sql/MDL_context::COND_wait_status を参照してください。
synch/cond/sql/MYSQL_BIN_LOG::COND_done: バイナリログを有効にしている。高いコミットスループット、多数のトランザクションがコミットされている、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログレプリケーションや aurora_binlog_* パラメータの代わりにグローバルデータベースを使用します。
synch/mutex/innodb/aurora_lock_thread_slot_futex: 複数のデータ操作言語 (DML) ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「synch/mutex/innodb/aurora_lock_thread_slot_futex」を参照してください。
synch/mutex/innodb/buf_pool_mutex: バッファープールが、ワーキングデータセットを保持するのに十分な大きさではなありません。または、ワークロードが特定のテーブルからページにアクセスし、バッファプール内で競合が発生します。詳細については、「synch/mutex/innodb/buf_pool_mutex」を参照してください。
synch/mutex/innodb/fil_system_mutex: プロセスは、テーブルスペースのメモリー・キャッシュへのアクセスを待っています。詳細については、「synch/mutex/innodb/fil_system_mutex」を参照してください。
synch/mutex/innodb/os_mutex: このイベントは、イベントセマフォの一部です。スレッド間のシグナリングに使用される可変への排他的アクセスを提供します。使用方法には、統計スレッド、全文検索、バッファプールのダンプとロード操作、ログフラッシュなどがあります。この待機イベントは Aurora MySQL バージョン 1 の固有のものです。
synch/mutex/innodb/trx_sys_mutex: オペレーションは、一貫した、または制御された方法で InnoDB 内のトランザクション ID をチェック、更新、削除、または追加しています。これらの操作は trx_sys mutex 呼び出しを必要とします。これはパフォーマンススキーマインストルメンテーションによって追跡されます。操作には、データベースの起動時またはシャットダウン時のトランザクションシステムの管理、ロールバック、クリーンアップの取り消し、行の読み取りアクセス、およびバッファプールのロードが含まれます。トランザクション数が多い高データベースロードは、この待機イベントの頻繁な発生につながります。詳細については、「synch/mutex/innodb/trx_sys_mutex」を参照してください。
synch/mutex/mysys/key_cache። cache_lock: keycache->cache_lock mutex は MyISAM テーブルのキーキャッシュへのアクセスを制御します。Aurora MySQL では MyISAM テーブルを使用して永続データを保存することはできませんが、内部一時テーブルの保存に使用されます。状況によっては、一時テーブルがメモリに収まらなくなるとディスクに書き込まれることがあるため、created_tmp_tables または created_tmp_disk_tables ステータスカウンタを確認することを検討してください。
synch/mutex/sql/file_as_table። LOCK_offsets: エンジンは、テーブルメタデータファイルを開いたり作成したりするときに、このミューテックスを取得します。この待機イベントが過剰な頻度で発生すると、作成またはオープンされているテーブルの数が急増しています。
synch/mutex/sql/FILE_AS_TABLE::LOCK_shim_lists: エンジンは、reset_size、detach_contents、または add_contents のようなオペレーションを、オープンテーブルを追跡する内部構造上で実行しながら、このミューテックスを取得します。ミューテックスは、リストの内容へのアクセスを同期します。この待機イベントが高頻度で発生すると、以前にアクセスされたテーブルのセットが突然変化したことを示します。エンジンは、新しいテーブルにアクセスするか、以前にアクセスしたテーブルに関連するコンテキストを解放する必要があります。
synch/mutex/sql/LOCK_open: セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「MySQL でのテーブルのオープンとクローズの方法」を参照してください。
synch/mutex/sql/LOCK_table_cache: セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「MySQL でのテーブルのオープンとクローズの方法」を参照してください。
synch/mutex/sql/LOG: この待機イベントの場合、ログロックの待機中のスレッドがあります。例えば、スレッドは、スロークエリログファイルに書き込むためにロックを待っている場合があります。
synch/mutex/sql/MYSQL_BIN_LOG::LOCK_commit: この待機イベントの場合、バイナリログにコミットする目的でロック取得を待機中のスレッドがあります。変化率が非常に高いデータベースではバイナリログ記録の競合が発生する場合がありえます。使用している MySQL のバージョンによっては、バイナリログの整合性と耐久性の高いを保護するために使用される特定のロックがあります。RDS for MySQL の場合、バイナリログはレプリケーションと自動バックアッププロセスに使用されます。Aurora MySQL の場合、バイナリログはネイティブのレプリケーションやバックアップに必要ありません。バイナリログはデフォルトで無効になっていますが、これを有効にして外部のレプリケーションや変更データのキャプチャに使用できます。詳細については、MySQL ドキュメントの「バイナリログ」を参照してください。
sync/mutex/sql/MYSQL_BIN_LOG። LOCK_dump_thread_metrics_collection: バイナリログ記録がオンの場合、エンジンはアクティブなダンプスレッドのメトリクスをエンジンエラーログと内部オペレーションマップに出力する際、このミューテックスを取得します。
sync/mutex/sql/MYSQL_BIN_LOG። LOCK_inactive_binlogs_map: バイナリログ記録がオンの場合、エンジンは最新のバイナリログファイルのリストに追加したり、そこから削除したり、検索したりする際に、このミューテックスを取得します。
sync/mutex/sql/MYSQL_BIN_LOG። LOCK_io_cache: バイナリログがオンの場合、エンジンは Aurora binlog IO キャッシュ操作(割り当て、サイズ変更、解放、書き込み、読み取り、パージ、およびキャッシュ情報へのアクセス) 中にこのミューテックスを取得します。このイベントが頻繁に発生する場合、エンジンは binlog イベントが格納されているキャッシュにアクセスしています。待機時間を短縮するには、コミットを減らします。複数のステートメントを 1 つのトランザクションにグループ化してみてください。
synch/mutex/sql/MYSQL_BIN_LOG::LOCK_log: バイナリログを有効にしている。高いコミットスループット、多数のコミットしているトランザクション、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログレプリケーションや aurora_binlog_* パラメータの代わりにグローバルデータベースを使用します。
synch/mutex/sql/server_thread። LOCK_sync: ミューテックス SERVER_THREAD::LOCK_sync はファイル書き込みスレッドのスケジューリング、処理、または起動中に取得されます。この待機イベントが過剰に発生すると、データベース内の書き込みアクティビティが増加していることを示します。
synch/mutex/sql/TABLESPACES:lock: エンジンは、作成、削除、トランケート、および拡張のテーブルスペースオペレーション中に TABLESPACES:lock ミューテックスを取得します。この待機イベントが過剰に発生すると、テーブルスペース操作の頻度が高いことを示します。例として、大量のデータをデータベースにロードしています。
synch/rwlock/innodb/dict: この待機イベントの場合、InnoDB データディクショナリに保持されている rwlock を待機中のスレッドがあります。
synch/rwlock/innodb/dict_operation_lock: この待機イベントの場合、InnoDB データディクショナリのオペレーションのロックを保持しているスレッドがあります。
synch/rwlock/innodb/dict sys RW lock: データ定義言語コード (DDLs) 内の多数の同時データ制御言語ステートメント (DCLs) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDL への依存度を下げます。
synch/rwlock/innodb/hash_table_locks: この待機イベントの過剰な発生は、バッファキャッシュをマッピングするハッシュテーブルの変更に競合があることを示します。バッファキャッシュのサイズを増やし、関連するクエリのアクセスパスを改善することを検討してください。この待機が目立つときにデータベースをチューニングする方法については、synch/rwlock/innodb/hash_table_locks を参照してください。
synch/rwlock/innodb/index_tree_rw_lock: 複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。
synch/sxlock/innodb/dict_operation_lock: データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。
synch/sxlock/innodb/dict_sys_lock: データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。
synch/sxlock/innodb/hash_table_locks: セッションは、バッファプール内のページを見つけることができませんでした。エンジンは、ファイルを読み取るか、バッファープールの最も長い時間使われていない (LRU) リストを変更する必要があります。バッファキャッシュのサイズを増やし、関連するクエリのアクセスパスを改善することを検討してください。
synch/sxlock/innodb/index_tree_rw_lock: 複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。

同期待機イベントのトラブルシューティングの詳細は、「Performance Insights で SYNCH 待機イベントを待機しているアクティブセッションの数が多いことが MySQL DB インスタンスに表示されているのはなぜですか?」を参照してください。

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 です。
HEAP をオンディスクに変換する: スレッドは、内部一時テーブルをインメモリテーブルからディスク上のテーブルに変換しています。
tmp テーブルにコピーする: スレッドが ALTER TABLE ステートメントを処理中です。この状態は、新しい構造を持つテーブルが作成された後、ローがそのテーブルにコピーされる前に発生します。この状態のスレッドの場合、パフォーマンススキーマを使用して、コピー操作の進行状況に関する情報を取得できます。
ソートインデックスの作成: Aurora MySQL は、既存のインデックスを使用してクエリの ORDER BY および GROUP BY 句を満たすことができないため、ソートを実行しています。詳細については、「ソートインデックスの作成」を参照してください。
テーブルの作成: スレッドは、永続テーブルまたは一時テーブルを作成しています。
遅延コミット ok 完了: Aurora MySQL の非同期コミットが承認を受け取り、完了しました。
遅延コミット ok スタートしました: Aurora MySQL スレッドは非同期コミットプロセスをスタートしましたが、確認を待っています。これは通常、トランザクションの本物のコミット時間です。
遅延送信 ok 完了: 接続に関連付けられている Aurora MySQL ワーカースレッドは、応答がクライアントに送信されている間に解放できます。スレッドは他の作業をスタートできます。ステータス delayed send okはクライアントへの非同期確認が完了したことを示します。
遅延送信「ok」をスタートしました: Aurora MySQL ワーカースレッドがクライアントに非同期で応答を送信し、他の接続で自由に作業できるようになりました。トランザクションは、まだ確認されていない非同期コミットプロセスをスタートしました。
実行中: スレッドはステートメントの実行をスタートしました。
アイテムを解放する: スレッドがコマンドを実行しました。この状態中に行われた項目の解放には、クエリキャッシュが含まれます。この状態は通常、クリーンアップが続きます。
初期化: この状態は、ALTER TABLE、DELETE、INSERT、SELECT、または UPDATE ステートメントの初期化前に発生します。この状態のアクションには、バイナリログまたは InnoDB ログのフラッシュ、クエリキャッシュのクリーンアップが含まれます。
マスターがすべてのバイナリログをスレーブに送信しました: プライマリノードはレプリケーションの一部を終了しました。スレッドは、バイナリログ (binlog) に書き込むことができるように、より多くのクエリが実行されるのを待っています。
テーブルを開く: スレッドがテーブルを開こうとしている。ALTER TABLE または LOCK TABLE ステートメントを終了する必要がある場合や、 table_open_cache の値を超える場合を除いて、このオペレーションは早いです。
最適化: サーバーはクエリの初期最適化を実行しています。
準備: この状態は、クエリの最適化中に発生します。
クエリ終了: この状態は、クエリの処理後、アイテム解放状態の前に発生します。
重複を除去する: Aurora MySQL はクエリの初期段階でDISTINCT オペレーションを最適化できませんでした。Aurora MySQL は、結果をクライアントに送信する前に、重複した行をすべて削除する必要があります。
更新の行の検索: スレッドは更新する前に一致する行をすべて検索しています。この段階は、エンジンが行の検索に使用するインデックスを UPDATE が変更している時に必要です。
バイナリログイベントをスレーブに送信する: スレッドはバイナリログからイベントを読み取り、それをレプリカに送信しています。
キャッシュされた結果をクライアントに送信する: サーバーは、クエリキャッシュからクエリの結果を取得し、それをクライアントに送信しています。
データの送信: スレッドは、SELECT ステートメントの行を読み取り、処理していますが、クライアントへのデータの送信はまだスタートされていません。このプロセスでは、クエリを満たすために必要な結果が含まれているページを特定します。詳細については、「データの送信」を参照してください。
クライアントに送信する: サーバーはクライアントにパケットを書き込んでいます。以前のバージョンの MySQL では、この待機イベントは writing to net としてラベル付けされていました。
スタート中: これは、ステートメントの実行スタートの初期の段階です。
統計: サーバーは統計を計算して、クエリ実行プランを開発しています。スレッドが長時間この状態にある場合、サーバーは他の作業の実行中にディスクバインドされている可能性があります。
クエリキャッシュに結果を格納する: サーバーは、クエリの結果をクエリキャッシュに格納しています。
システムロック: スレッドは 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 クラスターの 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 の 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 Global Database 内のセカンダリクラスター内のセッションでは使用できません。書き込み転送の詳細については、「Amazon Aurora Global Database の書き込み転送を使用する」を参照してください。

リーダーでの READ COMMITTED の有効化

Aurora レプリカでの READ COMMITTED 分離レベルを有効にするには、aurora_read_replica_read_committed 構成設定を有効にします。特定の Aurora レプリカに接続しているときに、セッションレベルでこの設定を有効にします。有効にするには、以下の SQL コマンドを実行します。


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

この構成設定を一時的に有効にして、インタラクティブなアドホック (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 バージョン 3 では、コミュニティ MySQL 8.0 で利用可能なすべてのヒントを使用できます。これらのヒントの詳細については、を参照してください。オプティマイザーヒントのMySQL リファレンスマニュアル。

これらのヒントは、Aurora MySQL 2.08 以降で使用可能です。これらのヒントは、Aurora MySQL バージョン 2 のハッシュ結合特徴を使用するクエリ、特にパラレルクエリ最適化を使用するクエリに適用されます。

HASH_JOIN、NO_HASH_JOIN

クエリにハッシュ結合最適化メソッドを使用するかどうかをオプティマイザが選択する機能をオンまたはオフにします。HASH_JOIN は、そのメカニズムがより効率的である場合、オプティマイザがハッシュ結合を使用できるようにします。NO_HASH_JOIN は、オプティマイザがクエリにハッシュ結合を使用できないようにします。このヒントは、Aurora MySQL 2.08 以降で使用可能です。Aurora MySQL バージョン 3 では効果がありません。

以下の例では、このヒントの使用方法を示します。


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

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

HASH_JOIN_PROBING、NO_HASH_JOIN_PROBING

ハッシュ結合クエリで、結合のプローブ側に指定されたテーブルを使用するかどうかを指定します。クエリは、プローブテーブルの内容全体を読み取る代わりに、構築テーブルの列値がプローブテーブルに存在するかどうかをテストします。HASH_JOIN_PROBING および HASH_JOIN_BUILDING を使用して、クエリテキスト内のテーブルを並べ替えることなく、ハッシュ結合クエリの処理方法を指定できます。このヒントは、Aurora MySQL 2.08 以降で使用可能です。Aurora MySQL バージョン 3 では効果がありません。

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


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

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

HASH_JOIN_BUILDING、NO_HASH_JOIN_BUILDING

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

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


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

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

JOIN_FIXED_ORDER

クエリ内のテーブルが、クエリにリストされている順序に基づいて結合されるように指定します。これは、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 (GTIDs) に基づきレプリケーションを使用する方法については、「Amazon Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

トピック

mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL バージョン 3 以降)
mysql.rds_set_master_auto_position (Aurora MySQL バージョン 1 および 2)
mysql.rds_set_source_auto_position (Aurora MySQL バージョン3以上)
mysql.rds_set_external_master_with_auto_position (Aurora MySQL バージョン 1 および 2)
mysql.rds_set_external_source_with_auto_position (Aurora MySQL バージョン3以降)
mysql.rds_skip_transaction_with_gtid

mysql.rds_assign_gtids_to_anonymous_transactions (Aurora MySQL バージョン 3 以降)

構文


CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);

パラメータ

gtid_option: 文字列値。指定できる値は次のとおりです。OFF,LOCAL、または指定された UUID。

使用に関する注意事項

このプロシージャは、コミュニティMySQLでステートメントの発行と同じ効果がありますCHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option。

GTID をONに変える必要がありますにとってgtid_optionまたは設定されるLOCALまたは特定の UUIDに設定されます。

デフォルトは OFFです。この特徴が使用されていないことを意味します。

LOCALレプリカ独自の UUID を含む GTID を割り当てます (server_uuid設定)。

UUID であるパラメータを渡すと、指定された UUID を含む GTID が割り当てられます。server_uuidレプリケーション・ソース・サーバーの設定。

例

この特徴をオフにするには、次の手順を実行します:


mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('OFF');
+-------------------------------------------------------------+
| Message  |
+-------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: OFF |
+-------------------------------------------------------------+
1 row in set (0.07 sec)

レプリカ独自の UUID を使用するには、次の手順を実行します:


mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('LOCAL');
+---------------------------------------------------------------+
| Message  |
+---------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: LOCAL |
+---------------------------------------------------------------+
1 row in set (0.07 sec)

指定した UUID を使用するには、次の手順を実行します:


mysql> call mysql.rds_assign_gtids_to_anonymous_transactions('317a4760-f3dd-3b74-8e45-0615ed29de0e');
+----------------------------------------------------------------------------------------------+
| Message |
+----------------------------------------------------------------------------------------------+
| ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS has been set to: 317a4760-f3dd-3b74-8e45-0615ed29de0e |
+----------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)

mysql.rds_set_master_auto_position (Aurora MySQL バージョン 1 および 2)

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

構文


CALL mysql.rds_set_master_auto_position (auto_position_mode);

パラメータ

auto_position_mode

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

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

使用に関する注意事項

Aurora MySQL 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_source_auto_position (Aurora MySQL バージョン3以上)

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

構文


CALL mysql.rds_set_source_auto_position (auto_position_mode);

パラメータ

auto_position_mode

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

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

使用に関する注意事項

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

管理ユーザーは、mysql.rds_set_source_auto_positionプロシージャを実行しなければなりません。

mysql.rds_set_external_master_with_auto_position (Aurora MySQL バージョン 1 および 2)

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

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

構文


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

パラメータ

host_name: レプリケーションマスターとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
host_port: Aurora の外部で動作する MySQL インスタンス (レプリケーションマスター) で使用されるポート。ポート番号を変換する 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 ではサポートされていません。Aurora MySQL バージョン 3 の場合は、mysql.rds_set_external_source_with_auto_position代わりにプロシージャを使用します。

mysql.rds_set_external_master_with_auto_position を実行する前に、外部の MySQL DB インスタンスがレプリケーションマスターになるように設定します。外部の MySQL インスタンスに接続するには、replication_user_name および replication_user_password の値を指定します。これらの値を使用して、MySQL の外部インスタンスで REPLICATION CLIENT および REPLICATION SLAVE アクセス許可を持つレプリケーションユーザーを示す必要があります。

外部の MySQL インスタンスをレプリケーションマスターとして設定するには

選択した MySQL クライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
外部の MySQL インスタンスで、REPLICATION CLIENT と REPLICATION SLAVE の特権をレプリケーションユーザーに付与します。次の例では、ドメインの REPLICATION CLIENT ユーザーに、すべてのデータベースの REPLICATION SLAVE および 'repl_user' 特権を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```

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

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

例

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


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

mysql.rds_set_external_source_with_auto_position (Aurora MySQL バージョン3以降)

構文


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

パラメータ

host_name: レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
host_port: Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する 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_source_with_auto_positionプロシージャを実行しなければなりません。管理ユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこのプロシージャを実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。

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

mysql.rds_set_external_source_with_auto_position を実行する前に、外部の MySQL DB インスタンスがレプリケーションソースになるように設定します。外部の MySQL インスタンスに接続するには、replication_user_name および replication_user_password の値を指定します。これらの値を使用して、MySQL の外部インスタンスで REPLICATION CLIENT および REPLICATION SLAVE アクセス許可を持つレプリケーションユーザーを示す必要があります。

外部の MySQL インスタンスをレプリケーションソースとして設定するには

選択した MySQL クライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。次に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd'
```
外部の MySQL インスタンスで、REPLICATION CLIENT と REPLICATION SLAVE の特権をレプリケーションユーザーに付与します。次の例では、ドメインの REPLICATION CLIENT ユーザーに、すべてのデータベースの REPLICATION SLAVE および 'repl_user' 特権を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```

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

例


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

mysql.rds_skip_transaction_with_gtid

Aurora プライマリインスタンスで、指定されたグローバルトランザクション識別子 (GTID) のあるトランザクションのレプリケーションをスキップします。

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

構文


CALL mysql.rds_skip_transaction_with_gtid (gtid_to_skip);

パラメータ

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

使用に関する注意事項

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

マスターユーザーが mysql.rds_skip_transaction_with_gtidのプロシージャを実行する必要があります。

Aurora MySQL — 固有の information_schema テーブル

Aurora MySQL には、Aurora に固有の特定の information_schema テーブルがあります。

information_schema.replica_host_status

information_schema.replica_host_status テーブルにはレプリケーション情報が含まれています。使用できる列を以下のテーブルに示します。残りの列は Aurora 内部でのみ使用されます。

Column	データ型	説明
CPU	double	レプリカホストの CPU 使用率。
IS_CURRENT	tinyint	レプリカが最新かどうか。
LAST_UPDATE_TIMESTAMP	datetime(6)	前回の更新が行われた時刻。レコードが古くなっているかどうかを判断するために使用されます。
REPLICA_LAG_IN_MILLISECONDS	double	ミリ秒単位でのレプリカ遅延。
SERVER_ID	varchar(100)	データベースサーバーの ID。
SESSION_ID	varchar(100)	データベースセッションの ID。DB インスタンスがライターインスタンスかリーダーインスタンスかを判断するために使用されます。

注記

レプリカインスタンスが遅延すると、その information_schema.replica_host_status テーブルからクエリされる情報が古くなることがあります。このような状況では、代わりにライターインスタンスからクエリを実行することをお勧めします。

mysql.ro_replica_status テーブルにも同様の情報がありますが、使用することは推奨されません。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

Amazon Aurora MySQL を使用する際のベストプラクティス

Aurora MySQL の更新