# Amazon Aurora MySQL のリファレンス
このリファレンスには、Aurora MySQL パラメータ、ステータス可変、一般的な SQL 拡張に関する情報や、コミュニティ MySQL データベースエンジンとの相違点が含まれます。
**Topics**
+ [Aurora MySQL 設定パラメータ](AuroraMySQL.Reference.ParameterGroups.md)
+ [Aurora MySQL グローバルステータス変数](AuroraMySQL.Reference.GlobalStatusVars.md)
+ [Aurora MySQL の待機イベント](AuroraMySQL.Reference.Waitevents.md)
+ [Aurora MySQL スレッド状態](AuroraMySQL.Reference.thread-states.md)
+ [Aurora MySQL の分離レベル](AuroraMySQL.Reference.IsolationLevels.md)
+ [Aurora MySQL のヒント](AuroraMySQL.Reference.Hints.md)
+ [Aurora MySQL ストアドプロシージャリファレンス](AuroraMySQL.Reference.StoredProcs.md)
+ [Aurora MySQL — 固有の information\$1schema テーブル](AuroraMySQL.Reference.ISTables.md)
# Aurora MySQL 設定パラメータ
Amazon 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 マネジメントコンソール、AWS CLI、または Amazon RDS API を使用して管理できます。クラスターレベルのパラメータとインスタンスレベルのパラメータの管理には、別々のコマンドを使用します。例えば、DB クラスターパラメータグループのクラスターレベルのパラメータを管理するには、CLI の [DB クラスターパラメータグループを変更する](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster-parameter-group.html) コマンドを使用します。DB クラスターの DB インスタンスの DB パラメータグループのインスタンスレベルのパラメータを管理するには、CLI の [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) コマンドを使用します。
クラスターレベルのパラメータとインスタンスレベルのパラメータはいずれも、コンソール、CLI、または RDS API を使用して表示できます。例えば、DB クラスターパラメータグループのクラスターレベルのパラメータを表示するには、AWS CLI の [describe-db-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-parameters.html) コマンドを使用します。DB クラスターの DB インスタンスの DB パラメータグループのインスタンスレベルのパラメータを表示するには、CLI の [describe-db-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-parameters.html) コマンドを使用します。
**注記**
各[デフォルトのパラメータグループ](USER_WorkingWithParamGroups.md)には、パラメータグループ内のすべてのパラメータのデフォルト値が含まれます。パラメータのこの値に「エンジンのデフォルト」がある場合は、実際のデフォルト値については、バージョン固有の MySQL または PostgreSQL のドキュメントを参照してください。
特に明記されていない限り、次の表に記載されているパラメータは Aurora MySQL バージョン 2 および 3 で有効です。
DB パラメータグループの詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。Aurora Serverless v1 クラスターのルールおよび制限については、「[Aurora Serverless v1 のパラメータグループ](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups)」を参照してください。
**Topics**
+ [クラスターレベルのパラメータ](#AuroraMySQL.Reference.Parameters.Cluster)
+ [インスタンスレベルのパラメータ](#AuroraMySQL.Reference.Parameters.Instance)
+ [Aurora MySQL に適用されない MySQL パラメータ](#AuroraMySQL.Reference.Parameters.Inapplicable)
## クラスターレベルのパラメータ
次の表は、Aurora MySQL DB クラスター全体に適用されるすべてのパラメータを示しています。
| パラメータ名 | 変更可能 | コメント |
| --- | --- | --- |
| `aurora_binlog_read_buffer_size` | はい | バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。Aurora MySQL バージョン 3 から削除されました。 |
| `aurora_binlog_replication_max_yield_seconds` | あり | バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。 |
| `aurora_binlog_replication_sec_index_parallel_workers` | あり | 複数のセカンダリインデックスを持つ大きなテーブルのトランザクションを複製するときに、セカンダリインデックスの変更を適用できる並列スレッドの合計数を設定します。パラメータは、デフォルトで `0` (無効) に設定されています。 このパラメータは、Aurora MySQL バージョン 306 以降で使用できます。詳細については、「[Aurora MySQL でのバイナリログのレプリケーションの最適化](binlog-optimization.md)」を参照してください。 |
| `aurora_binlog_use_large_read_buffer` | あり | バイナリログ (binlog) レプリケーションを使用するクラスターにのみ影響します。バイナリログのレプリケーションの詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。Aurora MySQL バージョン 3 から削除されました。 |
| `aurora_disable_hash_join` | あり | Aurora MySQL バージョン 2.09 以降でハッシュ結合最適化を無効にするには、このパラメータを `ON` に設定します。バージョン 3 ではサポートされていません。詳細については、「[Amazon Aurora MySQL の並列クエリ](aurora-mysql-parallel-query.md)」を参照してください。 |
| `aurora_enable_replica_log_compression` | はい | 詳細については、「[Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance)」を参照してください。Aurora Global Database の一部であるクラスターには適用されません。Aurora MySQL バージョン 3 から削除されました。 |
| `aurora_enable_repl_bin_log_filtering` | あり | 詳細については、「[Amazon Aurora MySQL レプリケーションのパフォーマンスに関する考慮事項](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Performance)」を参照してください。Aurora Global Database の一部であるクラスターには適用されません。Aurora MySQL バージョン 3 から削除されました。 |
| `aurora_enable_staggered_replica_restart` | あり | この設定は、Aurora MySQL バージョン 3 で使用できますが、使用されていません。 |
| `aurora_enable_zdr` | あり | Aurora MySQL 2.10 以降では、この設定はデフォルトでオンになっています。詳細については、「[ダウンタイムのない再起動 (ZDR) (Amazon Aurora MySQL 用)](AuroraMySQL.Replication.Availability.md)」を参照してください。 |
| `aurora_enhanced_binlog` | あり | このパラメータの値を 1 に設定すると、Aurora MySQL バージョン 3.03.1 以降で拡張バイナリログがオンになります。詳細については、「[Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)」を参照してください。 |
| `aurora_jemalloc_background_thread` | あり | このパラメータを使用して、バックグラウンドスレッドがメモリメンテナンスオペレーションを実行できるようにします。指定できる値は `0` (無効) と `1` (有効) です。デフォルト値は `0` です。 このパラメータは、Aurora MySQL バージョン 3.05 以降に適用されます。 |
| `aurora_jemalloc_dirty_decay_ms` | あり | このパラメータを使用して、解放されたメモリを一定時間 (ミリ秒単位) 保持します。メモリを保持すると、より迅速に再利用できます。指定できる値は `0`～`18446744073709551615` です。デフォルト値 (`0`) は、すべてのメモリを解放可能なメモリとしてオペレーティングシステムに返します。 このパラメータは、Aurora MySQL バージョン 3.05 以降に適用されます。 |
| `aurora_jemalloc_tcache_enabled` | あり | このパラメータを使用して、スレッドローカルキャッシュ内の小さなメモリリクエスト (最大 32 KiB) を処理し、メモリアリーナをバイパスします。指定できる値は `0` (無効) と `1` (有効) です。デフォルト値は `1` です。 このパラメータは、Aurora MySQL バージョン 3.05 以降に適用されます。 |
| `aurora_load_from_s3_role` | あり | 詳細については、「[Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード](AuroraMySQL.Integrating.LoadFromS3.md)」を参照してください。現在、Aurora MySQL バージョン 3 では使用できません。`aws_default_s3_role` を使用します。 |
| `aurora_mask_password_hashes_type` | あり | Aurora MySQL 2.11 以降では、この設定はデフォルトでオンになっています。 この設定を使用して、スロークエリログ、監査ログで Aurora MySQL パスワードハッシュをマスクします。許容されている値は `0` と `1` (デフォルト) です。`1` に設定されている場合、パスワードは `` として記録されます。`0` に設定されている場合、パスワードはハッシュ (`#`) 値として記録されます。 |
| `aurora_select_into_s3_role` | あり | 詳細については、「[Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存](AuroraMySQL.Integrating.SaveIntoS3.md)」を参照してください。現在、Aurora MySQL バージョン 3 では使用できません。`aws_default_s3_role` を使用します。 |
| `authentication_kerberos_caseins_cmp` | あり | `authentication_kerberos` プラグインの大文字と小文字を区別しないユーザー名の比較を制御します。大文字と小文字を区別せずに比較するには、`true` に設定します。デフォルトでは、大文字と小文字を区別した比較が使用されます (`false`)。詳細については、「[Aurora MySQL での Kerberos 認証の使用](aurora-mysql-kerberos.md)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3.03 以降で使用できます。 |
| `auto_increment_increment` | はい | |
| `auto_increment_offset` | はい | |
| `aws_default_lambda_role` | はい | 詳細については、「[Amazon Aurora MySQL DB クラスターからの Lambda 関数の呼び出し](AuroraMySQL.Integrating.Lambda.md)」を参照してください。 |
| `aws_default_s3_role` | あり | DB クラスターから `LOAD DATA FROM S3` ステートメント、`LOAD XML FROM S3` ステートメント、または `SELECT INTO OUTFILE S3` ステートメントを呼び出すときに使用します。 Aurora MySQL バージョン 2 では、該当するステートメントの `aurora_load_from_s3_role` または `aurora_select_into_s3_role` に IAM ロールが指定されていない場合、このパラメータで指定された IAM ロールが使用されます。 Aurora MySQL バージョン 3 では、このパラメータに指定した IAM ロールが常に使用されます。 詳細については、「[IAM ロールと Amazon Aurora MySQL DB クラスターの関連付け](AuroraMySQL.Integrating.Authorizing.IAM.AddRoleToDBCluster.md)」を参照してください。 |
| `binlog_backup` | あり | このパラメータの値を 0 に設定すると、Aurora MySQL バージョン 3.03.1 以降で拡張バイナリログがオンになります。このパラメータは、拡張バイナリログを使用する場合にのみオフにできます。詳細については、「[Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)」を参照してください。 |
| `binlog_checksum` | あり | このパラメータが設定されていない場合、AWS CLI および RDS API は `None` の値をレポートします。この場合、Aurora MySQL はエンジンのデフォルト値である `CRC32` を使用します。これは、チェックサムを無効化する明示的な `NONE` の設定とは異なります。 |
| `binlog-do-db` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_format` | あり | 詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。 |
| `binlog_group_commit_sync_delay` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_group_commit_sync_no_delay_count` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog-ignore-db` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_replication_globaldb` | あり | このパラメータの値を 0 に設定すると、Aurora MySQL バージョン 3.03.1 以降で拡張バイナリログがオンになります。このパラメータは、拡張バイナリログを使用する場合にのみオフにできます。詳細については、「[Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)」を参照してください。 |
| `binlog_row_image` | いいえ | |
| `binlog_row_metadata` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_row_value_options` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_rows_query_log_events` | はい | |
| `binlog_transaction_compression` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_transaction_compression_level_zstd` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_transaction_dependency_history_size` | あり | このパラメータは、メモリに保持され、特定の行を最後に変更したトランザクションを検索するために使用される行ハッシュ数の上限を設定します。このハッシュ数に達すると、履歴はパージされます。 このパラメータは、Aurora MySQL バージョン 2.12 とバージョン 3 に適用されます。 |
| `binlog_transaction_dependency_tracking` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `character-set-client-handshake` | はい | |
| `character_set_client` | はい | |
| `character_set_connection` | はい | |
| `character_set_database` | はい | |
| `character_set_filesystem` | はい | |
| `character_set_results` | はい | |
| `character_set_server` | はい | |
| `collation_connection` | はい | |
| `collation_server` | はい | |
| `completion_type` | はい | |
| `default_storage_engine` | いいえ | Aurora MySQL クラスターは、すべてのデータに対して InnoDB ストレージエンジンを使用します。 |
| `enforce_gtid_consistency` | ときどき | Aurora MySQL バージョン 2 以降で変更可能です。 |
| `event_scheduler` | あり | イベントスケジューラのステータスを示します。 Aurora MySQL バージョン 3 では、クラスターレベルでのみ変更できます。 |
| `gtid-mode` | ときどき | Aurora MySQL バージョン 2 以降で変更可能です。 |
| `information_schema_stats_expiry` | あり | MySQL データベースサーバーがストレージエンジンからデータを取得し、キャッシュ内のデータを置き換えるまでの秒数。指定できる値は `0`～`31536000` です。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `init_connect` | あり | 接続するクライアントごとにサーバーによって実行されるコマンド。設定では、接続障害を回避するため、二重引用符 ("") を使用します。次に例を示します。 SET optimizer_switch="hash_join=off"
Aurora MySQL バージョン 3 では、`CONNECTION_ADMIN` 権限を持つユーザーにこのパラメータは適用されません。これには Aurora マスターユーザーが含まれます。詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。 |
| `innodb_adaptive_hash_index` | あり | このパラメータは、Aurora MySQL バージョン 2 および Aurora MySQL バージョン 3 の DB クラスターレベルで修正できます。 Adaptive Hash インデックスは Reader DB インスタンスではサポートされていません。 |
| `innodb_aurora_instant_alter_column_allowed` | あり | `INSTANT` アルゴリズムをグローバルレベルでの `ALTER COLUMN` オペレーションに使用できるかどうかを制御します。許容値は以下のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) 詳細については、MySQL ドキュメントの「[列オペレーション](https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html#online-ddl-column-operations)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3.05 以降に適用されます。 |
| `innodb_autoinc_lock_mode` | あり | |
| `innodb_checksums` | なし | Aurora MySQL バージョン 3 から削除されました。 |
| `innodb_cmp_per_index_enabled` | はい | |
| `innodb_commit_concurrency` | はい | |
| `innodb_data_home_dir` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `innodb_deadlock_detect` | あり | このオプションは、Aurora MySQL バージョン 2.11 以降とバージョン 3 でデッドロック検出を無効化するために使用されます。 高並行性システムでは、多数のスレッドが同じロックを待機すると、デッドロック検出によって速度が低下する可能性があります。MySQL パラメータの詳細については、MySQL のドキュメントを参照してください。 |
| `innodb_default_row_format` | あり | このパラメータは、InnoDB テーブル (ユーザー作成 InnoDB 一時テーブルを含む) のデフォルトの行形式を定義します。Aurora MySQL バージョン 2 と 3 に適用されます。 値は `DYNAMIC`、`COMPACT`、または `REDUNDANT.` になります。 |
| `innodb_file_per_table` | あり | このパラメータは、テーブルストレージの編成方法に影響します。詳細については、「[ストレージのスケーリング](Aurora.Managing.Performance.md#Aurora.Managing.Performance.StorageScaling)」を参照してください。 |
| `innodb_flush_log_at_trx_commit` | あり | デフォルト値の `1` を使用することを強くお勧めします。 Aurora MySQL バージョン 3 では、このパラメータを `1` 以外の値に設定する前に、`innodb_trx_commit_allow_data_loss` の値を `1` に設定する必要があります。 詳細については、「[ログバッファをフラッシュする頻度の設定](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)」を参照してください。 |
| `innodb_ft_max_token_size` | はい | |
| `innodb_ft_min_token_size` | はい | |
| `innodb_ft_num_word_optimize` | はい | |
| `innodb_ft_sort_pll_degree` | はい | |
| `innodb_online_alter_log_max_size` | はい | |
| `innodb_optimize_fulltext_only` | はい | |
| `innodb_page_size` | いいえ | |
| `innodb_print_all_deadlocks` | あり | 有効にすると、すべての InnoDB のデッドロックに関する情報が Aurora MySQL エラーログに記録されます。詳細については、「[Aurora MySQL デッドロックの最小化とトラブルシューティング](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks)」を参照してください。 |
| `innodb_purge_batch_size` | はい | |
| `innodb_purge_threads` | はい | |
| `innodb_rollback_on_timeout` | はい | |
| `innodb_rollback_segments` | はい | |
| `innodb_spin_wait_delay` | はい | |
| `innodb_strict_mode` | はい | |
| `innodb_support_xa` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `innodb_sync_array_size` | はい | |
| `innodb_sync_spin_loops` | はい | |
| `innodb_stats_include_delete_marked` | あり | このパラメータが有効なとき、InnoDB はパーシステントオプティマイザ統計の計算時に削除マーク付きのレコードを含めます。 このパラメータは、Aurora MySQL バージョン 2.12 とバージョン 3 に適用されます。 |
| `innodb_table_locks` | はい | |
| `innodb_trx_commit_allow_data_loss` | あり | Aurora MySQL バージョン 3 では、`innodb_flush_log_at_trx_commit` の値を変更できるように、このパラメータの値を `1` に設定します。 `innodb_trx_commit_allow_data_loss` の初期値は `0` です。 詳細については、「[ログバッファをフラッシュする頻度の設定](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)」を参照してください。 |
| `innodb_undo_directory` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `internal_tmp_disk_storage_engine` | あり | どのインメモリストレージエンジンを内部一時テーブルに使用するかを制御します。指定できる値は `INNODB` と `MYISAM` です。 このパラメータは、Aurora MySQL バージョン 2 に適用されます。 |
| `internal_tmp_mem_storage_engine` | あり | どのインメモリストレージエンジンを内部一時テーブルに使用するかを制御します。指定できる値は `MEMORY` と `TempTable` です。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `key_buffer_size` | あり | MyISAM テーブルのキーキャッシュ。詳しい情報については、「[keycache->cache\$1lock ミューテックス](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)」を参照してください。 |
| `lc_time_names` | はい | |
| `log_error_suppression_list` | あり | MySQL エラーログに記録されていないエラーコードのリストを指定します。これにより、重大でない特定のエラー条件を無視することで、エラーログをクリーンな状態に保つことができます。詳細については、MySQL ドキュメントの「[log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3.03 以降に適用されます。 |
| `low_priority_updates` | あり | `INSERT`、`UPDATE`、`DELETE`、`LOCK TABLE WRITE` オペレーションは、保留中の `SELECT` オペレーションがなくなるまで待機します。このパラメータは、テーブルレベルのロック (MyISAM、MEMORY、MERGE) のみを使用するストレージエンジンにのみ影響します。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `lower_case_table_names` | はい (Aurora MySQL バージョン 2) クラスター作成時のみ (Aurora MySQL バージョン 3) | Aurora MySQL バージョン 2.10 以降では、この設定を変更し、ライターインスタンスを再起動した後、すべてのリーダーインスタンスを再起動してください。詳細については、「[読み取り可用性機能のある Aurora クラスターの再起動](aurora-mysql-survivable-replicas.md)」を参照してください。 Aurora MySQL バージョン 3 では、 このパラメータ値はクラスターの作成時に永続的に設定されます。このオプションにデフォルト以外の値を使用する場合は、アップグレードする前に Aurora MySQL バージョン 3 カスタムパラメータグループを設定し、バージョン 3 クラスターを作成するスナップショットの復元操作中にパラメータグループを指定します。 Aurora MySQL に基づく Aurora グローバルデータベースでは、`lower_case_table_names` パラメータがオンの場合、Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行できません。使用できる方法の詳細については、「[メジャーバージョンのアップグレード](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)」を参照してください。 |
| `master-info-repository` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `master_verify_checksum` | あり | Aurora MySQL バージョン 2。`source_verify_checksum` を Aurora MySQL バージョン 3 で使用する。 |
| `max_delayed_threads` | あり | `INSERT DELAYED` ステートメントを処理するスレッドの最大数を設定します。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `max_error_count` | あり | 表示用に保存するエラーメッセージ、警告メッセージ、およびメモメッセージの最大数。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `max_execution_time` | あり | 実行中の `SELECT` ステートメントのタイムアウトをミリ秒単位で表します。値は `0`～`18446744073709551615` の範囲で指定できます。`0` に設定すると、タイムアウトは発生しません。 詳細については、MySQL ドキュメントの「[max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)」を参照してください。 |
| `min_examined_row_limit` | あり | このパラメータを使用すると、指定した行数よりも少ない行数を調べるクエリがログに記録されないようにします。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `partial_revokes` | なし | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `preload_buffer_size` | あり | インデックスをプリロードするときに割り当てられるバッファのサイズ。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `query_cache_type` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `read_only` | あり | このパラメータがオンにされると、サーバーはレプリカスレッドによって実行される更新以外の更新を許可しません。 Aurora MySQL バージョン 2 の有効な値は以下のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Aurora MySQL バージョン 3 の有効な値は以下のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Aurora MySQL バージョン 3 では、`CONNECTION_ADMIN` 権限を持つユーザーにこのパラメータは適用されません。これには Aurora マスターユーザーが含まれます。詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。 |
| `relay-log-space-limit` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replica_parallel_type` | あり | このパラメータを使用すると、整合性を損なうことなく、すでに準備段階にあるコミットされていないすべてのスレッドのレプリカを並行して実行できます。Aurora MySQL バージョン 3 に適用されます。 Aurora MySQL バージョン 3.03.\$1 以前では、デフォルト値は DATABASE です。Aurora MySQL バージョン 3.04 以降では、デフォルト値は LOGICAL\$1CLOCK です。 |
| `replica_preserve_commit_order` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replica_transaction_retries` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replica_type_conversions` | あり | このパラメータは、レプリカで使用されるタイプ変換を決定します。指定できる値は、`ALL_LOSSY`、`ALL_NON_LOSSY`、`ALL_SIGNED`、および `ALL_UNSIGNED`です。詳細については、MySQL ドキュメントの「[ソースとレプリカのテーブル定義が異なるレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-do-db` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-do-table` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-ignore-db` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-ignore-table` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-wild-do-table` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `replicate-wild-ignore-table` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `require_secure_transport` | あり | このパラメータは、Aurora MySQL バージョン 2 および 3 に適用されます。詳細については、「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。 |
| `rpl_read_size` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `server_audit_cw_upload` | なし | Aurora MySQL でこのパラメータは廃止されました。`server_audit_logs_upload` を使用します。 詳細については、「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)」を参照してください。 |
| `server_audit_events` | はい | 詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。 |
| `server_audit_excl_users` | はい | 詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。 |
| `server_audit_incl_users` | はい | 詳細については、「[Amazon Aurora MySQL DB クラスターでのアドバンストな監査の使用](AuroraMySQL.Auditing.md)」を参照してください。 |
| `server_audit_logging` | あり | Amazon CloudWatch Logs へのログのアップロードの手順については、[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md) を参照してください。 |
| `server_audit_logs_upload` | あり | [高度な監査] を有効にし、このパラメータを `1` に設定することで、監査ログを CloudWatch Logs にパブリッシュできます。`server_audit_logs_upload` パラメータのデフォルト値は `0` です。 詳細については、「[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md)」を参照してください。 |
| `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 から削除されました。 |
| `thread_cache_size` | あり | キャッシュされるスレッドの数。このパラメータは、Aurora MySQL バージョン 2 および 3 に適用されます。 |
| `time_zone` | あり | デフォルトでは、Aurora DB クラスターのタイムゾーンは協定世界時 (UTC) です。代わりに、DB クラスターのインスタンスのタイムゾーンをアプリケーションのローカルタイムゾーンに設定できます。詳細については、「[Amazon Aurora DB クラスターのローカルタイムゾーン](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.LocalTimeZone)」を参照してください。 |
| `tls_version` | はい | 詳細については、「[Aurora MySQL の TLS バージョン](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.TLS_Version)」を参照してください。 |
## インスタンスレベルのパラメータ
次の表は、Aurora MySQL DB クラスターの特定の DB インスタンスに適用されるパラメータの一覧です。
| パラメータ名 | 変更可能 | コメント |
| --- | --- | --- |
| `activate_all_roles_on_login` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `allow-suspicious-udfs` | なし | |
| `aurora_disable_hash_join` | あり | Aurora MySQL バージョン 2.09 以降でハッシュ結合最適化を無効にするには、このパラメータを `ON` に設定します。バージョン 3 ではサポートされていません。詳細については、「[Amazon Aurora MySQL の並列クエリ](aurora-mysql-parallel-query.md)」を参照してください。 |
| `aurora_lab_mode` | はい | 詳細については、「[Amazon Aurora MySQL ラボモード](AuroraMySQL.Updates.LabMode.md)」を参照してください。Aurora MySQL バージョン 3 から削除されました。 |
| `aurora_oom_response` | あり | このパラメータは、Aurora MySQL バージョン 2 および 3 でサポートされています。詳細については、「[Aurora MySQL データベースのメモリ不足の問題のトラブルシューティング](AuroraMySQLOOM.md)」を参照してください。 |
| `aurora_parallel_query` | あり | Aurora MySQL バージョン 2.09 以降では、`ON` に設定してパラレルクエリを有効にします。これらのバージョンでは、古い `aurora_pq` パラメータは使用されません。詳細については、「[Amazon Aurora MySQL の並列クエリ](aurora-mysql-parallel-query.md)」を参照してください。 |
| `aurora_pq` | あり | Aurora MySQL バージョン 2.09 より前の特定の DB インスタンスでは、パラレルクエリをオフにするには、`OFF` に設定します。バージョン 2.09 以降では、代わりに `aurora_parallel_query` を使用してパラレルクエリのオンとオフを切り替えます。詳細については、「[Amazon Aurora MySQL の並列クエリ](aurora-mysql-parallel-query.md)」を参照してください。 |
| `aurora_read_replica_read_committed` | あり | Aurora レプリカの `READ COMMITTED` 分離レベルを有効化し、長時間実行クエリ中のパージラグを削減するように分離動作を変更します。動作の変更点および変更によるクエリ結果への影響を理解している場合にのみ、この設定を有効にしてください。たとえば、この設定では MySQL のデフォルトよりも厳密でない分離を使用します。Aurora はクエリ実行中にテーブルを再編成するため、これが有効なとき、長時間実行クエリには同じ行の複数のコピーが表示されることがあります。詳細については、「[Aurora MySQL の分離レベル](AuroraMySQL.Reference.IsolationLevels.md)」を参照してください。 |
| `aurora_tmptable_enable_per_table_limit` | あり | Aurora MySQL バージョン 3.04 以降で、`TempTable` ストレージエンジンによって作成されるメモリ内一時テーブルの最大サイズを `tmp_table_size` パラメータが制御するかどうかを決定します。 詳細については、「[内部メモリ内一時テーブルのサイズを制限する](ams3-temptable-behavior.md#ams3-temptable-behavior-limit)」を参照してください。 |
| `aurora_use_vector_instructions` | あり | このパラメータが有効なとき、Aurora MySQL は最新の CPU が提供する最適化されたベクトル処理命令を使用して、I/O 集約型ワークロードのパフォーマンスを向上させます。 Aurora MySQL version 3.05 以降では、この設定はデフォルトで有効になっています。 |
| `autocommit` | はい | |
| `automatic_sp_privileges` | はい | |
| `back_log` | はい | |
| `basedir` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `binlog_cache_size` | はい | |
| `binlog_max_flush_queue_time` | はい | |
| `binlog_order_commits` | はい | |
| `binlog_stmt_cache_size` | はい | |
| `binlog_transaction_compression` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `binlog_transaction_compression_level_zstd` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `bulk_insert_buffer_size` | はい | |
| `concurrent_insert` | はい | |
| `connect_timeout` | はい | |
| `core-file` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `datadir` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `default_authentication_plugin` | なし | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `default_time_zone` | なし | |
| `default_tmp_storage_engine` | あり | 一時テーブルのデフォルトのストレージエンジン。 |
| `default_week_format` | はい | |
| `delay_key_write` | はい | |
| `delayed_insert_limit` | はい | |
| `delayed_insert_timeout` | はい | |
| `delayed_queue_size` | はい | |
| `div_precision_increment` | はい | |
| `end_markers_in_json` | はい | |
| `eq_range_index_dive_limit` | はい | |
| `event_scheduler` | ときどき | イベントスケジューラのステータスを示します。 Aurora MySQL バージョン 3 では、クラスターレベルでのみ変更できます。 |
| `explicit_defaults_for_timestamp` | あり | |
| `flush` | いいえ | |
| `flush_time` | はい | |
| `ft_boolean_syntax` | いいえ | |
| `ft_max_word_len` | はい | |
| `ft_min_word_len` | はい | |
| `ft_query_expansion_limit` | はい | |
| `ft_stopword_file` | はい | |
| `general_log` | はい | CloudWatch Logs へのログのアップロードの手順については、[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md) を参照してください。 |
| `general_log_file` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `group_concat_max_len` | はい | |
| `host_cache_size` | はい | |
| `init_connect` | あり | 接続するクライアントごとにサーバーによって実行されるコマンド。設定では、接続障害を回避するため、二重引用符 ("") を使用します。次に例を示します。 SET optimizer_switch="hash_join=off"
Aurora MySQL バージョン 3 では、Aurora マスターユーザーなど、`CONNECTION_ADMIN` 権限を持つユーザーには、このパラメータは適用されません。詳細については、「[ロールベースの特権モデル](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)」を参照してください。 |
| `innodb_adaptive_hash_index` | あり | このパラメータは、Aurora MySQL バージョン 2 の DB インスタンスレベルに適用されます。Aurora MySQL バージョン 3 では、DB クラスターレベルでのみ変更できます。 Adaptive Hash インデックスは Reader DB インスタンスではサポートされていません。 |
| `innodb_adaptive_max_sleep_delay` | あり | Aurora では、`innodb_thread_concurrency` は常に 0 であるため、このパラメータを変更しても影響はありません。 |
| `innodb_aurora_max_partitions_for_range` | あり | 永続的な統計情報が得られない場合は、このパラメータを使用してパーティション分割テーブルの行数計算のパフォーマンスを向上させることができます。 この値は 0 ～ 8192 に設定できます。この値によって、行数の計算時にチェックするパーティションの数が決まります。デフォルト値は 0 で、MySQL のデフォルト動作と同じく、すべてのパーティションを使用していると推定されます。 このパラメータは、Aurora MySQL バージョン 3.03.1 以降で使用できます。 |
| `innodb_autoextend_increment` | あり | |
| `innodb_buffer_pool_dump_at_shutdown` | いいえ | |
| `innodb_buffer_pool_dump_now` | いいえ | |
| `innodb_buffer_pool_filename` | いいえ | |
| `innodb_buffer_pool_load_abort` | いいえ | |
| `innodb_buffer_pool_load_at_startup` | いいえ | |
| `innodb_buffer_pool_load_now` | いいえ | |
| `innodb_buffer_pool_size` | あり | デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「[DB パラメータ式の変数](USER_ParamValuesRef.md#USER_FormulaVariables)」を参照してください。 |
| `innodb_change_buffer_max_size` | なし | Aurora MySQL は、は InnoDB 変更バッファをまったく使用しません。 |
| `innodb_compression_failure_threshold_pct` | はい | |
| `innodb_compression_level` | はい | |
| `innodb_compression_pad_pct_max` | はい | |
| `innodb_concurrency_tickets` | はい | Aurora では `innodb_thread_concurrency` が常に 0 であるため、このパラメータを変更しても影響はありません。 |
| `innodb_deadlock_detect` | あり | このオプションは、Aurora MySQL バージョン 2.11 以降とバージョン 3 でデッドロック検出を無効化するために使用されます。 高並行性システムでは、多数のスレッドが同じロックを待機すると、デッドロック検出によって速度が低下する可能性があります。MySQL パラメータの詳細については、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 のデッドロックに関する情報が Aurora MySQL エラーログに記録されます。詳細については、「[Aurora MySQL デッドロックの最小化とトラブルシューティング](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.deadlocks)」を参照してください。 |
| `innodb_random_read_ahead` | はい | |
| `innodb_read_ahead_threshold` | はい | |
| `innodb_read_io_threads` | いいえ | |
| `innodb_read_only` | いいえ | Aurora MySQL は、クラスターの種類に基づき、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_disk_storage_engine` | あり | どのインメモリストレージエンジンを内部一時テーブルに使用するかを制御します。指定できる値は `INNODB` と `MYISAM` です。 このパラメータは、Aurora MySQL バージョン 2 に適用されます。 |
| `internal_tmp_mem_storage_engine` | あり | どのインメモリストレージエンジンを内部一時テーブルに使用するかを制御します。指定できる値は `MEMORY` と `TempTable` です。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `join_buffer_size` | はい | |
| `keep_files_on_create` | はい | |
| `key_buffer_size` | あり | MyISAM テーブルのキーキャッシュ。詳しい情報については、「[keycache->cache\$1lock ミューテックス](AuroraMySQL.Reference.Waitevents.md#key-cache.cache-lock)」を参照してください。 |
| `key_cache_age_threshold` | はい | |
| `key_cache_block_size` | はい | |
| `key_cache_division_limit` | はい | |
| `local_infile` | はい | |
| `lock_wait_timeout` | はい | |
| `log-bin` | いいえ | `binlog_format` を `STATEMENT`、`MIXED`、または `ROW` に設定すると、`log-bin` は自動的に `ON` に設定されます。`binlog_format` を `OFF` に設定すると、`log-bin` は自動的に `OFF` に設定されます。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。 |
| `log_bin_trust_function_creators` | はい | |
| `log_bin_use_v1_row_events` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `log_error` | なし | |
| `log_error_suppression_list` | あり | MySQL エラーログに記録されていないエラーコードのリストを指定します。これにより、重大でない特定のエラー条件を無視することで、エラーログをクリーンな状態に保つことができます。詳細については、MySQL ドキュメントの「[log\$1error\$1suppression\$1list](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_log_error_suppression_list)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3.03 以降に適用されます。 |
| `log_output` | はい | |
| `log_queries_not_using_indexes` | はい | |
| `log_slave_updates` | なし | Aurora MySQL バージョン 2。`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` | あり | `INSERT`、`UPDATE`、`DELETE`、`LOCK TABLE WRITE` オペレーションは、保留中の `SELECT` オペレーションがなくなるまで待機します。このパラメータは、テーブルレベルのロック (MyISAM、MEMORY、MERGE) のみを使用するストレージエンジンにのみ影響します。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `max_allowed_packet` | はい | |
| `max_binlog_cache_size` | はい | |
| `max_binlog_size` | いいえ | |
| `max_binlog_stmt_cache_size` | はい | |
| `max_connect_errors` | はい | |
| `max_connections` | あり | デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「[DB パラメータ式の変数](USER_ParamValuesRef.md#USER_FormulaVariables)」を参照してください。インスタンスクラスに応じたデフォルト値については、「[Aurora MySQL DB インスタンスへの最大接続数](AuroraMySQL.Managing.Performance.md#AuroraMySQL.Managing.MaxConnections)」を参照してください。 |
| `max_delayed_threads` | あり | `INSERT DELAYED` ステートメントを処理するスレッドの最大数を設定します。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `max_error_count` | あり | 表示用に保存するエラーメッセージ、警告メッセージ、およびメモメッセージの最大数。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `max_execution_time` | あり | 実行中の `SELECT` ステートメントのタイムアウトをミリ秒単位で表します。値は `0`～`18446744073709551615` の範囲で指定できます。`0` に設定すると、タイムアウトは発生しません。 詳細については、MySQL ドキュメントの「[max\$1execution\$1time](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_execution_time)」を参照してください。 |
| `max_heap_table_size` | はい | |
| `max_insert_delayed_threads` | はい | |
| `max_join_size` | はい | |
| `max_length_for_sort_data` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `max_prepared_stmt_count` | はい | |
| `max_seeks_for_key` | はい | |
| `max_sort_length` | はい | |
| `max_sp_recursion_depth` | はい | |
| `max_tmp_tables` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `max_user_connections` | はい | |
| `max_write_lock_count` | はい | |
| `metadata_locks_cache_size` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `min_examined_row_limit` | あり | このパラメータを使用すると、指定した行数よりも少ない行数を調べるクエリがログに記録されないようにします。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `myisam_data_pointer_size` | はい | |
| `myisam_max_sort_file_size` | はい | |
| `myisam_mmap_size` | はい | |
| `myisam_sort_buffer_size` | はい | |
| `myisam_stats_method` | はい | |
| `myisam_use_mmap` | はい | |
| `net_buffer_length` | はい | |
| `net_read_timeout` | はい | |
| `net_retry_count` | はい | |
| `net_write_timeout` | はい | |
| `old-style-user-limits` | はい | |
| `old_passwords` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `optimizer_prune_level` | はい | |
| `optimizer_search_depth` | はい | |
| `optimizer_switch` | はい | このスイッチを使用する Aurora MySQL 機能の詳細については、「[Amazon Aurora MySQL を使用する際のベストプラクティス](AuroraMySQL.BestPractices.md)」を参照してください。 |
| `optimizer_trace` | はい | |
| `optimizer_trace_features` | はい | |
| `optimizer_trace_limit` | はい | |
| `optimizer_trace_max_mem_size` | はい | |
| `optimizer_trace_offset` | はい | |
| `performance-schema-consumer-events-waits-current` | はい | |
| `performance-schema-instrument` | はい | |
| `performance_schema` | はい | |
| `performance_schema_accounts_size` | はい | |
| `performance_schema_consumer_global_instrumentation` | はい | |
| `performance_schema_consumer_thread_instrumentation` | はい | |
| `performance_schema_consumer_events_stages_current` | はい | |
| `performance_schema_consumer_events_stages_history` | はい | |
| `performance_schema_consumer_events_stages_history_long` | はい | |
| `performance_schema_consumer_events_statements_current` | はい | |
| `performance_schema_consumer_events_statements_history` | はい | |
| `performance_schema_consumer_events_statements_history_long` | はい | |
| `performance_schema_consumer_events_waits_history` | はい | |
| `performance_schema_consumer_events_waits_history_long` | はい | |
| `performance_schema_consumer_statements_digest` | はい | |
| `performance_schema_digests_size` | はい | |
| `performance_schema_events_stages_history_long_size` | はい | |
| `performance_schema_events_stages_history_size` | はい | |
| `performance_schema_events_statements_history_long_size` | はい | |
| `performance_schema_events_statements_history_size` | はい | |
| `performance_schema_events_transactions_history_long_size` | はい | |
| `performance_schema_events_transactions_history_size` | はい | |
| `performance_schema_events_waits_history_long_size` | はい | |
| `performance_schema_events_waits_history_size` | はい | |
| `performance_schema_hosts_size` | はい | |
| `performance_schema_max_cond_classes` | はい | |
| `performance_schema_max_cond_instances` | はい | |
| `performance_schema_max_digest_length` | はい | |
| `performance_schema_max_file_classes` | はい | |
| `performance_schema_max_file_handles` | はい | |
| `performance_schema_max_file_instances` | はい | |
| `performance_schema_max_index_stat` | はい | |
| `performance_schema_max_memory_classes` | はい | |
| `performance_schema_max_metadata_locks` | はい | |
| `performance_schema_max_mutex_classes` | はい | |
| `performance_schema_max_mutex_instances` | はい | |
| `performance_schema_max_prepared_statements_instances` | はい | |
| `performance_schema_max_program_instances` | はい | |
| `performance_schema_max_rwlock_classes` | はい | |
| `performance_schema_max_rwlock_instances` | はい | |
| `performance_schema_max_socket_classes` | はい | |
| `performance_schema_max_socket_instances` | はい | |
| `performance_schema_max_sql_text_length` | はい | |
| `performance_schema_max_stage_classes` | はい | |
| `performance_schema_max_statement_classes` | はい | |
| `performance_schema_max_statement_stack` | はい | |
| `performance_schema_max_table_handles` | はい | |
| `performance_schema_max_table_instances` | はい | |
| `performance_schema_max_table_lock_stat` | はい | |
| `performance_schema_max_thread_classes` | はい | |
| `performance_schema_max_thread_instances` | はい | |
| `performance_schema_session_connect_attrs_size` | はい | |
| `performance_schema_setup_actors_size` | はい | |
| `performance_schema_setup_objects_size` | はい | |
| `performance_schema_show_processlist` | あり | このパラメータは、使用する SHOW PROCESSLIST 実装を決定します。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html)このパラメータは、Aurora MySQL バージョン 2.12 とバージョン 3 に適用されます。 |
| `performance_schema_users_size` | あり | |
| `pid_file` | いいえ | |
| `plugin_dir` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `port` | なし | Aurora MySQL は接続プロパティを管理し、クラスター内のすべての DB インスタンスに対して一貫した設定を適用します。 |
| `preload_buffer_size` | あり | インデックスをプリロードするときに割り当てられるバッファのサイズ。 このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `profiling_history_size` | はい | |
| `query_alloc_block_size` | はい | |
| `query_cache_limit` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `query_cache_min_res_unit` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `query_cache_size` | あり | デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「[DB パラメータ式の変数](USER_ParamValuesRef.md#USER_FormulaVariables)」を参照してください。 Aurora MySQL バージョン 3 から削除されました。 |
| `query_cache_type` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `query_cache_wlock_invalidate` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `query_prealloc_size` | はい | |
| `range_alloc_block_size` | はい | |
| `read_buffer_size` | はい | |
| `read_only` | あり | このパラメータがオンにされると、サーバーはレプリカスレッドによって実行される更新以外の更新を許可しません。 Aurora MySQL バージョン 2 の有効な値は以下のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.ParameterGroups.html) Aurora MySQL バージョン 2 の DB クラスターパラメータグループを使用して、フェイルオーバー時に `read_only` パラメータが新しいライターインスタンスに適用されていることを確認することをお勧めします。 Aurora MySQL はすべてのリーダーで `innodb_read_only` を `1` に設定しているため、リーダーインスタンスは常に読み取り専用です。したがって、`read_only` はリーダーインスタンスでは冗長になります。 Aurora MySQL バージョン 3 からインスタンスレベルで削除されました。 |
| `read_rnd_buffer_size` | あり | |
| `relay-log` | いいえ | |
| `relay_log_info_repository` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `relay_log_recovery` | なし | |
| `replica_checkpoint_group` | あり | Aurora MySQL バージョン 3 |
| `replica_checkpoint_period` | あり | Aurora MySQL バージョン 3 |
| `replica_parallel_workers` | あり | Aurora MySQL バージョン 3 |
| `replica_pending_jobs_size_max` | あり | Aurora MySQL バージョン 3 |
| `replica_skip_errors` | あり | Aurora MySQL バージョン 3 |
| `replica_sql_verify_checksum` | あり | Aurora MySQL バージョン 3 |
| `safe-user-create` | はい | |
| `secure_auth` | あり | Aurora MySQL バージョン 2 では、このパラメータは常にオンになっています。オフにしようとするとエラーが発生します。 Aurora MySQL バージョン 3 から削除されました。 |
| `secure_file_priv` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `show_create_table_verbosity` | あり | この変数を有効にすると、[SHOW\$1CREATE\$1TABLE](https://dev.mysql.com/doc/refman/5.7/en/show-create-table.html) は、デフォルトの形式であるかどうかに関係なく、`ROW_FORMAT` を表示します。 このパラメータは、Aurora MySQL バージョン 2.12 とバージョン 3 に適用されます。 |
| `skip-slave-start` | なし | |
| `skip_external_locking` | いいえ | |
| `skip_show_database` | はい | |
| `slave_checkpoint_group` | あり | Aurora MySQL バージョン 2。`replica_checkpoint_group` を Aurora MySQL バージョン 3 で使用する。 |
| `slave_checkpoint_period` | あり | Aurora MySQL バージョン 2。`replica_checkpoint_period` を Aurora MySQL バージョン 3 で使用する。 |
| `slave_parallel_workers` | あり | Aurora MySQL バージョン 2。`replica_parallel_workers` を Aurora MySQL バージョン 3 で使用する。 |
| `slave_pending_jobs_size_max` | あり | Aurora MySQL バージョン 2。`replica_pending_jobs_size_max` を Aurora MySQL バージョン 3 で使用する。 |
| `slave_sql_verify_checksum` | あり | Aurora MySQL バージョン 2。`replica_sql_verify_checksum` を Aurora MySQL バージョン 3 で使用する。 |
| `slow_launch_time` | はい | |
| `slow_query_log` | はい | CloudWatch Logs へのログのアップロードの手順については、[Amazon CloudWatch Logs への Amazon Aurora MySQL ログの発行](AuroraMySQL.Integrating.CloudWatch.md) を参照してください。 |
| `slow_query_log_file` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `socket` | なし | |
| `sort_buffer_size` | はい | |
| `sql_mode` | はい | |
| `sql_select_limit` | はい | |
| `stored_program_cache` | はい | |
| `sync_binlog` | いいえ | |
| `sync_master_info` | はい | |
| `sync_source_info` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。 |
| `sync_relay_log` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `sync_relay_log_info` | はい | |
| `sysdate-is-now` | はい | |
| `table_cache_element_entry_ttl` | いいえ | |
| `table_definition_cache` | あり | デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「[DB パラメータ式の変数](USER_ParamValuesRef.md#USER_FormulaVariables)」を参照してください。 |
| `table_open_cache` | あり | デフォルト値は式により表されます。式内で `DBInstanceClassMemory` 値がどのように計算されるかにいては、「[DB パラメータ式の変数](USER_ParamValuesRef.md#USER_FormulaVariables)」を参照してください。 |
| `table_open_cache_instances` | はい | |
| `temp-pool` | あり | Aurora MySQL バージョン 3 から削除されました。 |
| `temptable_max_mmap` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。 |
| `temptable_max_ram` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。 |
| `temptable_use_mmap` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。詳細については、「[Aurora MySQL バージョン 3 での新しい一時テーブルの動作](ams3-temptable-behavior.md)」を参照してください。 |
| `thread_cache_size` | あり | キャッシュされるスレッドの数。このパラメータは、Aurora MySQL バージョン 2 および 3 に適用されます。 |
| `thread_handling` | なし | |
| `thread_stack` | はい | |
| `timed_mutexes` | はい | |
| `tmp_table_size` | あり | Aurora MySQL バージョン 3 の `MEMORY` ストレージエンジンによって作成される内部メモリ内一時テーブルの最大サイズを定義します。 Aurora MySQL バージョン 3.04 以降で、`aurora_tmptable_enable_per_table_limit` が `ON` のときに `TempTable` ストレージエンジンによって作成される内部メモリ内一時テーブルの最大サイズを定義します。 詳細については、「[内部メモリ内一時テーブルのサイズを制限する](ams3-temptable-behavior.md#ams3-temptable-behavior-limit)」を参照してください。 |
| `tmpdir` | なし | Aurora MySQL は、直接ファイルシステムにアクセスしないマネージドインスタンスを使用します。 |
| `transaction_alloc_block_size` | はい | |
| `transaction_isolation` | あり | このパラメータは、Aurora MySQL バージョン 3 に適用されます。`tx_isolation` はこれに置き換えられます。 |
| `transaction_prealloc_size` | はい | |
| `tx_isolation` | あり | Aurora MySQL バージョン 3 から削除されました。これは `transaction_isolation` に置き換えられます。 |
| `updatable_views_with_limit` | あり | |
| `validate-password` | いいえ | |
| `validate_password_dictionary_file` | いいえ | |
| `validate_password_length` | いいえ | |
| `validate_password_mixed_case_count` | いいえ | |
| `validate_password_number_count` | いいえ | |
| `validate_password_policy` | いいえ | |
| `validate_password_special_char_count` | いいえ | |
| `wait_timeout` | あり | Aurora は `interactive_timeout` と `wait_timeout` の最小値を評価します。次に、その最小値をタイムアウトとして使い、対話型と非対話型の両方のアイドル状態のセッションをすべて終了します。 |
## Aurora MySQL に適用されない MySQL パラメータ
Aurora MySQL と MySQL ではアーキテクチャに違いがあるため、一部の MySQL パラメータは Aurora MySQL に適用されません。
次の MySQL パラメータは Aurora MySQL には適用されません。これはすべてを網羅したリストではありません。
+ `activate_all_roles_on_login` – このパラメータは、Aurora MySQL バージョン 2 には適用されません。Aurora MySQL バージョン 3 で利用可能です。
+ `big_tables`
+ `bind_address`
+ `character_sets_dir`
+ `innodb_adaptive_flushing`
+ `innodb_adaptive_flushing_lwm`
+ `innodb_buffer_pool_chunk_size`
+ `innodb_buffer_pool_instances`
+ `innodb_change_buffering`
+ `innodb_checksum_algorithm`
+ `innodb_data_file_path`
+ `innodb_dedicated_server`
+ `innodb_doublewrite`
+ `innodb_flush_log_at_timeout` – このパラメータは Aurora MySQL には適用されません。詳細については、「[ログバッファをフラッシュする頻度の設定](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush)」を参照してください。
+ `innodb_flush_method`
+ `innodb_flush_neighbors`
+ `innodb_io_capacity`
+ `innodb_io_capacity_max`
+ `innodb_log_buffer_size`
+ `innodb_log_file_size`
+ `innodb_log_files_in_group`
+ `innodb_log_spin_cpu_abs_lwm`
+ `innodb_log_spin_cpu_pct_hwm`
+ `innodb_log_writer_threads`
+ `innodb_max_dirty_pages_pct`
+ `innodb_numa_interleave`
+ `innodb_page_size`
+ `innodb_redo_log_capacity`
+ `innodb_redo_log_encrypt`
+ `innodb_undo_log_encrypt`
+ `innodb_undo_log_truncate`
+ `innodb_undo_logs`
+ `innodb_undo_tablespaces`
+ `innodb_use_native_aio`
+ `innodb_write_io_threads`
# Aurora MySQL グローバルステータス変数
Aurora MySQL には、コミュニティ MySQL のステータス変数と、Aurora に固有の変数が含まれます。これらの変数を調べて、データベースエンジン内で何が起こっているかを知ることができます。コミュニティ MySQL のステータス変数の詳細については、コミュニティ MySQL 8.0 ドキュメントの「[Server Status Variables](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html)」を参照してください。
Aurora MySQL グローバルステータス変数の現在の値は、次のようなステートメントを使用して確認できます。
```
show global status like '%aurora%';
```
**注記**
グローバルステータス変数は、DB エンジンの再起動時にクリアされます。
次の表では、Aurora MySQL が使用するグローバルステータス変数について説明します。
| 名前 | 説明 |
| --- | --- |
| `AuroraDb_commits` | 前回の再起動以降のコミットの総数。 |
| `AuroraDb_commit_latency` | 前回の再起動以降のコミットレイテンシーの合計。 |
| `AuroraDb_ddl_stmt_duration` | 前回の再起動以降の DDL レイテンシーの合計。 |
| `AuroraDb_select_stmt_duration` | 前回の再起動以降の `SELECT` ステートメントレイテンシーの合計。 |
| `AuroraDb_insert_stmt_duration` | 前回の再起動以降の `INSERT` ステートメントレイテンシーの合計。 |
| `AuroraDb_update_stmt_duration` | 前回の再起動以降の `UPDATE` ステートメントレイテンシーの合計。 |
| `AuroraDb_delete_stmt_duration` | 前回の再起動以降の `DELETE` ステートメントレイテンシーの合計。 |
| `Aurora_binlog_io_cache_allocated` | バイナリログ I/O キャッシュに割り当てられたバイト数。 |
| `Aurora_binlog_io_cache_read_requests` | バイナリログ I/O キャッシュに対して行われた読み取りリクエスト数。 |
| `Aurora_binlog_io_cache_reads` | バイナリログ I/O キャッシュから処理された読み込みリクエスト数。 |
| `Aurora_enhanced_binlog` | この DB インスタンスの拡張バイナリログが有効か無効かを示します。詳細については、「[Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)」を参照してください。 |
| `Aurora_external_connection_count` | DB インスタンスへのデータベース接続の数。ただし、データベースヘルスチェックに使用される RDS サービス接続は除きます。 |
| `Aurora_fast_insert_cache_hits` | キャッシュされたカーソルが正常に取得され検証されたときに増加するカウンター。高速挿入キャッシュの詳細については、「[Amazon Aurora MySQL パフォーマンスの拡張](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)」を参照してください。 |
| `Aurora_fast_insert_cache_misses` | キャッシュされたカーソルが有効でなくなり、Aurora が通常のインデックストラバーサルを実行したときに増加するカウンター。高速挿入キャッシュの詳細については、「[Amazon Aurora MySQL パフォーマンスの拡張](Aurora.AuroraMySQL.Overview.md#Aurora.AuroraMySQL.Performance)」を参照してください。 |
| `Aurora_fts_cache_memory_used` | InnoDB 全文検索システムが使用しているメモリの量 (バイト数)。この変数は、Aurora MySQL バージョン 3.07 以上に適用されます。 |
| `Aurora_fwd_master_dml_stmt_count` | このライター DB インスタンスに転送された DML ステートメントの合計数。この変数は、Aurora MySQL バージョン 2 に適用されます。 |
| `Aurora_fwd_master_dml_stmt_duration` | このライター DB インスタンスに転送された DML ステートメントの合計期間。この変数は、Aurora MySQL バージョン 2 に適用されます。 |
| `Aurora_fwd_master_errors_rpc_timeout` | 転送された接続がライター上で確立されなかった回数。 |
| `Aurora_fwd_master_errors_session_limit` | ライターで `session full` の理由で拒否された転送されたクエリの数。 |
| `Aurora_fwd_master_errors_session_timeout` | ライターでのタイムアウトにより転送セッションが終了した回数。 |
| `Aurora_fwd_master_open_sessions` | ライター DB インスタンスで転送されたセッションの数。この変数は、Aurora MySQL バージョン 2 に適用されます。 |
| `Aurora_fwd_master_select_stmt_count` | このライター DB インスタンスに転送された `SELECT` ステートメントの総数。この変数は、Aurora MySQL バージョン 2 に適用されます。 |
| `Aurora_fwd_master_select_stmt_duration` | このライター DB インスタンスに転送された `SELECT` ステートメントの合計期間。この変数は、Aurora MySQL バージョン 2 に適用されます。 |
| `Aurora_fwd_writer_dml_stmt_count` | このライター DB インスタンスに転送された DML ステートメントの合計数。この変数は、Aurora MySQL バージョン 3 に適用されます。 |
| `Aurora_fwd_writer_dml_stmt_duration` | このライター DB インスタンスに転送された DML ステートメントの合計期間。この変数は、Aurora MySQL バージョン 3 に適用されます。 |
| `Aurora_fwd_writer_errors_rpc_timeout` | 転送された接続がライター上で確立されなかった回数。 |
| `Aurora_fwd_writer_errors_session_limit` | ライターで `session full` の理由で拒否された転送されたクエリの数。 |
| `Aurora_fwd_writer_errors_session_timeout` | ライターでのタイムアウトにより転送セッションが終了した回数。 |
| `Aurora_fwd_writer_open_sessions` | ライター DB インスタンスで転送されたセッションの数。この変数は、Aurora MySQL バージョン 3 に適用されます。 |
| `Aurora_fwd_writer_select_stmt_count` | このライター DB インスタンスに転送された `SELECT` ステートメントの総数。この変数は、Aurora MySQL バージョン 3 に適用されます。 |
| `Aurora_fwd_writer_select_stmt_duration` | このライター DB インスタンスに転送された `SELECT` ステートメントの合計期間。この変数は、Aurora MySQL バージョン 3 に適用されます。 |
| `Aurora_lockmgr_buffer_pool_memory_used` | Aurora MySQL ロックマネージャーが使用しているバッファプールメモリの量 (バイト単位)。 |
| `Aurora_lockmgr_memory_used` | Aurora MySQL ロックマネージャーが使用しているメモリの量 (バイト単位)。 |
| `Aurora_ml_actual_request_cnt` | DB インスタンスのユーザーによって実行されたすべてのクエリで、Aurora MySQL が Aurora 機械学習サービスに対して行ったリクエストの集計カウント。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_actual_response_cnt` | DB インスタンスのユーザーが実行するすべてのクエリで、Aurora MySQL が Aurora 機械学習サービスから受け取るレスポンスの集計カウント。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_cache_hit_cnt` | DB インスタンスのユーザーが実行したすべてのクエリで、Aurora MySQL が Aurora 機械学習サービスから受け取る内部キャッシュヒットの集計カウント。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_logical_request_cnt` | 前回のステータスリセット以降、DB インスタンスが Aurora 機械学習サービスに送信されると評価した論理リクエストの数。バッチ処理が使用されているかどうかによっては、この値が `Aurora_ml_actual_request_cnt` より高くなることがあります。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_logical_response_cnt` | DB インスタンスのユーザーが実行するすべてのクエリで、Aurora MySQL が Aurora 機械学習サービスから受け取るレスポンスの集計カウント。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_retry_request_cnt` | 前回のステータスリセット以降、DB インスタンスが Aurora 機械学習サービスに送信されると評価した再試行リクエストの数。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `Aurora_ml_single_request_cnt` | DB インスタンスのユーザーが実行するすべてのクエリで、非バッチモードで評価される Aurora 機械学習の関数の集計カウント。詳細については、「[Aurora MySQL で Amazon Aurora 機械学習を使用する](mysql-ml.md)」を参照してください。 |
| `aurora_oom_avoidance_recovery_state` | Aurora のメモリ不足 (OOM) 回避リカバリが、この DB インスタンスの `ACTIVE` または `INACTIVE` 状態であるかどうかを示します。 この変数は、Aurora MySQL バージョン 3.06.0 以上に適用されます。 |
| `aurora_oom_reserved_mem_enter_kb` | Aurora の OOM 処理メカニズムで `RESERVED` 状態に入るためのしきい値を表します。 サーバーで使用可能なメモリがこのしきい値を下回ると、`aurora_oom_status` は `RESERVED` に変わり、サーバーがクリティカルレベルのメモリ使用量に近づいていることを示します。 この変数は、Aurora MySQL バージョン 3.06.0 以上に適用されます。 |
| `aurora_oom_reserved_mem_exit_kb` | Aurora の OOM 処理メカニズムで `RESERVED` 状態を出るためのしきい値を表します。 サーバーで使用可能なメモリがこのしきい値を超えて増加すると、`aurora_oom_status` は `NORMAL` に戻り、サーバーが十分なメモリリソースを持つ、より安定した状態に戻ったことを示します。 この変数は、Aurora MySQL バージョン 3.06.0 以上に適用されます。 |
| `aurora_oom_status` | この DB インスタンスの現在の OOM ステータスを表します。値が `NORMAL` のときには、十分なメモリリソースがあることを示します。 値が `RESERVED` に変わった場合は、サーバーで使用可能なメモリが少ないことを示します。アクションは `aurora_oom_response` パラメータ設定に基づいて実行されます。 詳細については、「[Aurora MySQL データベースのメモリ不足の問題のトラブルシューティング](AuroraMySQLOOM.md)」を参照してください。 この変数は、Aurora MySQL バージョン 3.06.0 以上に適用されます。 |
| `Aurora_pq_bytes_returned` | パラレルクエリ中にヘッドノードに送信されたタプルデータ構造のバイト数。`Aurora_pq_pages_pushed_down` と比較するために 16,384 で割ります。 |
| `Aurora_pq_max_concurrent_requests` | この Aurora DB インスタンスで同時に実行できるパラレルクエリセッションの最大数。これは、AWS の DB インスタンスクラスによって異なる固定の数です。 |
| `Aurora_pq_pages_pushed_down` | パラレルクエリがヘッドノードへのネットワーク送信を回避したデータページ数 (それぞれ 16 KiB の固定サイズ)。 |
| `Aurora_pq_request_attempted` | リクエストされたパラレルクエリセッションの数。この値は、サブクエリや結合などの SQL 構成に応じて、クエリごとに複数のセッションを表す場合があります。 |
| `Aurora_pq_request_executed` | パラレルクエリセッションの数は正常に実行されます。 |
| `Aurora_pq_request_failed` | クライアントにエラーを戻したパラレルクエリセッションの数。場合によっては、例えば、ストレージレイヤーの問題のために、パラレルクエリのリクエストが失敗することがあります。このような場合、失敗したクエリ部分は、非パラレルクエリメカニズムを使用して再試行されます。再試行されたクエリも失敗すると、エラーがクライアントに返され、このカウンターが増分されます。 |
| `Aurora_pq_request_in_progress` | 現在進行中のパラレルクエリセッションの数。この数は、Aurora DB クラスター全体ではなく、接続している特定の Aurora DB インスタンスのものが適用されます。DB インスタンスが同時実行の制限に近いかどうかを調べるには、この値を `Aurora_pq_max_concurrent_requests` と比較します。 |
| `Aurora_pq_request_not_chosen` | クエリを満たすためにパラレルクエリが選択されなかった回数。この値は、他のいくつかのより細かいカウンターの合計です。`EXPLAIN` ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。 |
| `Aurora_pq_request_not_chosen_below_min_rows` | テーブル内の行数のためにパラレルクエリが選択されなかった回数。`EXPLAIN` ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。 |
| `Aurora_pq_request_not_chosen_column_bit` | 射影された列の中にサポートされていないデータ型があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_column_geometry` | テーブルに `GEOMETRY` データ型の列があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。この制限を解除する Aurora MySQL のバージョンについては、[Aurora MySQL バージョン 3 への パラレルクエリクラスターのアップグレード](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) を参照してください。 |
| `Aurora_pq_request_not_chosen_column_lob` | `LOB` データタイプ、または宣言された長さのため外部に保存された `VARCHAR` カラムをテーブルが持っていることが原因で、非パラレルクエリの処理パスを使用したパラレルクエリのリクエスト数。この制限を解除する Aurora MySQL のバージョンについては、[Aurora MySQL バージョン 3 への パラレルクエリクラスターのアップグレード](aurora-mysql-parallel-query-optimizing.md#aurora-mysql-parallel-query-upgrade-pqv2) を参照してください。 |
| `Aurora_pq_request_not_chosen_column_virtual` | テーブルに仮想列があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_custom_charset` | テーブルにカスタム文字セットの列があるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_fast_ddl` | テーブルが高速 DDL の `ALTER` ステートメントによって変更中であるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_few_pages_outside_buffer_pool` | パラレルクエリを価値のあるものにするためのバッファされていないテーブルデータが十分ないため、テーブルデータの 95 パーセント未満がバッファプールにあったにもかかわらず、パラレルクエリの回数は選択されませんでした。 |
| `Aurora_pq_request_not_chosen_full_text_index` | テーブルに全文インデックスがあるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_high_buffer_pool_pct` | テーブルデータの高パーセンテージ (現在は 95 パーセント以上) が既にバッファプールに入っていたため、パラレルクエリが選択されなかった回数。このような場合、オプティマイザは、バッファプールからのデータの読取りがより効率的であると判断します。`EXPLAIN` ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。 |
| `Aurora_pq_request_not_chosen_index_hint` | クエリにインデックスヒントが含まれているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_innodb_table_format` | テーブルが、サポートされていない InnoDB の行形式を使用しているために、パラレルクエリ以外の処理方法が適用されるパラレルクエリのリクエスト数。Aurora のパラレルクエリは、`COMPACT`、`REDUNDANT`,および `DYNAMIC` の行形式にのみ適用されます。 |
| `Aurora_pq_request_not_chosen_long_trx` | 長時間実行トランザクション内でクエリがスタートされているために、非パラレルクエリ処理パスを使用したパラレルクエリリクエストの数。`EXPLAIN` ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。 |
| `Aurora_pq_request_not_chosen_no_where_clause` | クエリに `WHERE` 句がないために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_range_scan` | インデックスの範囲スキャンを使用しているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_row_length_too_long` | すべての列の合計長が長すぎるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_small_table` | 行数および平均行長によって決定される、テーブルの全体的なサイズのためにパラレルクエリが選択されなかった回数。`EXPLAIN` ステートメントでは、クエリが実際に実行されていない場合でもこのカウンターは増加します。 |
| `Aurora_pq_request_not_chosen_temporary_table` | クエリでサポートされていない `MyISAM` また `memory` テーブルタイプを使用しているテンポラリテーブルを参照しているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_tx_isolation` | クエリでサポートされていないトランザクション分離レベルを使用しているために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。リーダー DB インスタンスでは、パラレルクエリは `REPEATABLE READ` および `READ COMMITTED` 分離レベルにのみ適用されます。 |
| `Aurora_pq_request_not_chosen_update_delete_stmts` | クエリが `UPDATE` または `DELETE` ステートメントの一部であるために、パラレルクエリ以外の処理方法が使用されるパラレルクエリのリクエスト数。 |
| `Aurora_pq_request_not_chosen_unsupported_access` | `WHERE` 句がパラレルクエリの基準を満たしていないために、非パラレルクエリ処理パスを使用するパラレルクエリリクエストの数。この結果は、クエリがデータ集約型スキャンを必要としない場合、またはクエリが `DELETE` または `UPDATE` ステートメントである場合に発生します。 |
| `Aurora_pq_request_not_chosen_unsupported_storage_type` | Aurora MySQL DB クラスターがサポートされている Aurora クラスターストレージ設定を使用していないために非並列クエリ処理パスを使用する並列クエリリクエストの数。詳細については、「[制限](aurora-mysql-parallel-query.md#aurora-mysql-parallel-query-limitations)」を参照してください。 このパラメータは、Aurora MySQL バージョン 3.04 以降に適用されます。 |
| `Aurora_pq_request_throttled` | 特定の Aurora DB インスタンスで既に実行されている同時パラレルクエリの最大数のために、パラレルクエリが選択されなかった回数。 |
| `Aurora_repl_bytes_received` | 前回再起動してから Aurora MySQL リーダーデータベースインスタンスに複製されたバイト数。詳細については、「[Amazon Aurora MySQL でのレプリケーション](AuroraMySQL.Replication.md)」を参照してください。 |
| `Aurora_reserved_mem_exceeded_incidents` | 前回の再起動以降、エンジンが予約メモリの制限を超えた回数。`aurora_oom_response` が設定されている場合、このしきい値は、メモリ不足 (OOM) 回避アクティビティがトリガーされるタイミングを定義します。Aurora MySQL OOM レスポンスの詳細については、「[Aurora MySQL データベースのメモリ不足の問題のトラブルシューティング](AuroraMySQLOOM.md)」を参照してください。 |
| `aurora_temptable_max_ram_allocation` | 前回の再起動以降に、内部一時テーブルが任意の時点で使用した最大メモリ容量をバイト単位で表します。 |
| `aurora_temptable_ram_allocation` | 内部一時テーブルが使用している現在のメモリ容量をバイト単位で表します。 |
| `Aurora_in_memory_relaylog_status` | インメモリリレーログ機能の現在のステータス。値は ENABLED または DISABLED となります。 |
| `Aurora_in_memory_relaylog_disabled_reason` | インメモリリレーログ機能が現在のステータスである理由を表示します。この機能が無効になっている場合は、機能が無効になっている理由を説明するメッセージを表示します。 |
| `Aurora_in_memory_relaylog_fallback_count` | インメモリリレーログ機能から永続リレーログモード (レガシー) へのフォールバックの合計数を表示します。フォールバックは、単一のイベントがキャッシュサイズ (現在は 128 MB) を超えるか、トランザクションの再試行数がレプリカトランザクションの再試行数の上限 (replica\$1transaction\$1retries) を超えた場合に発生する可能性があります。 |
| `Aurora_in_memory_relaylog_recovery_count` | インメモリリレーログの復旧が自動的に実行された合計数を表示します。この数には、フォールバックの合計数と、一時的なフォールバック後にインメモリリレーログモードに自動的に切り替えられた回数が含まれます。 |
| `Aurora_thread_pool_thread_count` | Aurora スレッドプール内の現在のスレッド数。Aurora MySQL OOM レスポンスの詳細については、「[スレッドプール](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.pool)」を参照してください。 |
| `Aurora_tmz_version` | DB クラスターで使用されているタイムゾーン情報の現在のバージョンを示します。値は IANA (Internet Assigned Numbers Authority) 形式 `YYYYsuffix` に従います。例えば、`2022a` および `2023c` です。 このパラメータは、Aurora MySQL バージョン 2.12 以降とバージョン 3.04 以降に適用されます。 |
| `Aurora_zdr_oom_threshold` | Aurora DB インスタンスがゼロダウンタイム再起動 (ZDR) を開始して、潜在的なメモリ関連の問題から回復するためのメモリしきい値をキロバイト (KB) 単位で表します。 |
| `server_aurora_das_running` | この DB インスタンスでデータベースアクティビティストリーム (DAS) が有効か無効かを示します。詳細については、「[データベースアクティビティストリームを使用した Amazon Aurora のモニタリング](DBActivityStreams.md)」を参照してください。 |
## Aurora MySQL に適応されない MySQL ステータス可変
Aurora MySQL と MySQL ではアーキテクチャに違いがあるため、一部の MySQL パラメータのステータス可変は Aurora MySQL に適用されません。
以下の MySQL ステータス可変は Aurora MySQL には適用されません。これはすべてを網羅したリストではありません。
+ `innodb_buffer_pool_bytes_dirty`
+ `innodb_buffer_pool_pages_dirty`
+ `innodb_buffer_pool_pages_flushed`
Aurora MySQL バージョン 3 は、Aurora MySQL バージョン 2 にあった次のステータス可変を削除します。
+ `AuroraDb_lockmgr_bitmaps0_in_use`
+ `AuroraDb_lockmgr_bitmaps1_in_use`
+ `AuroraDb_lockmgr_bitmaps_mem_used`
+ `AuroraDb_thread_deadlocks`
+ `available_alter_table_log_entries`
+ `Aurora_lockmgr_memory_used`
+ `Aurora_missing_history_on_replica_incidents`
+ `Aurora_new_lock_manager_lock_release_cnt`
+ `Aurora_new_lock_manager_lock_release_total_duration_micro`
+ `Aurora_new_lock_manager_lock_timeout_cnt`
+ `Aurora_total_op_memory`
+ `Aurora_total_op_temp_space`
+ `Aurora_used_alter_table_log_entries`
+ `Aurora_using_new_lock_manager`
+ `Aurora_volume_bytes_allocated`
+ `Aurora_volume_bytes_left_extent`
+ `Aurora_volume_bytes_left_total`
+ `Com_alter_db_upgrade`
+ `Compression`
+ `External_threads_connected`
+ `Innodb_available_undo_logs`
+ `Last_query_cost`
+ `Last_query_partial_plans`
+ `Slave_heartbeat_period`
+ `Slave_last_heartbeat`
+ `Slave_received_heartbeats`
+ `Slave_retried_transactions`
+ `Slave_running`
+ `Time_since_zero_connections`
これらの MySQL ステータス変数は、Aurora MySQL バージョン 2 で使用できますが、Aurora MySQL バージョン 3 では使用できません。
+ `Innodb_redo_log_enabled`
+ `Innodb_undo_tablespaces_total`
+ `Innodb_undo_tablespaces_implicit`
+ `Innodb_undo_tablespaces_explicit`
+ `Innodb_undo_tablespaces_active`
# Aurora MySQL の待機イベント
以下は、Aurora MySQL の代表的な待機イベントです。
**注記**
待機イベントを使用して Aurora MySQL のパフォーマンスを調整する方法については、「[待機イベントを使用した Aurora MySQL のチューニング](AuroraMySQL.Managing.Tuning.wait-events.md)」を参照してください。
MySQL の待機イベントで使用される命名規則については、MySQL ドキュメントの「[Performance Schema インストゥルメント命名規則](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html)」を参照してください。
**cpu**
実行可能なアクティブな接続の数が vCPUs 数よりも一貫して多くなります。詳細については、「[cpu](ams-waits.cpu.md)」を参照してください。
**io/aurora\$1redo\$1log\$1flush**
セッションは Aurora ストレージにデータを保持しています。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。詳細については、「[io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md)」を参照してください。
**io/aurora\$1respond\$1to\$1client**
Aurora MySQL バージョン 2.10.2 以降の 2.10 バージョン、2.09.3 以降の 2.09 バージョン、2.07.7 以降の 2.07 バージョンの場合、クエリ処理が完了すると、結果がアプリケーションクライアントに返されます。DB インスタンスクラスのネットワーク帯域幅と、返される結果セットのサイズを比較します。また、クライアント側の応答時間もチェックしてください。クライアントが応答せず、TCP パケットを処理できない場合、パケットドロップと TCP 再送信が発生する可能性があります。この状況は、ネットワーク帯域幅に悪影響を及ぼします。2.10.2、2.09.3、2.09.3、および 2.07.7 より前のバージョンでは、待機イベントにアイドル時間が誤って含まれます。この待機が目立つときにデータベースをチューニングする方法については、[io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) を参照してください。
**io/file/csv/data**
スレッドは Comma Separated Value (CSV) 形式でテーブルに書き込みます。CSV テーブルの使用状況を確認してください。通常、このイベントはテーブルでの `log_output` の設定に伴って発生します。
**io/file/sql/binlog**
スレッドは、ディスクに書き込まれるバイナリログ (binlog) ファイルを待っています。
**io/redo\$1log\$1flush**
セッションは Aurora ストレージにデータを保持しています。通常、この待機イベントは Aurora MySQL の書き込み I/O オペレーション用です。詳細については、「[io/redo\$1log\$1flush](ams-waits.io-redologflush.md)」を参照してください。
**io/socket/sql/client\$1connection**
`mysqld` プログラムは受信する新規クライアント接続を処理するためのスレッド作成でビジー状態です。詳細については、「[io/socket/sql/client\$1connection](ams-waits.client-connection.md)」を参照してください。
**io/table/sql/handler**
エンジンは、テーブルへのアクセスを待っています。このイベントは、データがバッファプールにキャッシュされているか、ディスク上でアクセスされているかにかかわらず、発生します。詳細については、「[io/table/sql/handler](ams-waits.waitio.md)」を参照してください。
**lock/table/sql/handler**
この待機イベントは、テーブルロック待機イベントハンドラです。Performance Schema の原始的イベントと分子的イベントの詳細については、MySQL ドキュメントの [Performance Schema の原子的および分子的イベント](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-atom-molecule-events.html)を参照してください。
**synch/cond/innodb/row\$1lock\$1wait**
複数のデータ操作言語 (DML) ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md)」を参照してください。
**synch/cond/innodb/row\$1lock\$1wait\$1cond**
複数の DML ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md)」を参照してください。
**synch/cond/sql/MDL\$1context::COND\$1wait\$1status**
スレッドは、テーブルのメタデータロックを待っています。エンジンは、このタイプのロックを使用して、データベーススキーマへの同時アクセスを管理し、データの整合性を確保します。詳細については、MySQL ドキュメントの「[ロック操作の最適化](https://dev.mysql.com/doc/refman/8.0/en/locking-issues.html)」を参照してください。この待機が目立つときにデータベースをチューニングする方法については、[synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) を参照してください。
**synch/cond/sql/MYSQL\$1BIN\$1LOG::COND\$1done**
バイナリログを有効にしている。高いコミットスループット、多数のトランザクションがコミットされている、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログレプリケーションや `aurora_binlog_*` パラメータの代わりにグローバルデータベースを使用します。
**synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex**
複数の DML ステートメントが同じデータベース行に同時にアクセスしようとしています。詳細については、「[synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md)」を参照してください。
**synch/mutex/innodb/buf\$1pool\$1mutex**
バッファプールが、ワーキング データ セットを保持するのに十分な大きさではありません。または、ワークロードが特定のテーブルからページにアクセスし、バッファプール内で競合が発生します。詳細については、「[synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md)」を参照してください。
**synch/mutex/innodb/fil\$1system\$1mutex**
プロセスは、テーブルスペースのメモリキャッシュへのアクセスを待っています。詳細については、「[synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md)」を参照してください。
**synch/mutex/innodb/trx\$1sys\$1mutex**
オペレーションは、一貫した、または制御された方法で InnoDB 内のトランザクション ID をチェック、更新、削除、または追加しています。これらの操作は `trx_sys` mutex 呼び出しを必要とします。これはパフォーマンススキーマインストルメンテーションによって追跡されます。操作には、データベースの起動時またはシャットダウン時のトランザクションシステムの管理、ロールバック、クリーンアップの取り消し、行の読み取りアクセス、およびバッファプールのロードが含まれます。トランザクション数が多い高データベース ロードは、この待機イベントの頻繁な発生につながります。詳細については、「[synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md)」を参照してください。
**synch/mutex/mysys/key\$1cache:: cache\$1lock**
`keycache->cache_lock` mutex は MyISAM テーブルのキーキャッシュへのアクセスを制御します。Aurora MySQL では MyISAM テーブルを使用して永続データを保存することはできませんが、内部一時テーブルの保存に使用されます。状況によっては、一時テーブルがメモリに収まらなくなるとディスクに書き込まれることがあるため、`created_tmp_tables` または `created_tmp_disk_tables` ステータスカウンターを確認することを検討してください。
**synch/mutex/sql/file\$1as\$1table:: LOCK\$1offsets**
エンジンは、テーブルメタデータファイルを開いたり作成したりするときに、このミューテックスを取得します。この待機イベントが過剰な頻度で発生すると、作成またはオープンされているテーブルの数が急増しています。
**synch/mutex/sql/FILE\$1AS\$1TABLE::LOCK\$1shim\$1lists**
エンジンは、`reset_size`、`detach_contents`、または `add_contents` のようなオペレーションを、オープンテーブルを追跡する内部構造上で実行しながら、このミューテックスを取得します。ミューテックスは、リストの内容へのアクセスを同期します。この待機イベントが高頻度で発生すると、以前にアクセスされたテーブルのセットが突然変化したことを示します。エンジンは、新しいテーブルにアクセスするか、以前にアクセスしたテーブルに関連するコンテキストを解放する必要があります。
**synch/mutex/sql/LOCK\$1open**
セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「[MySQL でのテーブルのオープンとクローズの方法](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)」を参照してください。
**synch/mutex/sql/LOCK\$1table\$1cache**
セッションが開いているテーブルの数が、テーブル定義キャッシュまたはテーブルオープンキャッシュのサイズを超えています。これらのキャッシュのサイズを増やします。詳細については、「[MySQL でのテーブルのオープンとクローズの方法](https://dev.mysql.com/doc/refman/8.0/en/table-cache.html)」を参照してください。
**synch/mutex/sql/LOG**
この待機イベントの場合、ログロックの待機中のスレッドがあります。例えば、スレッドは、スロークエリログファイルに書き込むためにロックを待っている場合があります。
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1commit**
この待機イベントの場合、バイナリログにコミットする目的でロック取得を待機中のスレッドがあります。変化率が非常に高いデータベースではバイナリログ記録の競合が発生する場合がありえます。使用している MySQL のバージョンによっては、バイナリログの整合性と耐久性の高さを保護するために使用される特定のロックがあります。RDS for MySQL の場合、バイナリログはレプリケーションと自動バックアッププロセスに使用されます。Aurora MySQL の場合、バイナリログはネイティブのレプリケーションやバックアップに必要ありません。バイナリログはデフォルトで無効になっていますが、これを有効にして外部のレプリケーションや変更データのキャプチャに使用できます。詳細については、MySQL ドキュメントの「[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)」を参照してください。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1dump\$1thread\$1metrics\$1collection**
バイナリログ記録がオンの場合、エンジンはアクティブなダンプスレッドのメトリクスをエンジンエラーログと内部オペレーションマップに出力する際、このミューテックスを取得します。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1inactive\$1binlogs\$1map**
バイナリログ記録がオンの場合、エンジンは最新のバイナリログファイルのリストに追加したり、そこから削除したり、検索したりする際に、このミューテックスを取得します。
**sync/mutex/sql/MYSQL\$1BIN\$1LOG:: LOCK\$1io\$1cache**
バイナリログがオンの場合、エンジンは Aurora binlog IO キャッシュ操作(割り当て、サイズ変更、解放、書き込み、読み取り、パージ、およびキャッシュ情報へのアクセス) 中にこのミューテックスを取得します。このイベントが頻繁に発生する場合、エンジンは binlog イベントが格納されているキャッシュにアクセスしています。待機時間を短縮するには、コミットを減らします。複数のステートメントを 1 つのトランザクションにグループ化してみてください。
**synch/mutex/sql/MYSQL\$1BIN\$1LOG::LOCK\$1log**
バイナリログを有効にしている。高いコミットスループット、多数のコミットしているトランザクション、またはバイナリログを読み取るレプリカがある可能性があります。複数行ステートメントを使用するか、ステートメントを 1 つのトランザクションにバンドルすることを検討してください。Aurora では、バイナリログ レプリケーションや `aurora_binlog_*` パラメータの代わりにグローバルデータベースを使用します。
**synch/mutex/sql/server\$1thread:: LOCK\$1sync**
ミューテックス `SERVER_THREAD::LOCK_sync` はファイル書き込みスレッドのスケジューリング、処理、または起動中に取得されます。この待機イベントが過剰に発生すると、データベース内の書き込みアクティビティが増加していることを示します。
**synch/mutex/sql/TABLESPACES:lock**
エンジンは、作成、削除、トランケート、および拡張のテーブルスペース オペレーション中に `TABLESPACES:lock` ミューテックスを取得します。この待機イベントが過剰に発生すると、テーブルスペース操作の頻度が高いことを示します。例として、大量のデータをデータベースにロードしています。
**synch/rwlock/innodb/dict**
この待機イベントの場合、InnoDB データディクショナリに保持されている rwlock を待機中のスレッドがあります。
**synch/rwlock/innodb/dict\$1operation\$1lock**
この待機イベントの場合、InnoDB データディクショナリのオペレーションのロックを保持しているスレッドがあります。
**synch/rwlock/innodb/dict sys RW lock**
データ定義言語コード (DDLs) 内の多数の同時データ制御言語ステートメント (DCLs) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDL への依存度を下げます。
**synch/rwlock/innodb/index\$1tree\$1rw\$1lock**
複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。
**synch/sxlock/innodb/dict\$1operation\$1lock**
データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。
**synch/sxlock/innodb/dict\$1sys\$1lock**
データ定義言語コード (DDL) 内の多数の同時データ制御言語ステートメント (DCL) が同時にトリガーされます。通常のアプリケーションアクティビティ中に、アプリケーションの DDLs への依存度を下げます。
**synch/sxlock/innodb/hash\$1table\$1locks**
セッションは、バッファプール内のページを見つけることができませんでした。エンジンは、ファイルを読み取るか、バッファプールの最も長い時間使われていない (LRU) リストを変更する必要があります。バッファキャッシュのサイズを増やし、関連するクエリのアクセスパスを改善することを検討してください。
**synch/sxlock/innodb/index\$1tree\$1rw\$1lock**
複数の類似したデータ操作言語 (DML) ステートメントが同じデータベースオブジェクトに同時にアクセスしようとしています。複数行ステートメントを使用してみてください。また異なるデータベースオブジェクトにワークロードを分散します。例えば、パーティショニングを実装します。
**synch/mutex/innodb/temp\$1pool\$1manager\$1mutex**
この待機イベントは、セッションがセッション一時テーブルスペースのプールを管理するためのミューテックスの取得を待機しているときに発生します。
同期待機イベントのトラブルシューティングの詳細は、「[Performance Insights で SYNCH 待機イベントを待機しているアクティブセッションの数が多いことが MySQL DB インスタンスに表示されているのはなぜですか?](https://aws.amazon.com/premiumsupport/knowledge-center/aurora-mysql-synch-wait-events/)」を参照してください。
# Aurora MySQL スレッド状態
以下は、Aurora MySQL の代表的な待機イベントです。
**許可の確認**
スレッドは、サーバーがステートメントを実行するために必要な権限を持っているかどうかをチェックしています。
**クエリキャッシュのクエリのチェック**
サーバーは、現在のクエリがクエリキャッシュに存在するかどうかをチェックしています。
**クリーンアップ**
これは、作業は完了しているがクライアントによってまだ閉じられていない接続の最終状態です。最善の解決策は、コード内の接続を明示的に閉じることです。または、パラメータグループの `wait_timeout` に、より低い値を設定することもできます。
**テーブルを閉じる**
スレッドは、変更されたテーブルデータをディスクにフラッシュし、使用されているテーブルを閉じています。高速操作ではない場合は、インスタンスクラスのネットワーク帯域幅に対するネットワーク帯域幅消費メトリックを確認します。また `table_open_cache` と `table_definition_cache` パラメータのパラメータ値が、十分なテーブルを同時に開ける状態かをチェックし、エンジンが頻繁にテーブルを開いたり閉じたりする必要がないようにします。これらのパラメータは、インスタンスのメモリ消費量に影響します。
**HEAP を MyISAM に変換する**
クエリは、一時テーブルをインメモリからディスク上に変換しています。この変換は、クエリ処理の中間ステップで MySQL によって作成された一時テーブルがメモリに対して大きすぎるため、必要になります。`tmp_table_size` と `max_heap_table_size` の値をチェックします。それ以降のバージョンでは、このスレッド状態名は `converting HEAP to ondisk` です。
**HEAP をオンディスクに変換する**
スレッドは、内部一時テーブルをインメモリテーブルからディスク上のテーブルに変換しています。
**tmp テーブルにコピーする**
スレッドが `ALTER TABLE` ステートメントを処理中です。この状態は、新しい構造を持つテーブルが作成された後、ローがそのテーブルにコピーされる前に発生します。この状態のスレッドの場合、パフォーマンススキーマを使用して、コピー操作の進行状況に関する情報を取得できます。
**ソートインデックスの作成**
Aurora MySQL は、既存のインデックスを使用して クエリの `ORDER BY` および `GROUP BY` 句を満たすことができないため、ソートを実行しています。詳細については、「[ソートインデックスの作成](ams-states.sort-index.md)」を参照してください。
**テーブルの作成**
スレッドは、永続テーブルまたは一時テーブルを作成しています。
**遅延コミット 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` ステートメントの行を読み取り、処理していますが、クライアントへのデータの送信はまだスタートされていません。このプロセスでは、クエリを満たすために必要な結果が含まれているページを特定します。詳細については、「[データの送信](ams-states.sending-data.md)」を参照してください。
**クライアントに送信する**
サーバーはクライアントにパケットを書き込んでいます。以前のバージョンの 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 DB クラスターのプライマリインスタンスでは、分離レベル `REPEATABLE READ`、`READ COMMITTED`、`READ UNCOMMITTED`、および `SERIALIZABLE` を使用できます。これらの分離レベルは、Aurora MySQL と RDS for MySQL で同じように機能します。
## リーダーインスタンスでの REPEATABLE READ の分離レベル
デフォルトでは、読み取り専用の Aurora レプリカとして設定された Aurora MySQL DB インスタンスは、常に `REPEATABLE READ` 分離レベルを使用します。これらの DB インスタンスは、`SET TRANSACTION ISOLATION LEVEL` ステートメントを無視し、引き続き `REPEATABLE READ` 分離レベルを使用します。
## リーダーインスタンスでの READ COMMITTED の分離レベル
アプリケーションのプライマリインスタンスに書き込み集中型のワークロードが含まれ、Aurora レプリカに長時間実行されるクエリが含まれている場合、かなりのパージラグが発生する可能性があります。*パージラグ*は、長時間実行されるクエリによって内部ガベージコレクションがブロックされた場合に発生します。確認できる症状は、`SHOW ENGINE INNODB STATUS` コマンドからの出力で `history list length` の値が高いことです。この値をモニタリングするには、CloudWatch の `RollbackSegmentHistoryListLength` メトリクスを使用します。大幅なパージラグが発生すると、セカンダリインデックスの有効性が低下し、全体的なクエリパフォーマンスの低下とストレージ領域の浪費が起きる可能性があります。
このような問題が発生した場合は、Aurora レプリカで `READ COMMITTED` 分離レベルを使用するように、Aurora MySQL セッションレベルの構成設定 `aurora_read_replica_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 の書き込み転送を使用する](aurora-global-database-write-forwarding.md)」を参照してください。
### リーダーでの READ COMMITTED の使用
Aurora レプリカで `READ COMMITTED` 分離レベルを使用するには、`aurora_read_replica_read_committed` 構成設定を `ON` に設定します。特定の Aurora レプリカに接続しているときに、セッションレベルでこの設定を使用します。有効にするには、以下の SQL コマンドを実行します。
```
set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;
```
この構成設定を一時的に有効にして、インタラクティブなアドホック (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` 設定は不要である可能性があります。長時間実行されるクエリと書き込み集中型のワークロードの組み合わせがなければ、履歴リストの長さに問題が発生することはほとんどありません。
**Example 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\$1table SELECT \$1 FROM other\$1table LIMIT 1000000; COMMIT; | | |
| T2 | | Q1: SELECT COUNT(\$1) FROM big\$1table; | Q2: SELECT COUNT(\$1) FROM big\$1table; |
| T3 | INSERT INTO big\$1table (c1, c2) VALUES (1, 'one more row'); COMMIT; | | |
| T4 | | Q1 が終了すると、結果は 1,000,000 になります。 | Q2 が終了すると、結果は 1,000,000 または 1,000,001 になります。 |
| T5 | DELETE FROM big\$1table LIMIT 2; COMMIT; | | |
| T6 | | Q1 が終了すると、結果は 1,000,000 になります。 | Q2 が終了すると、結果は 1,000,000、1,000,001、999,999、999,998 のいずれかになります。 |
| T7 | UPDATE big\$1table SET c2 = CONCAT(c2,c2,c2); COMMIT; | | |
| T8 | | Q1 が終了すると、結果は 1,000,000 になります。 | Q2 が終了すると、結果は 1,000,000、1,000,001、999,999、またはそれより大きい値になります。 |
| T9 | | Q3: SELECT COUNT(\$1) FROM big\$1table; | Q4: SELECT COUNT(\$1) FROM big\$1table; |
| T10 | | Q3 が終了すると、結果は 999,999 になります。 | Q4 が終了すると、結果は 999,999 になります。 |
| T11 | | Q5: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; | Q6: SELECT COUNT(\$1) FROM parent\$1table p JOIN child\$1table c ON (p.id = c.id) WHERE p.id = 1000; |
| T12 | INSERT INTO parent\$1table (id, s) VALUES (1000, 'hello'); INSERT INTO child\$1table (id, s) VALUES (1000, 'world'); COMMIT; | | |
| T13 | | Q5 が終了すると、結果は 0 になります。 | Q6 終了すると、結果は 0 または 1 になります。 |
他のトランザクションが DML ステートメントを実行してコミットする前にクエリが迅速に終了する場合、結果は予測可能であり、プライマリインスタンスでも Aurora レプリカでも同じ結果になります。最初のクエリから始めて、動作の違いを詳しく調べてみましょう。
プライマリインスタンスでの `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 Community Edition 8.0 で利用可能なすべてのヒントを使用できます。これらのヒントの詳細については、*MySQL リファレンスマニュアル*の「[オプティマイザヒント](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html)」を参照してください。
これらのヒントは、Aurora MySQL バージョン 2 で使用可能です。これらのヒントは、Aurora MySQL バージョン 2 のハッシュ結合特徴を使用するクエリ、特にパラレルクエリ最適化を使用するクエリに適用されます。
**PQ、NO\$1PQ**
オプティマイザが、テーブル単位またはクエリ単位、どちらのパラレルクエリを使用するかを指定します。
`PQ` は、指定されたテーブルまたはクエリ全体 (ブロック) に対して、オプティマイザがパラレルクエリを使用するよう強制します。`NO_PQ` は、指定されたテーブルまたはクエリ全体 (ブロック) に対して、オプティマイザがパラレルクエリを使用しないようにします。
このヒントは、Aurora MySQL バージョン 2.11 以降で使用可能です。以下の例では、このヒントの使用方法を示します。
テーブル名を指定した場合、オプティマイザは選択したテーブルにのみ `PQ/NO_PQ` ヒントを適用するようになります。テーブル名を指定しない場合、クエリブロックの影響を受けるすべてのテーブルに `PQ/NO_PQ` ヒントが強制されます。
```
EXPLAIN SELECT /*+ PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
EXPLAIN SELECT /*+ NO_PQ() */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1) */ f1, f2
FROM num1 t1 WHERE f1 > 10 and f2 < 100;
EXPLAIN SELECT /*+ NO_PQ(t1,t2) */ f1, f2
FROM num1 t1, num1 t2 WHERE t1.f1 = t2.f21;
```
**HASH\$1JOIN、NO\$1HASH\$1JOIN**
クエリにハッシュ結合最適化メソッドを使用するかどうかを選択するパラレルクエリオプティマイザの機能をオンまたはオフにします。`HASH_JOIN` は、そのメカニズムがより効率的である場合、オプティマイザがハッシュ結合を使用できるようにします。`NO_HASH_JOIN` は、オプティマイザがクエリにハッシュ結合を使用できないようにします。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。Aurora MySQL バージョン 3 では効果がありません。
以下の例では、このヒントの使用方法を示します。
```
EXPLAIN SELECT/*+ HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ NO_HASH_JOIN(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1PROBING、NO\$1HASH\$1JOIN\$1PROBING**
ハッシュ結合クエリで、結合のプローブ側に指定されたテーブルを使用するかどうかを指定します。クエリは、プローブテーブルの内容全体を読み取る代わりに、構築テーブルの列値がプローブテーブルに存在するかどうかをテストします。`HASH_JOIN_PROBING` および `HASH_JOIN_BUILDING` を使用して、クエリテキスト内のテーブルを並べ替えることなく、ハッシュ結合クエリの処理方法を指定できます。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。Aurora MySQL バージョン 3 では効果がありません。
以下の例では、このヒントの使用方法を示します。テーブル `HASH_JOIN_PROBING` の `T2` ヒントを指定することは、テーブル `NO_HASH_JOIN_PROBING` に `T1` を指定するのと同じ効果があります。
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_PROBING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_PROBING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**HASH\$1JOIN\$1BUILDING、NO\$1HASH\$1JOIN\$1BUILDING**
ハッシュ結合クエリで、結合の構築側に指定されたテーブルを使用するかどうかを指定します。クエリは、このテーブルのすべての行を処理し、他のテーブルと相互参照する列値のリストを作成します。`HASH_JOIN_PROBING` および `HASH_JOIN_BUILDING` を使用して、クエリテキスト内のテーブルを並べ替えることなく、ハッシュ結合クエリの処理方法を指定できます。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。Aurora MySQL バージョン 3 では効果がありません。
以下の例では、このヒントの使用方法を示します。テーブル `HASH_JOIN_BUILDING` の `T2` ヒントを指定することは、テーブル `NO_HASH_JOIN_BUILDING` に `T1` を指定するのと同じ効果があります。
```
EXPLAIN SELECT /*+ HASH_JOIN(t2) HASH_JOIN_BUILDING(t2) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
EXPLAIN SELECT /*+ HASH_JOIN(t2) NO_HASH_JOIN_BUILDING(t1) */ f1, f2
FROM t1, t2 WHERE t1.f1 = t2.f1;
```
**JOIN\$1FIXED\$1ORDER**
クエリ内のテーブルが、クエリにリストされている順序に基づいて結合されるように指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。これは、MySQL `STRAIGHT_JOIN` の代替となることを目的とし、MySQL [JOIN\$1FIXED\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) ヒントに相当します。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。
以下の例では、このヒントの使用方法を示します。
```
EXPLAIN SELECT /*+ JOIN_FIXED_ORDER() */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1ORDER**
クエリ内のテーブルの結合順序を指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。MySQL [JOIN\$1ORDER](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) ヒントに相当します。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。
以下の例では、このヒントの使用方法を示します。
```
EXPLAIN SELECT /*+ JOIN_ORDER (t4, t2, t1, t3) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1PREFIX**
結合順序の先頭に配置するテーブルを指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。MySQL [JOIN\$1PREFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) ヒントに相当します。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。
以下の例では、このヒントの使用方法を示します。
```
EXPLAIN SELECT /*+ JOIN_PREFIX (t4, t2) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
**JOIN\$1SUFFIX**
結合順で最後に配置するテーブルを指定します。これは、3 つ以上のテーブルを含むクエリで特に便利です。MySQL [JOIN\$1SUFFIX](https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html) ヒントに相当します。このヒントは、Aurora MySQL バージョン 2.08 以降で使用可能です。
以下の例では、このヒントの使用方法を示します。
```
EXPLAIN SELECT /*+ JOIN_SUFFIX (t1) */ f1, f2
FROM t1 JOIN t2 USING (id) JOIN t3 USING (id) JOIN t4 USING (id);
```
ハッシュ結合クエリの使用方法については、「[ハッシュ結合を使用した大規模な Aurora MySQL 結合クエリの最適化](AuroraMySQL.BestPractices.Performance.md#Aurora.BestPractices.HashJoin)」を参照してください。
# Aurora MySQL ストアドプロシージャリファレンス
Aurora MySQL DB クラスターを管理するには、組み込みストアドプロシージャを呼び出します。
**Topics**
+ [グローバルステータス履歴の収集と維持](mysql-stored-proc-gsh.md)
+ [バイナリログレプリケーションの設定、開始、停止](mysql-stored-proc-replicating.md)
+ [セッションやクエリの終了](mysql-stored-proc-ending.md)
+ [GTID を使用したトランザクションのレプリケーション](mysql-stored-proc-gtid.md)
+ [クエリログのローテーション](mysql-stored-proc-logging.md)
+ [バイナリログ構成の設定と表示](mysql-stored-proc-configuring.md)
# グローバルステータス履歴の収集と維持
Amazon RDS は、ステータス変数の値のスナップショットを掲示的に取得し、前回のスナップショット後の変化とともにテーブルに書き込む一連のプロシージャを提供します。このインフラストラクチャは Global Status History (GoSH) と呼ばれます。詳細については、「[Managing the Global Status History](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH)」(Global Status History の管理) を参照してください。
以下のストアドプロシージャは、Global Status History (GoSH) の収集方法と保守方法を管理します。
**Topics**
+ [mysql.rds\$1collect\$1global\$1status\$1history](#mysql_rds_collect_global_status_history)
+ [mysql.rds\$1disable\$1gsh\$1collector](#mysql_rds_disable_gsh_collector)
+ [mysql.rds\$1disable\$1gsh\$1rotation](#mysql_rds_disable_gsh_rotation)
+ [mysql.rds\$1enable\$1gsh\$1collector](#mysql_rds_enable_gsh_collector)
+ [mysql.rds\$1enable\$1gsh\$1rotation](#mysql_rds_enable_gsh_rotation)
+ [mysql.rds\$1rotate\$1global\$1status\$1history](#mysql_rds_rotate_global_status_history)
+ [mysql.rds\$1set\$1gsh\$1collector](#mysql_rds_set_gsh_collector)
+ [mysql.rds\$1set\$1gsh\$1rotation](#mysql_rds_set_gsh_rotation)
## mysql.rds\$1collect\$1global\$1status\$1history
Global Status History (GoSH) のスナップショットをオンデマンドで作成します。
### 構文
```
CALL mysql.rds_collect_global_status_history;
```
## mysql.rds\$1disable\$1gsh\$1collector
Global Status History (GoSH) によって作成されたスナップショットを無効にします。
### 構文
```
CALL mysql.rds_disable_gsh_collector;
```
## mysql.rds\$1disable\$1gsh\$1rotation
`mysql.global_status_history` テーブルのローテーションをオフにします。
### 構文
```
CALL mysql.rds_disable_gsh_rotation;
```
## mysql.rds\$1enable\$1gsh\$1collector
Global Status History (GoSH) をオンにして、`rds_set_gsh_collector` で指定された間隔でデフォルトのスナップショットを作成します。
### 構文
```
CALL mysql.rds_enable_gsh_collector;
```
## mysql.rds\$1enable\$1gsh\$1rotation
`rds_set_gsh_rotation` で指定された間隔での `mysql.global_status_history` テーブルのコンテンツの `mysql.global_status_history_old` へのローテーションをオンにします。
### 構文
```
CALL mysql.rds_enable_gsh_rotation;
```
## mysql.rds\$1rotate\$1global\$1status\$1history
`mysql.global_status_history` テーブルのコンテンツを `mysql.global_status_history_old` にオンデマンドでローテーションします。
### 構文
```
CALL mysql.rds_rotate_global_status_history;
```
## mysql.rds\$1set\$1gsh\$1collector
Global Status History (GoSH) によって作成されたスナップショットの間隔を分単位で指定します。
### 構文
```
CALL mysql.rds_set_gsh_collector(intervalPeriod);
```
### パラメータ
*intervalPeriod*
スナップショット作成の間隔 (分単位)。デフォルト値は `5` です。
## mysql.rds\$1set\$1gsh\$1rotation
`mysql.global_status_history` テーブルのローテーション間隔を日単位で指定します。
### 構文
```
CALL mysql.rds_set_gsh_rotation(intervalPeriod);
```
### パラメータ
*intervalPeriod*
テーブルのローテーション間隔 (日単位)。デフォルト値は `7` です。
# バイナリログレプリケーションの設定、開始、停止
Aurora MySQL クラスターのプライマリインスタンスに接続している間に、次のストアドプロシージャを呼び出すことができます。これらのプロシージャでは、トランザクションが外部データベースから Aurora MySQL、または Aurora MySQL から外部データベースに複製される方法を管理します。
**Topics**
+ [mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL バージョン 2)](#mysql_rds_disable_session_binlog)
+ [mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL バージョン 2)](#mysql_rds_enable_session_binlog)
+ [mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material)
+ [mysql.rds\$1next\$1master\$1log (Aurora MySQL バージョン 2)](#mysql_rds_next_master_log)
+ [mysql.rds\$1next\$1source\$1log (Aurora MySQL バージョン 3)](#mysql_rds_next_source_log)
+ [mysql.rds\$1remove\$1binlog\$1ssl\$1material](#mysql_rds_remove_binlog_ssl_material)
+ [mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_reset_external_master)
+ [mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_reset_external_source)
+ [mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl)
+ [mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master)
+ [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source)
+ [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master_with_auto_position)
+ [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source_with_auto_position)
+ [mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL バージョン 2)](#mysql_rds_set_master_auto_position)
+ [mysql.rds\$1set\$1read\$1only (Aurora MySQL バージョン 3)](#mysql_rds_set_read_only)
+ [mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL バージョン 2)](#mysql_rds_set_session_binlog_format)
+ [mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_source_auto_position)
+ [mysql.rds\$1skip\$1repl\$1error](#mysql_rds_skip_repl_error)
+ [mysql.rds\$1start\$1replication](#mysql_rds_start_replication)
+ [mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until)
+ [mysql.rds\$1stop\$1replication](#mysql_rds_stop_replication)
## mysql.rds\$1disable\$1session\$1binlog (Aurora MySQL バージョン 2)
`sql_log_bin` 変数を `OFF` に設定することにより、現在のセッションのバイナリログをオフにします。
### 構文
```
CALL mysql.rds_disable_session_binlog;
```
### パラメータ
なし
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。
**注記**
Aurora MySQL バージョン 3 では、`SESSION_VARIABLES_ADMIN` 権限を持っている場合、次のコマンドを使用して現在のセッションのバイナリログ記録を無効にできます。
```
SET SESSION sql_log_bin = OFF;
```
## mysql.rds\$1enable\$1session\$1binlog (Aurora MySQL バージョン 2)
`sql_log_bin` 変数を `ON` に設定することにより、現在のセッションのバイナリログをオンにします。
### 構文
```
CALL mysql.rds_enable_session_binlog;
```
### パラメータ
なし
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。
**注記**
Aurora MySQL バージョン 3 では、`SESSION_VARIABLES_ADMIN` 権限を持っている場合、次のコマンドを使用して現在のセッションのバイナリログ記録を有効にできます。
```
SET SESSION sql_log_bin = ON;
```
## mysql.rds\$1import\$1binlog\$1ssl\$1material
認証局証明書、クライアント証明書、およびクライアントキーを Aurora MySQL DB クラスターにインポートします。この情報は SSL 通信および暗号化レプリケーションに必要です。
**注記**
現在、この手順は、Aurora MySQL バージョン 2 (2.09.2、2.10.0、2.10.1、2.11.0) とバージョン 3 (3.01.1 以降) でサポートされています。
### 構文
```
CALL mysql.rds_import_binlog_ssl_material (
ssl_material
);
```
### パラメータ
*ssl\$1material*
MySQL クライアント用の以下の .pem 形式のコンテンツを含む JSON ペイロード。
+ "ssl\$1ca":"*認証局証明書*"
+ "ssl\$1cert":"*クライアント証明書*"
+ "ssl\$1key":"*クライアントキー*"
### 使用に関する注意事項
この手順を実行する前に、暗号化レプリケーションを準備します。
+ 外部の MySQL 出典データベースインスタンスで有効になった SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアントの証明書を生成します。
+ SSL が外部出典データベースインスタンスで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL 出典データベースインスタンスで SSL の設定に使用した認証局キーが必要です。
詳細については、MySQL ドキュメントの「[Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)」を参照してください。
**重要**
暗号化レプリケーションをじゅんびしたら、SSL 接続を使用してこの手順を実行します。クライアントのキーは、安全ではない接続で転送するべきではありません。
この手順では、外部の MySQL データベースから SSL 情報を Aurora MySQL DB クラスターにインポートします。SSL 情報は、Aurora MySQL DB クラスター用の SSL 情報が含まれる .pem 形式のファイルにあります。暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。
上記のファイルからこの情報を正しい JSON ペイロードで `ssl_material` パラメータにコピーできます。暗号化レプリケーションをサポートするために、この SSL 情報を Aurora MySQL DB クラスターにインポートします。
JSON ペイロードは、次のようになります。
```
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
ssl_ca_pem_body_code
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
ssl_cert_pem_body_code
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
ssl_key_pem_body_code
-----END RSA PRIVATE KEY-----\n"}'
```
### 例
次の例では、SSL 情報を Aurora MySQL にインポートします。.pem 形式ファイルでは、通常の場合、コード本文に例に示されるコード本文より長くなっています。
```
call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');
```
## mysql.rds\$1next\$1master\$1log (Aurora MySQL バージョン 2)
出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。
### 構文
```
CALL mysql.rds_next_master_log(
curr_master_log
);
```
### パラメータ
*curr\$1master\$1log*
現在のマスターログファイルのインデックス。例えば、現在のファイルが `mysql-bin-changelog.012345` という名前の場合は、インデックスは 12345 になります。現在のマスターログファイルの名前を調べるには、`SHOW REPLICA STATUS` コマンドを実行し、`Master_Log_File` フィールドを確認します。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_next_master_log` を実行する必要があります。
**警告**
`mysql.rds_next_master_log` は、レプリケーション出典であるマルチ AZ DB インスタンスのフェイルオーバーの後でレプリケーションが失敗し、`Last_IO_Errno` の `SHOW REPLICA STATUS` フィールドが I/O エラー 1236 を示している場合にのみ呼び出してください。
`mysql.rds_next_master_log` を呼び出すと、フェイルオーバーイベントが発生する前にソースインスタンスのトランザクションがディスク上のバイナリログに書き込まれなかった場合、リードレプリカのデータが失われる可能性があります。
### 例
Aurora MySQL リードレプリカでレプリケーションが失敗すると仮定します。リードレプリカで `SHOW REPLICA STATUS\G` を実行すると、次の結果が返されます。
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Master: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` フィールドはインスタンスが I/O エラー 1236 を受け取ったことを示します。`Master_Log_File` フィールドは、ファイル名が `mysql-bin-changelog.012345` であることを示しています。これは、ログファイルのインデックスが `12345` であることを表しています。エラーを解決するには、次のパラメータを使用して `mysql.rds_next_master_log` を呼び出すことができます。
```
CALL mysql.rds_next_master_log(12345);
```
## mysql.rds\$1next\$1source\$1log (Aurora MySQL バージョン 3)
出典データベースインスタンスのログの位置を、出典データベースインスタンスの次のバイナリログの先頭に変更します。このプロシージャは、リードレプリカでレプリケーション I/O エラー 1236 が発生した場合にのみ使用してください。
### 構文
```
CALL mysql.rds_next_source_log(
curr_source_log
);
```
### パラメータ
*curr\$1source\$1log*
現在のソースログファイルのインデックス。例えば、現在のファイルが `mysql-bin-changelog.012345` という名前の場合は、インデックスは 12345 になります。現在のソースログファイルの名前を調べるには、`SHOW REPLICA STATUS` コマンドを実行し、`Source_Log_File` フィールドを確認します。
### 使用に関する注意事項
管理ユーザーは、`mysql.rds_next_source_log`プロシージャを実行すべきです。
**警告**
`mysql.rds_next_source_log` は、レプリケーション出典であるマルチ AZ DB インスタンスのフェイルオーバーの後でレプリケーションが失敗し、`Last_IO_Errno` の `SHOW REPLICA STATUS` フィールドが I/O エラー 1236 を示している場合にのみ呼び出してください。
`mysql.rds_next_source_log` を呼び出すと、フェイルオーバーイベントが発生する前にソースインスタンスのトランザクションがディスク上のバイナリログに書き込まれなかった場合、リードレプリカのデータが失われる可能性があります。ソースインスタンスのパラメータ `sync_binlog` および `innodb_support_xa` を `1` に設定することで、このような問題が発生する可能性を軽減できますが、パフォーマンスが低下する恐れがあります。詳細については、
### 例
Aurora MySQL リードレプリカでレプリケーションが失敗すると仮定します。リードレプリカで `SHOW REPLICA STATUS\G` を実行すると、次の結果が返されます。
```
*************************** 1. row ***************************
Replica_IO_State:
Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com
Source_User: MasterUser
Source_Port: 3306
Connect_Retry: 10
Source_Log_File: mysql-bin-changelog.012345
Read_Source_Log_Pos: 1219393
Relay_Log_File: relaylog.012340
Relay_Log_Pos: 30223388
Relay_Source_Log_File: mysql-bin-changelog.012345
Replica_IO_Running: No
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 30223232
Relay_Log_Space: 5248928866
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 67285976
```
`Last_IO_Errno` フィールドはインスタンスが I/O エラー 1236 を受け取ったことを示します。`Source_Log_File` フィールドは、ファイル名が `mysql-bin-changelog.012345` であることを示しています。これは、ログファイルのインデックスが `12345` であることを表しています。エラーを解決するには、次のパラメータを使用して `mysql.rds_next_source_log` を呼び出すことができます。
```
CALL mysql.rds_next_source_log(12345);
```
## mysql.rds\$1remove\$1binlog\$1ssl\$1material
SSL 通信と暗号化レプリケーション用の認証局証明書、クライアント証明書およびクライアントキーを削除します。[mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) を使用してこの情報をインポートします。
### 構文
```
CALL mysql.rds_remove_binlog_ssl_material;
```
## mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
CALL mysql.rds_reset_external_master;
```
### 使用に関する注意事項
マスターユーザーが `mysql.rds_reset_external_master` を実行する必要があります。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとしての設定が解除される MySQL DB インスタンス上で実行する必要があります。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
レプリケーションを使用して、Aurora MySQL の外部で実行している MySQL インスタンスからデータをインポートする方法の詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
## mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用しないように再設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
CALL mysql.rds_reset_external_source;
```
### 使用に関する注意事項
管理ユーザーは、`mysql.rds_reset_external_source`プロシージャを実行すべきです。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとしての設定が解除される MySQL DB インスタンス上で実行する必要があります。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
## mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)
バイナリログレプリケーションの `SOURCE_SSL` 暗号化を有効にします。詳細については、MySQL ドキュメントの「[CHANGE REPLICATION SOURCE TO ステートメント](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)」を参照してください。
### 構文
```
CALL mysql.rds_set_binlog_source_ssl(mode);
```
### パラメータ
*モード*
`SOURCE_SSL` 暗号化が有効になっているかを示す次の値:
+ `0` – `SOURCE_SSL` 暗号化は無効になっています。デフォルトは `0` です。
+ `1` – `SOURCE_SSL` 暗号化は有効にされています。SSL または TLS を使用して暗号化を設定できます。
### 使用に関する注意事項
このプロシージャは、Aurora MySQL バージョン 3.06 以降でサポートされています。
## mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用するように設定します。
`mysql.rds_set_external_master` プロシージャは廃止されており、将来のリリースでは削除されます。代わりに `mysql.rds\$1set\$1external\$1source` を使用します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
CALL mysql.rds_set_external_master (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### パラメータ
*host\$1name*
出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Amazon RDS の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*mysql\$1binary\$1log\$1file\$1name*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。
binlog ファイルの名前と場所は、`SHOW MASTER STATUS`出典データベースインスタンス上で実行することによって決定できます。
*ssl\$1encryption*
レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。
`MASTER_SSL_VERIFY_SERVER_CERT` オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_set_external_master` を実行する必要があります。このプロシージャは、Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとして設定される MySQL DB インスタンス上で実行する必要があります。
`mysql.rds_set_external_master` を実行する前に、Amazon RDS の外部で動作する MySQL インスタンスを出典データベースインスタンスとして必ず設定してください。Amazon RDS の外部で動作する MySQL インスタンスに接続するには、MySQL の外部インスタンスの `replication_user_name` および `replication_user_password` アクセス権限を持つレプリケーションユーザーを示す `REPLICATION CLIENT` および `REPLICATION SLAVE` の値を指定する必要があります。
**MySQL の外部インスタンスを出典データベースインスタンスとして設定するには**
1. 選択した MySQL クライアントを使用して、MySQL の外部インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。以下に例を示します。
**MySQL 5.7**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. MySQL の外部インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl\$1user」ユーザーに、すべてのデータベースの `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限を付与します。
**MySQL 5.7**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**MySQL 8.0**
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
暗号化されたレプリケーションを使用するには、SSL 接続を使用するようにソースデータベースインスタンスを設定します。また、[mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) 手順を使用して、DB インスタンスあるいは DB クラスターに認証局証明書、クライアント証明書およびクライアントキーをインポートします。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
`mysql.rds_set_external_master` を呼び出して Amazon RDS DB インスタンスをリードレプリカとして設定した後で、このリードレプリカで [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) を呼び出してレプリケーションプロセスをスタートできます。[mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_reset_external_master) を呼び出して、リードレプリカの設定を削除することもできます。
`mysql.rds_set_external_master` が呼び出されると、Amazon RDS では、時刻、ユーザー、`set master` アクションが `mysql.rds_history` テーブルと `mysql.rds_replication_status` テーブルに記録されます。
### 例
MySQL DB インスタンス上で実行すると、DB インスタンスが Amazon RDS の外部で動作する MySQL インスタンスのリードレプリカとして設定されます。次に例を示します。
```
call mysql.rds_set_external_master(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)
Aurora MySQL DB インスタンスを、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして使用するように設定します。
**重要**
この手順を実行するには、`autocommit` を有効にする必要があります。これを有効にするには、`autocommit` パラメータを `1` に設定します。パラメータの変更については、「[Amazon Aurora の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
### 構文
```
CALL mysql.rds_set_external_source (
host_name
, host_port
, replication_user_name
, replication_user_password
, mysql_binary_log_file_name
, mysql_binary_log_file_location
, ssl_encryption
);
```
### パラメータ
*host\$1name*
出典データベースインスタンスとなる、Amazon RDS の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Amazon RDS の外部で動作する MySQL インスタンス (出典データベースインスタンス) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Amazon RDS の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*mysql\$1binary\$1log\$1file\$1name*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*mysql\$1binary\$1log\$1file\$1location*
`mysql_binary_log_file_name` バイナリログ内の場所。レプリケーションでは、この場所からレプリケーション情報の読み取りをスタートします。
binlog ファイルの名前と場所は、`SHOW MASTER STATUS`出典データベースインスタンス上で実行することによって決定できます。
*ssl\$1encryption*
レプリケーション接続で Secure Socket Layer (SSL) 暗号化を使用するかどうかを指定する値。1 は SSL 暗号化を使用することを指定し、0 は暗号化を使用しないことを指定します。デフォルトは 0 です。
このオプションを有効にするには、[mysql.rds\$1import\$1binlog\$1ssl\$1material](#mysql_rds_import_binlog_ssl_material) を使用してカスタム SSL 証明書をインポートしておく必要があります。カスタム SSL 証明書をインポートしていない場合は、このパラメータを 0 に設定し、[mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl) を使用してバイナリログレプリケーション用の SSL を有効にします。
`SOURCE_SSL_VERIFY_SERVER_CERT` オプションはサポートされていません。このオプションは 0 に設定されます。つまり、接続は暗号化されますが、証明書は検証されません。
### 使用に関する注意事項
管理ユーザーは、`mysql.rds_set_external_source`プロシージャを実行すべきです。このプロシージャは、Amazon RDS の外部で実行している MySQL インスタンスのリードレプリカとして設定される Aurora MySQL DB インスタンス上で実行する必要があります。
`mysql.rds_set_external_source` を実行する前に、Amazon RDS の外部で動作する MySQL インスタンスを出典データベースインスタンスとして必ず設定してください。Amazon RDS の外部で動作する MySQL インスタンスに接続するには、MySQL の外部インスタンスの `replication_user_name` および `replication_user_password` アクセス権限を持つレプリケーションユーザーを示す `REPLICATION CLIENT` および `REPLICATION SLAVE` の値を指定する必要があります。
**MySQL の外部インスタンスを出典データベースインスタンスとして設定するには**
1. 選択した MySQL クライアントを使用して、MySQL の外部インスタンスに接続し、レプリケーションに使用されるユーザーアカウントを作成します。以下に例を示します。
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外のパスワードを指定してください。
1. MySQL の外部インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の権限をレプリケーションユーザーに付与します。次の例では、ドメインの 「repl\$1user」ユーザーに、すべてのデータベースの `REPLICATION CLIENT` および `REPLICATION SLAVE` 特権を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com';
```
暗号化されたレプリケーションを使用するには、SSL 接続を使用するように出典データベースインスタンスを設定します。また、[mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html) プロシージャを使用して、DB インスタンスまたは DB クラスターに認証局証明書、クライアント証明書、およびクライアントキーをインポートします。
**注記**
これらのストアドプロシージャは、主に Amazon RDS 外部で実行されている MySQL インスタンスのレプリケーションの有効化のために提供されています。可能な場合は、Aurora MySQL DB クラスター内のレプリケーションを管理するために、Aurora レプリカを使用することをお勧めします。Aurora MySQL DB クラスターでのレプリカの管理については、「[Aurora レプリカの使用](AuroraMySQL.Replication.md#AuroraMySQL.Replication.Replicas)」を参照してください。
`mysql.rds_set_external_source` を呼び出して Aurora MySQL DB インスタンスをリードレプリカとして設定したら、このリードレプリカで [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) を呼び出してレプリケーションプロセスを開始できます。[mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_reset_external_source) を呼び出して、リードレプリカの設定を削除することもできます。
`mysql.rds_set_external_source` が呼び出されると、Amazon RDS では、時刻、ユーザー、`set master` アクションが `mysql.rds_history` テーブルと `mysql.rds_replication_status` テーブルに記録されます。
### 例
Aurora MySQL DB インスタンスで実行すると、次の例に示されているように、DB インスタンスが Amazon RDS の外部で実行されている MySQL インスタンスのリードレプリカとして設定されます。
```
call mysql.rds_set_external_source(
'Externaldb.some.com',
3306,
'repl_user',
'password',
'mysql-bin-changelog.0777',
120,
1);
```
## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (Aurora MySQL バージョン 2)
外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。
Aurora MySQL は遅延レプリケーションをサポートしていないため、この手順では遅延レプリケーションは設定されません。
### 構文
```
CALL mysql.rds_set_external_master_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### パラメータ
*host\$1name*
レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Aurora の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*ssl\$1encryption*
このオプションは、現在実装されていません。デフォルトは 0 です。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
マスターユーザーが `mysql.rds_set_external_master_with_auto_position` を実行する必要があります。マスターユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこのプロシージャを実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。
この手順は Aurora MySQL バージョン 2 でサポートされています。Aurora MySQL バージョン 3 の場合は、[mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source_with_auto_position)代わりにプロシージャを使用します。
`mysql.rds_set_external_master_with_auto_position` を実行する前に、外部の MySQL 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'
```
1. 外部の MySQL インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。次の例では、ドメインの `REPLICATION CLIENT` ユーザーに、すべてのデータベースの `REPLICATION SLAVE` および `'repl_user'` 権限を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
`mysql.rds_set_external_master_with_auto_position` を呼び出すと、Amazon RDS によって特定の情報が記録されます。この情報には、時刻、ユーザー、`"set master"` の `mysql.rds_history` テーブルの `mysql.rds_replication_status` のアクションがあります。
問題の原因となることが知られている特定の GTID ベースの処理をスキップするには、[mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
### 例
Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。
```
call mysql.rds_set_external_master_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (Aurora MySQL バージョン 3)
外部の MySQL インスタンスからの受信レプリケーションを受け入れるように Aurora MySQL プライマリインスタンスを設定します。このプロシージャでも、グローバルトランザクション識別子 (GTIDs) に基づき、レプリケーションが設定されます。
### 構文
```
CALL mysql.rds_set_external_source_with_auto_position (
host_name
, host_port
, replication_user_name
, replication_user_password
, ssl_encryption
);
```
### パラメータ
*host\$1name*
レプリケーションソースとなる、Aurora の外部で動作する MySQL インスタンスのホスト名または IP アドレス。
*host\$1port*
Aurora の外部で動作する MySQL インスタンス (レプリケーションソース) で使用されるポート。ポート番号を変換する Secure Shell (SSH) ポートのレプリケーションがネットワーク設定に含まれる場合、SSH によって発行されるポート番号を指定します。
*replication\$1user\$1name*
Aurora の外部で実行される MySQL インスタンスの `REPLICATION CLIENT` および `REPLICATION SLAVE` のアクセス許可を持つユーザーの ID。外部インスタンスのレプリケーション専用のアカウントを使用することをお勧めします。
*replication\$1user\$1password*
`replication_user_name` で指定されたユーザー ID のパスワード。
*ssl\$1encryption*
このオプションは、現在実装されていません。デフォルトは 0 です。
[mysql.rds\$1set\$1binlog\$1source\$1ssl (Aurora MySQL バージョン 3)](#mysql_rds_set_binlog_source_ssl) を使用して、バイナリログレプリケーション用の SSL を有効にします。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
管理ユーザーは、`mysql.rds_set_external_source_with_auto_position`プロシージャを実行しなければなりません。管理ユーザーは、レプリケーションターゲットとして機能する Aurora MySQL DB クラスターのプライマリインスタンスでこのプロシージャを実行します。例えば、外部の MySQL DB インスタンスまたは Aurora MySQL DB クラスターのレプリケーションターゲットになります。
このプロシージャは Aurora MySQL バージョン 3 でサポートされています。Aurora MySQL は遅延レプリケーションをサポートしていないため、この手順では遅延レプリケーションは設定されません。
`mysql.rds_set_external_source_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'
```
1. 外部の MySQL インスタンスで、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。次の例では、ドメインの `REPLICATION CLIENT` ユーザーに、すべてのデータベースの `REPLICATION SLAVE` および `'repl_user'` 権限を付与します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'
IDENTIFIED BY 'SomePassW0rd'
```
`mysql.rds_set_external_source_with_auto_position` を呼び出すと、Amazon RDS によって特定の情報が記録されます。この情報には、時刻、ユーザー、`"set master"` の `mysql.rds_history` テーブルの `mysql.rds_replication_status` のアクションがあります。
問題の原因となることが知られている特定の GTID ベースの処理をスキップするには、[mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid) ストアドプロシージャを使用します。GTID ベースのレプリケーションの使用に関する詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
### 例
Aurora プライマリインスタンス上で実行すると、以下の例では、Aurora の外部で動作する MySQL のインスタンスのリードレプリカとして動作するように Aurora クラスターを設定します。
```
call mysql.rds_set_external_source_with_auto_position(
'Externaldb.some.com',
3306,
'repl_user'@'mydomain.com',
'SomePassW0rd');
```
## mysql.rds\$1set\$1master\$1auto\$1position (Aurora MySQL バージョン 2)
バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTID) ベースのレプリケーションモードを設定します。
### 構文
```
CALL mysql.rds_set_master_auto_position (
auto_position_mode
);
```
### パラメータ
*auto\$1position\$1mode*
ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:
+ `0` - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルトは `0` です。
+ `1` - GTID ベースのレプリケーション方法を使用します。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_set_master_auto_position` を実行する必要があります。
この手順は Aurora MySQL バージョン 2 でサポートされています。
## mysql.rds\$1set\$1read\$1only (Aurora MySQL バージョン 3)
DB インスタンスの `read_only` モードをグローバルにオンまたはオフにします。
### 構文
```
CALL mysql.rds_set_read_only(mode);
```
### パラメータ
*モード*
DB インスタンスの `read_only` モードがグローバルにオンまたはオフになっているかを示す値。
+ `0` – `OFF`。デフォルトは `0` です。
+ `1` – `ON`
### 使用に関する注意事項
`mysql.rds_set_read_only` ストアドプロシージャは `read_only` パラメータのみを変更します。`innodb_read_only` パラメータはリーダー DB インスタンスでは変更できません。
`read_only` パラメータの変更は再起動しても持続しません。`read_only` に永続的な変更を加えるには、`read_only` DB クラスターパラメータを使用する必要があります。
このプロシージャは、Aurora MySQL バージョン 3.06 以降でサポートされています。
## mysql.rds\$1set\$1session\$1binlog\$1format (Aurora MySQL バージョン 2)
現在のセッションのバイナリログ形式を設定します。
### 構文
```
CALL mysql.rds_set_session_binlog_format(format);
```
### パラメータ
*format*
現在のセッションのバイナリログ形式を示す値:
+ `STATEMENT` — レプリケーションソースは、SQL ステートメントに基づいてバイナリログにイベントを書き込みます。
+ `ROW` — レプリケーションソースは、個々のテーブル行の変更を示すイベントをバイナリログに書き込みます。
+ `MIXED` — ロギングは通常、SQL ステートメントに基づきますが、特定の条件下では行に切り替わります。詳細については、MySQL ドキュメントの「[混合バイナリログ形式](https://dev.mysql.com/doc/refman/8.0/en/binary-log-mixed.html)」を参照してください。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
このストアドプロシージャを使用するには、現在のセッションに対してバイナリログが設定されている必要があります。
Aurora では、このプロシージャは Aurora MySQL バージョン 2.12 以降の MySQL 5.7 互換バージョンでサポートされています。
## mysql.rds\$1set\$1source\$1auto\$1position (Aurora MySQL バージョン 3)
バイナリログファイルの位置、または、グローバルトランザクション識別子 (GTIDs) ベースのレプリケーションモードを設定します。
### 構文
```
CALL mysql.rds_set_source_auto_position (auto_position_mode);
```
### パラメータ
*auto\$1position\$1mode*
ファイルの位置に基づくレプリケーション、または GTID ベースのレプリケーションかどうかを示す値:
+ `0` - バイナリログファイルの位置に基づくレプリケーション方法を使用します。デフォルトは `0` です。
+ `1` - GTID ベースのレプリケーション方法を使用します。
### 使用に関する注意事項
Aurora MySQL DB クラスターでは、プライマリインスタンスに接続されている間に、このストアドプロシージャを呼び出します。
管理ユーザーは、`mysql.rds_set_source_auto_position`プロシージャを実行すべきです。
## mysql.rds\$1skip\$1repl\$1error
MySQL DB リードレプリカのレプリケーションエラーをスキップして、削除します。
### 構文
```
CALL mysql.rds_skip_repl_error;
```
### 使用に関する注意事項
マスターユーザーはリードレプリカに対して `mysql.rds_skip_repl_error` プロシージャを実行する必要があります。この手順の詳細については、「[Skipping the current replication error](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.SkipError)」(現在のレプリケーションエラーをスキップする) を参照してください。
MySQL の `SHOW REPLICA STATUS\G` コマンドを実行して、エラーがあるかどうかを判断します。レプリケーションエラーが重要ではない場合、`mysql.rds_skip_repl_error` を実行して、エラーをスキップすることができます。複数のエラーがある場合、`mysql.rds_skip_repl_error` では、初期のエラーを削除してから、他のエラーが存在することを警告します。その後で `SHOW REPLICA STATUS\G` を使用して、次のエラーに対処するための適切な対応方法を判断することができます。戻り値の詳細については、MySQL ドキュメントの「[SHOW REPLICA STATUS statement](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html)」を参照してください。
Aurora MySQL でのレプリケーションエラーの対処方法の詳細については、「[MySQL のリードレプリケーションのエラーの診断と解決](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.RR)」を参照してください。
#### レプリケーション停止エラー
`mysql.rds_skip_repl_error` プロシージャを呼び出すと、レプリカがダウンしているか無効であることを示すエラーメッセージが表示されることがあります。
このエラーメッセージは、リードレプリカではなくプライマリインスタンスでプロシージャを実行した場合に表示されます。このプロシージャを機能させるには、リードレプリカに対してこのプロシージャを実行する必要があります。
このエラーメッセージは、リードレプリカに対してプロシージャを実行したが、レプリケーションを正常に再開できない場合にも表示されることがあります。
多数のエラーをスキップする必要がある場合は、レプリケーションの遅延により、バイナリログ (binlog) ファイルがデフォルトの保持期間を超えて増大する場合があります。この場合、binlog ファイルがリードレプリカで再生される前に破棄されるため、致命的なエラーが発生することがあります。この破棄によりレプリケーションが停止し、`mysql.rds_skip_repl_error` コマンドを呼び出してレプリケーションエラーをスキップすることができなくなります。
この問題は、出典データベースインスタンスでバイナリログファイルの保持時間を増加させることで軽減できます。バイナリログ保持時間を長くすると、レプリケーションを再開し、必要に応じて `mysql.rds_skip_repl_error` コマンドを使用できるようになります。
バイナリログの保持期間を設定するには、「[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、`'binlog retention hours'` の設定パラメータを指定します。以下の例では、バイナリログファイルの保持期間を 48 時間に設定しています。
```
CALL mysql.rds_set_configuration('binlog retention hours', 48);
```
## mysql.rds\$1start\$1replication
Aurora MySQL DB クラスターからのレプリケーションを開始します。
**注記**
[mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until) または [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) ストアドプロシージャを使用して、Aurora MySQL DB インスタンスからのレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止できます。
### 構文
```
CALL mysql.rds_start_replication;
```
### 使用に関する注意事項
マスターユーザーが `mysql.rds_start_replication` を実行する必要があります。
Amazon RDS の外部の MySQL インスタンスからデータをインポートするには、[mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](#mysql_rds_set_external_master) または [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](#mysql_rds_set_external_source) を呼び出してレプリケーション設定を構築した後、リードレプリカに対して `mysql.rds_start_replication` を呼び出して、レプリケーションプロセスを開始します。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
Amazon RDS の外部の MySQL インスタンスにデータをエクスポートするには、リードレプリカに対して `mysql.rds_start_replication` と `mysql.rds_stop_replication` を呼び出して、バイナリログの消去などのレプリケーションアクションを制御します。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
リードレプリカで `mysql.rds_start_replication` を呼び出すことで、`mysql.rds_stop_replication` の呼び出しによって前に停止したレプリケーションプロセスを再開することもできます。詳細については、「[レプリケーション停止エラー](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicationStopped)」を参照してください。
## mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)
Aurora MySQL DB クラスターからレプリケーションを開始し、指定したバイナリログファイルの場所でレプリケーションを停止します。
### 構文
```
CALL mysql.rds_start_replication_until (
replication_log_file
, replication_stop_point
);
```
### パラメータ
*replication\$1log\$1file*
レプリケーション情報を含む出典データベースインスタンス上のバイナリログの名前。
*replication\$1stop\$1point *
`replication_log_file` バイナリログ内でレプリケーションが停止する場所。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_start_replication_until` を実行する必要があります。
この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。
`mysql.rds_start_replication_until` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`replication_log_file` パラメータに指定するファイル名は、出典データベースインスタンスの binlog ファイル名と一致する必要があります。
`replication_stop_point`パラメータで指定した停止場所が過去の時点である場合、レプリケーションは即座に停止します。
### 例
次の例では、レプリケーションをスタートし、`120` バイナリログファイルの場所 `mysql-bin-changelog.000777` に達するまで変更をレプリケートします。
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
## mysql.rds\$1stop\$1replication
MySQL DB インスタンスからのレプリケーションを停止します。
### 構文
```
CALL mysql.rds_stop_replication;
```
### 使用に関する注意事項
マスターユーザーが `mysql.rds_stop_replication` を実行する必要があります。
Amazon RDS の外部で動作する MySQL インスタンスからデータをインポートするようにレプリケーションを設定している場合は、リードレプリカで `mysql.rds_stop_replication` を呼び出して、インポートが完了した後でレプリケーションプロセスを停止することができます。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
Amazon RDS の外部にある MySQL インスタンスにデータをエクスポートするようにレプリケーションを設定している場合は、リードレプリカで `mysql.rds_start_replication` と `mysql.rds_stop_replication` を呼び出して、バイナリログの消去などのレプリケーションアクションを制御できます。詳細については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
`mysql.rds_stop_replication` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
# セッションやクエリの終了
次のストアドプロシージャは、セッションまたはクエリを終了します。
**Topics**
+ [mysql.rds\$1kill](#mysql_rds_kill)
+ [mysql.rds\$1kill\$1query](#mysql_rds_kill_query)
## mysql.rds\$1kill
MySQL サーバーへの接続を終了します。
### 構文
```
CALL mysql.rds_kill(processID);
```
### パラメータ
*processID*
終了する接続スレッドの識別子。
### 使用に関する注意事項
MySQL サーバーへの個々の接続は別々のスレッドで実行されます。接続を終了するには、`mysql.rds_kill` プロシージャを使用して、その接続のスレッド ID を渡します。スレッド ID を取得するには、MySQL の [PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) コマンドを使用します。
### 例
次の例では、4243 のスレッド ID を持つ接続を終了します。
```
CALL mysql.rds_kill(4243);
```
## mysql.rds\$1kill\$1query
MySQL サーバーに対して実行中のクエリを終了します。
### 構文
```
CALL mysql.rds_kill_query(processID);
```
### パラメータ
*processID*
終了するクエリを実行しているプロセスまたはスレッドの ID。
### 使用に関する注意事項
MySQL サーバーに対して実行しているクエリを終了するには、`mysql_rds_kill_query` プロシージャを使用して、クエリを実行しているスレッドの接続 ID を渡します。これにより、プロシージャは接続を終了します。
ID を取得するには、MySQL [INFORMATION\$1SCHEMA PROCESSLIST テーブル](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html)または MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html) コマンドを使用します。`SHOW PROCESSLIST` または `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` の ID 列の値は *processID* です。
### 例
次の例では、クエリスレッド ID が 230040 のクエリを停止します。
```
CALL mysql.rds_kill_query(230040);
```
# GTID を使用したトランザクションのレプリケーション
以下のストアドプロシージャは、Aurora MySQL でグローバルトランザクション識別子 (GTID) を使用してトランザクションをレプリケートする方法を制御します。Aurora MySQL を使用して、GTID に基づきレプリケーションを使用する方法については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
**Topics**
+ [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL バージョン 3)](#mysql_assign_gtids_to_anonymous_transactions)
+ [mysql.rds\$1gtid\$1purged (Aurora MySQL バージョン 3)](#mysql_rds_gtid_purged)
+ [mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)](#mysql_rds_skip_transaction_with_gtid)
+ [mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)](#mysql_rds_start_replication_until_gtid)
## mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL バージョン 3)
を設定します。`ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS`のオプション`CHANGE REPLICATION SOURCE TO`表示されます。これにより、レプリケーションチャネルが GTID を持たないレプリケートされたトランザクションに割り当てられます。このように、GTID ベースのレプリケーションを使用しないソースから、使用するレプリカに対してバイナリログレプリケーションを実行できます。詳細については、「[CHANGE REPLICATION SOURCE TO Statement」を参照してください。](https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html)そして[GTIDs のないソースから GTIDs を使用したレプリカへのレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-assign-anon.html)の*MySQL リファレンスマニュアル*を参照してください。
### 構文
```
CALL mysql.rds_assign_gtids_to_anonymous_transactions(gtid_option);
```
### パラメータ
*gtid\$1option*
文字列値。指定できる値は次のとおりです。`OFF`,`LOCAL`、または指定された UUID。
### 使用に関する注意事項
このプロシージャは、コミュニティMySQLでステートメントの発行と同じ効果があります`CHANGE REPLICATION SOURCE TO ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS = gtid_option`。
GTID を`ON`に変える必要があります*にとってgtid\$1option*または設定される`LOCAL`または特定の UUIDに設定されます。
デフォルトは `OFF` であり、この機能が使用されないことを意味します。
`LOCAL`レプリカ独自の 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\$1gtid\$1purged (Aurora MySQL バージョン 3)
システム変数 `gtid_purged` のグローバル値を特定のグローバルトランザクション識別子 (GTID) セットに設定します。`gtid_purged` システム変数は、サーバー上でコミットされたが、サーバー上のどのバイナリログファイルにも存在しないすべてのトランザクションの GTID で構成される GTID セットです。
MySQL 8.0 との互換性を保つため、`gtid_purged` の値を設定する方法が 2 つあります。
+ `gtid_purged` の値を、指定した GTID セットに置き換えます。
+ 指定した GTID セットを `gtid_purged` が既に含んでいる GTID セットに追加します。
### 構文
`gtid_purged` の値を、指定した GTID セットに置き換えるには
```
CALL mysql.rds_gtid_purged (gtid_set);
```
`gtid_purged` の値を、指定した GTID セットに追加するには
```
CALL mysql.rds_gtid_purged (+gtid_set);
```
### パラメータ
*gtid\$1set*
*gtid\$1set* の値は、`gtid_purged` の現在値のスーパーセットでなければならず、`gtid_subtract(gtid_executed,gtid_purged)` と交差することはできません。つまり、新しい GTID セットには、`gtid_purged` に既に存在していた GTID がすべて含まれている必要がありますが、まだパージされていなかった `gtid_executed` 内の GTID を含むことはできません。また、*gtid\$1set* パラメータは、グローバル `gtid_owned` セットにある GTID、サーバー上で現在処理中のトランザクションの GTID を含むことはできません。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_gtid_purged` を実行する必要があります。
この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。
### 例
次の例では、GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` を `gtid_purged` グローバル変数に代入します。
```
CALL mysql.rds_gtid_purged('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1skip\$1transaction\$1with\$1gtid (Aurora MySQL バージョン 2 および 3)
Aurora プライマリインスタンスで、指定されたグローバルトランザクション識別子 (GTID) のあるトランザクションのレプリケーションをスキップします。
特定の GTID トランザクションが問題の原因となることが知られている場合、障害復旧のためにこのプロシージャを使用できます。このストアドプロシージャを使用して、問題となるトランザクションをスキップします。問題のあるトランザクションの例には、レプリケーションを無効にしたり、重要なデータを削除したり、DB インスタンスを利用不可にするトランザクションが含まれます。
### 構文
```
CALL mysql.rds_skip_transaction_with_gtid (
gtid_to_skip
);
```
### パラメータ
*gtid\$1to\$1skip*
スキップするレプリケーショントランザクションの GTID。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_skip_transaction_with_gtid` を実行する必要があります。
この手順は Aurora MySQL バージョン 2 および 3 でサポートされています。
### 例
次の例では、GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` を使用したトランザクションのレプリケーションをスキップします。
```
CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
## mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)
Aurora MySQL DB クラスターからのレプリケーションを開始し、指定したグローバルトランザクション識別子 (GTID) の後でレプリケーションを停止します。
### 構文
```
CALL mysql.rds_start_replication_until_gtid(gtid);
```
### パラメータ
*gtid*
レプリケーションがその後で停止する GTID。
### 使用に関する注意事項
マスターユーザーが `mysql.rds_start_replication_until_gtid` を実行する必要があります。
この手順は Aurora MySQL バージョン 3.04 以降でサポートされています。
`mysql.rds_start_replication_until_gtid` ストアドプロシージャは、以下を含むマネージドレプリケーションではサポートされていません。
+ [AWS リージョン 間での Amazon Aurora MySQL DB クラスターのレプリケーション](AuroraMySQL.Replication.CrossRegion.md)
+ [Aurora リードレプリカを使用した、RDS for MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.RDSMySQL.Replica.md)
`gtid`パラメータで指定したトランザクションがレプリカによって既に実行されている場合、レプリケーションは即座に停止します。
### 例
次の例では、レプリケーションをスタートし、GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23` に達するまで変更をレプリケートします。
```
call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23');
```
# クエリログのローテーション
以下のストアドプロシージャは、MySQL ログをバックアップテーブルにローテーションします。詳細については、「[Aurora MySQL データベースのログファイル](USER_LogAccess.Concepts.MySQL.md)」を参照してください。
**Topics**
+ [mysql.rds\$1rotate\$1general\$1log](#mysql_rds_rotate_general_log)
+ [mysql.rds\$1rotate\$1slow\$1log](#mysql_rds_rotate_slow_log)
## mysql.rds\$1rotate\$1general\$1log
`mysql.general_log` テーブルをバックアップテーブルとしてローテーションさせます。
### 構文
```
CALL mysql.rds_rotate_general_log;
```
### 使用に関する注意事項
`mysql.general_log` テーブルのバックアップテーブルとしてのローテーションは、`mysql.rds_rotate_general_log` プロシージャを呼び出すことで実行できます。ログテーブルのローテーションが実行されると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルがすでに存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。バックアップのログテーブルは、必要に応じて照会することができます。`mysql.general_log` テーブルに対するバックアップのログテーブルは、`mysql.general_log_backup` という名前になります。
`log_output` パラメータが `TABLE` に設定されている場合にのみ、このプロシージャを実行できます。
## mysql.rds\$1rotate\$1slow\$1log
`mysql.slow_log` テーブルをバックアップテーブルとしてローテーションさせます。
### 構文
```
CALL mysql.rds_rotate_slow_log;
```
### 使用に関する注意事項
`mysql.slow_log` テーブルのバックアップテーブルとしてのローテーションは、`mysql.rds_rotate_slow_log` プロシージャを呼び出すことで実行できます。ログテーブルのローテーションが実行されると、現在のログテーブルがバックアップのログテーブルにコピーされ、現在のログテーブル内にあるエントリは削除されます。バックアップのログテーブルがすでに存在する場合は、現在のログテーブルをバックアップにコピーする前に、削除されます。
バックアップのログテーブルは、必要に応じて照会することができます。`mysql.slow_log` テーブルに対するバックアップのログテーブルは、`mysql.slow_log_backup` という名前になります。
# バイナリログ構成の設定と表示
次のストアドプロシージャは、バイナリログファイルの保存などの設定パラメータを設定および表示します。
**Topics**
+ [mysql.rds\$1set\$1configuration](#mysql_rds_set_configuration)
+ [mysql.rds\$1show\$1configuration](#mysql_rds_show_configuration)
## mysql.rds\$1set\$1configuration
バイナリログを保持する時間数またはレプリケーションを遅延させる秒数を指定します。
### 構文
```
CALL mysql.rds_set_configuration(name,value);
```
### パラメータ
*.name*
設定する設定パラメータの名前。
*値*
設定パラメータの値。
### 使用に関する注意事項
`mysql.rds_set_configuration` プロシージャは、以下の設定パラメータをサポートしています。
+ [バイナリログの保持時間](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours)
設定パラメータは永続的に保存され、DB インスタンスの再起動やフェイルオーバー後も存続します。
#### バイナリログの保持時間
`binlog retention hours` パラメータは、バイナリログファイルを保持する時間数を指定するために使用されます。Amazon Aurora では、通常、バイナリログは可能な限りすみやかに消去されますが、Aurora の外部にある MySQL データベースでのレプリケーションのためにバイナリログが必要になる場合があります。
`binlog retention hours` の初期値は `NULL` です。Aurora MySQL の場合、`NULL` はバイナリログが遅延してクリーンアップされることを意味します。Aurora MySQL バイナリログは、一定期間 (通常は 1 日以内)、システムに残ることがあります。
DB クラスターのバイナリログを保持する時間数を指定するには、`mysql.rds_set_configuration` ストアドプロシージャを使用して、次の例のように、レプリケーションを実行するのに十分な期間を指定します。
`call mysql.rds_set_configuration('binlog retention hours', 24);`
**注記**
`binlog retention hours` には、値 `0` は使用できません。
Aurora MySQL バージョン 2.11.0 以降、およびバージョン 3 DB クラスターの場合、最大 `binlog retention hours` 値は 2160 (90 日) です。
保持期間を設定したら、DB インスタンスのストレージ使用状況をモニタリングして、保持されたバイナリログに必要以上の容量が使用されないようにします。
## mysql.rds\$1show\$1configuration
バイナリログを保持する時間数。
### 構文
```
CALL mysql.rds_show_configuration;
```
### 使用に関する注意事項
Amazon RDS がバイナリログを保持する時間数を確認するには、`mysql.rds_show_configuration` ストアドプロシージャを使用します。
### 例
以下の例では、保持期間を表示しています。
```
call mysql.rds_show_configuration;
name value description
binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted.
```
# Aurora MySQL — 固有の information\$1schema テーブル
Aurora MySQL には、Aurora に固有の特定の `information_schema` テーブルがあります。
## information\$1schema.aurora\$1global\$1db\$1instance\$1status
`information_schema.aurora_global_db_instance_status` テーブルには、グローバルデータベースのプライマリ DB クラスターとセカンダリ DB クラスター内のすべての DB インスタンスのステータスに関する情報が含まれています。使用できる列を次の表に示します。残りの列は Aurora 内部でのみ使用されます。
**注記**
この情報スキーマテーブルは、Aurora MySQL バージョン 3.04.0 以降のグローバルデータベースでのみ使用できます。
| 列 | データ型 | 説明 |
| --- | --- | --- |
| SERVER\$1ID | varchar(100) | DB インスタンスの ID。 |
| SESSION\$1ID | varchar(100) | 現在のセッションの一意識別子。MASTER\$1SESSION\$1ID の値は、Writer (プライマリ) DB インスタンスを識別します。 |
| AWS\$1REGION | varchar(100) | このグローバルデータベースインスタンスが実行する AWS リージョン。リージョンのリストについては、「[リージョンの可用性](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)」を参照してください。 |
| DURABLE\$1LSN | bigint unsigned | ストレージで耐久性のあるログシーケンス番号 (LSN)。ログシーケンス番号 (LSN) は、データベーストランザクションログ内のレコードを識別する一意の連続番号です。LSN は、より大きな LSN が後のトランザクションを表すように順序付けられます。 |
| HIGHEST\$1LSN\$1RCVD | bigint unsigned | ライター DB インスタンスから DB インスタンスが受信した最も高い LSN。 |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | ライター DB インスタンスがパージできる最も古いトランザクションの ID。 |
| OLDEST\$1READ\$1VIEW\$1LSN | bigint unsigned | ストレージから読み取るために DB インスタンスが使用した最も古い LSN。 |
| VISIBILITY\$1LAG\$1IN\$1MSEC | float(10,0) unsigned | プライマリ DB クラスターのリーダーの場合、この DB インスタンスがライター DB インスタンスよりどれだけ遅れているか (ミリ秒単位)。セカンダリ DB クラスターのリーダーの場合、この DB インスタンスがセカンダリボリュームからどれだけ遅れているかをミリ秒単位で示します。 |
## information\$1schema.aurora\$1global\$1db\$1status
`information_schema.aurora_global_db_status` テーブルには、Aurora グローバルデータベースの遅延のさまざまな側面に関する情報が含まれています。具体的には、基盤となる Aurora ストレージの遅延 (いわゆる耐久性の遅延) と目標復旧時点 (RPO) 間の遅延などです。使用できる列を次の表に示します。残りの列は Aurora 内部でのみ使用されます。
**注記**
この情報スキーマテーブルは、Aurora MySQL バージョン 3.04.0 以降のグローバルデータベースでのみ使用できます。
| 列 | データ型 | 説明 |
| --- | --- | --- |
| AWS\$1REGION | varchar(100) | このグローバルデータベースインスタンスが実行する AWS リージョン。リージョンのリストについては、「[リージョンの可用性](Concepts.RegionsAndAvailabilityZones.md#Aurora.Overview.Availability)」を参照してください。 |
| HIGHEST\$1LSN\$1WRITTEN | bigint unsigned | この DB クラスターに現在存在するログシーケンス番号 (LSN) の最大値。ログシーケンス番号 (LSN) は、データベーストランザクションログ内のレコードを識別する一意の連続番号です。LSN は、より大きな LSN が後のトランザクションを表すように順序付けられます。 |
| DURABILITY\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | セカンダリ DB クラスターの HIGHEST\$1LSN\$1WRITTEN とプライマリ DB クラスターの HIGHEST\$1LSN\$1WRITTEN とのタイムスタンプ値の差。この値は、Aurora グローバルデータベースのプライマリ DB クラスターでは常に 0 です。 |
| RPO\$1LAG\$1IN\$1MILLISECONDS | float(10,0) unsigned | 目標復旧時点 (RPO) の遅延。RPO 遅延とは、最近のユーザートランザクション COMMIT が、Aurora グローバルデータベースのプライマリ DB クラスターに保存された後、セカンダリ DB クラスターに保存されるまでにかかる時間です。この値は、Aurora グローバルデータベースのプライマリ DB クラスターでは常に 0 です。 簡単に言うと、このメトリクスは、Aurora グローバルデータベース内の各 Aurora MySQL DB クラスターの目標復旧時点、つまり、障害が発生した場合に失われる可能性のあるデータの量を計算します。遅延と同様に、RPO は時間単位で測定されます。 |
| LAST\$1LAG\$1CALCULATION\$1TIMESTAMP | datetime | DURABILITY\$1LAG\$1IN\$1MILLISECONDS と RPO\$1LAG\$1IN\$1MILLISECONDS について値が最後に計算された時刻を指定するタイムスタンプ。1970-01-01 00:00:00\$100 のような時間値は、これがプライマリ DB クラスターであることを意味します。 |
| OLDEST\$1READ\$1VIEW\$1TRX\$1ID | bigint unsigned | ライター DB インスタンスがパージできる最も古いトランザクションの ID。 |
## information\$1schema.replica\$1host\$1status
`information_schema.replica_host_status` テーブルにはレプリケーション情報が含まれています。使用できる列を以下のテーブルに示します。残りの列は Aurora 内部でのみ使用されます。
| 列 | データ型 | 説明 |
| --- | --- | --- |
| CPU | double | レプリカホストの CPU 使用率。 |
| IS\$1CURRENT | tinyint | レプリカが最新かどうか。 |
| LAST\$1UPDATE\$1TIMESTAMP | datetime(6) | 前回の更新が行われた時刻。レコードが古くなっているかどうかを判断するために使用されます。 |
| REPLICA\$1LAG\$1IN\$1MILLISECONDS | double | ミリ秒単位でのレプリカ遅延。 |
| SERVER\$1ID | varchar(100) | データベースサーバーの ID。 |
| SESSION\$1ID | varchar(100) | データベースセッションの ID。DB インスタンスがライターインスタンスかリーダーインスタンスかを判断するために使用されます。 |
**注記**
レプリカインスタンスが遅延すると、その `information_schema.replica_host_status` テーブルからクエリされる情報が古くなることがあります。このような状況では、代わりにライターインスタンスからクエリを実行することをお勧めします。
`mysql.ro_replica_status` テーブルにも同様の情報がありますが、使用することは推奨されません。
## information\$1schema.aurora\$1forwarding\$1processlist
`information_schema.aurora_forwarding_processlist` テーブルには、書き込み転送に関係するプロセスについての情報が含まれています。
このテーブルの内容は、グローバルまたはクラスター内書き込み転送がオンになっている DB クラスターのライター DB インスタンスでのみ表示されます。リーダー DB インスタンスでは、空の結果セットが返されます。
| フィールド | データ型 | 説明 |
| --- | --- | --- |
| ID | bigint | ライター DB インスタンス上の接続の識別子。この識別子は、SHOW PROCESSLIST ステートメントの Id 列に表示され、スレッド内の CONNECTION\$1ID() 関数によって返される値と同じです。 |
| USER | varCHAR(32) | ステートメントを発行した MySQL ユーザー。 |
| HOST | varCHAR(255) | ステートメントを発行した MySQL クライアント。転送されたステートメントの場合、このフィールドには、転送側リーダー DB インスタンスで接続を確立したアプリケーションクライアントのホストアドレスが表示されます。 |
| DB | varCHAR(64) | スレッドのデフォルトデータベース。 |
| コマンド | varCHAR(16) | スレッドがクライアントに代わって実行しているコマンドのタイプ、またはセッションがアイドル状態の場合は Sleep。スレッドコマンドの説明については、MySQL ドキュメントの「[スレッドコマンド値](https://dev.mysql.com/doc/refman/8.0/en/thread-commands.html)」を参照してください。 |
| TIME | 整数 | スレッドが現在の状態になっていた時間 (秒単位)。 |
| STATE | varCHAR(64) | スレッドが何をしているのかを示すアクション、イベント、または状態。状態値の説明については、MySQL ドキュメントの「[一般的なスレッドの状態](https://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html)」を参照してください。 |
| INFO | longtext | スレッドが実行しているステートメント、またはステートメントを実行していない場合は NULL。ステートメントは、サーバーに送信されるステートメントかもしれず、ステートメントが他のステートメントを実行する場合は最も内側のステートメントかもしれません。 |
| IS\$1FORWARDED | bigint | スレッドがリーダー DB インスタンスから転送されるかどうかを示します。 |
| REPLICA\$1SESSION\$1ID | bigint | Aurora レプリカの接続識別子。この識別子は、転送側の Aurora リーダー DB インスタンスで SHOW PROCESSLIST ステートメントの Id 列に表示されるのと同じ値です。 |
| REPLICA\$1INSTANCE\$1IDENTIFIER | varCHAR(64) | 転送側スレッドの DB インスタンス識別子。 |
| REPLICA\$1CLUSTER\$1NAME | varCHAR(64) | 転送側スレッドの DB クラスター識別子。クラスター内書き込み転送の場合、この識別子は、ライター DB インスタンスと同じ DB クラスターです。 |
| REPLICA\$1REGION | varCHAR(64) | 転送側スレッドの送信元の AWS リージョン。クラスター内書き込み転送の場合、このリージョンは、ライター DB インスタンスと同じ AWS リージョン です。 |