engine=innodb, algorithm=copy;
```
以下のセクションでは、レプリケーションの設定、レプリケーションの停止、データベースの読み取りのスケール、バイナリログレプリケーションの最適化、拡張バイナリログの設定を行います。
**Topics**
+ [Aurora MySQL のバイナリログレプリケーションの設定](AuroraMySQL.Replication.MySQL.SettingUp.md)
+ [Aurora MySQL のバイナリログレプリケーションの停止](AuroraMySQL.Replication.MySQL.Stopping.md)
+ [Amazon Aurora を使用した MySQL データベースの読み取りスケーリング](AuroraMySQL.Replication.ReadScaling.md)
+ [Aurora MySQL でのバイナリログのレプリケーションの最適化](binlog-optimization.md)
+ [Aurora MySQL の拡張バイナリログの設定](AuroraMySQL.Enhanced.binlog.md)
# Aurora MySQL のバイナリログレプリケーションの設定
Aurora MySQL と MySQL との間でレプリケーションを設定するには、次のステップを使用します。各ステップについては、このトピックで詳しく説明します。
**Contents**
+ [1. レプリケーション出典のバイナリログ記録を有効にする](#AuroraMySQL.Replication.MySQL.EnableBinlog)
+ [2. レプリケーション出典のバイナリログを不要になるまで保持する](#AuroraMySQL.Replication.MySQL.RetainBinlogs)
+ [3. レプリケーションソースのコピーまたはダンプを作成する](#AuroraMySQL.Replication.MySQL.CreateSnapshot)
+ [4. レプリカターゲットにダンプをロードする (必要な場合)](#AuroraMySQL.Replication.MySQL.LoadSnapshot)
+ [5. レプリケーションソースでレプリケーションユーザーを作成する](#AuroraMySQL.Replication.MySQL.CreateReplUser)
+ [6. レプリカターゲットでレプリケーションを有効にする](#AuroraMySQL.Replication.MySQL.EnableReplication)
+ [リードレプリカへのレプリケーションを停止する場所の設定](#AuroraMySQL.Replication.StartReplicationUntil)
+ [7. レプリカをモニタリングする](#AuroraMySQL.Replication.MySQL.Monitor)
+ [レプリケーション出典とレプリケーションターゲット間でのパスワードの同期](#AuroraMySQL.Replication.passwords)
## 1. レプリケーション出典のバイナリログ記録を有効にする
以下のデータベースエンジンのレプリケーション出典で、バイナリログを有効にする手順を確認します。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターのバイナリログ記録を有効にするには** `binlog_format` DB クラスターパラメータを `ROW`、`STATEMENT`、または `MIXED` に設定します。特定のバイナリログ形式の必要性がない限り、`MIXED` をお勧めします。(デフォルト値は`OFF`です。) `binlog_format` パラメータを変更するには、カスタム DB クラスターパラメータグループを作成し、そのカスタムパラメータグループを DB クラスターに関連付けます。デフォルト DB クラスターパラメータグループのパラメータは変更できません。 `binlog_format` パラメータを `OFF` から別の値に変更した場合、変更を有効にするには、Aurora DB クラスターを再起動する必要があります。 詳細については、「[Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups)」および「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。 |
| RDS for MySQL | **Amazon RDS DB インスタンスのバイナリログ記録を有効にするには** Amazon RDS DB インスタンスでは、バイナリログ記録を直接有効にすることはできませんが、以下のいずれかの操作により有効にすることができます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **暗号化レプリケーションを設定するには** Aurora MySQL バージョン 2 を使用してデータを安全に複製するには、暗号化されたレプリケーションを使用できます。 暗号化レプリケーションを使う必要がない場合、このステップをスキップできます。 暗号化レプリケーションを使用するための前提条件は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) 暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **外部 MySQL データベースのバイナリログ記録を有効にするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 2. レプリケーション出典のバイナリログを不要になるまで保持する
MySQL バイナリログのレプリケーションを使用する場合、Amazon RDS はレプリケーションプロセスを管理しません。したがって、レプリケーション出典のバイナリログファイルは、変更がレプリカに適用されるまで保持する必要があります。このメンテナンスによって、障害発生時にソースデータベースを復元しやすくなります。
次のステップに従って、データベースエンジンのバイナリログを保持します。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターのバイナリログを保持するには** Aurora MySQL DB クラスターのバイナリログファイルにはアクセスできません。そのため、確実に変更がレプリカに適用されてから、レプリケーション出典のバイナリログファイルが Amazon RDS によって削除されるように、バイナリログファイルの保持期間は十分に長く設定する必要があります。Aurora MySQL DB クラスターのバイナリログファイルは最大 90 日間、保持できます。 MySQL データベースまたは RDS for MySQL DB インスタンスをレプリカとしてレプリケーションを設定する場合、レプリカを作成するデータベースが巨大なときには、レプリカへのデータベースの初期のコピーが完了し、レプリカラグが 0 に達するまで、バイナリログファイルが保持されるように、保持期間を長く設定してください。 バイナリログの保持期間を設定するには、「[mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)」の手順を使用して、DB クラスターのバイナリログファイルの保持時間数に合わせて、`'binlog retention hours'` の設定パラメータを指定します。Aurora MySQL バージョン 2 以降、およびバージョン 3 の最大値は 2160 (90 日) です。 以下の例では、バイナリログファイルの保持期間を 6 日に設定しています。 CALL mysql.rds_set_configuration('binlog retention hours', 144); レプリケーションが開始された後、レプリカに対して `SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを実行し、`Seconds behind master` フィールドを調べることで、変更がレプリカに適用されたことを確認できます。`Seconds behind master` フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、`binlog retention hours` 設定パラメータをより短い期間に設定することで、バイナリログファイルの保持期間を短くします。 この設定を指定しない場合、Aurora MySQL のデフォルト値は 24 (1 日) です。 `'binlog retention hours'` に最大値より大きい値を指定すると、Aurora MySQL は最大値を使用します。 |
| RDS for MySQL | **Amazon RDS DB インスタンスのバイナリログを保持するには** 前の行で説明したように、Amazon RDS DB インスタンスのバイナリログファイルを保持するには、保持期間を Aurora MySQL DB クラスターと同様に設定します。 DB インスタンスのリードレプリカを作成しても、Amazon RDS DB インスタンスのバイナリログファイルを保持できます。このリードレプリカはバイナリログファイルの保持専用に一時的に作成されます。リードレプリカが作成されたら、リードレプリカに対して [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) プロシージャを呼び出します。レプリケーションの停止中に Amazon RDS がレプリケーション出典のバイナリログファイルを削除することはありません。永続レプリカとのレプリケーションを設定した後、レプリケーション出典と永続レプリカ間のレプリカラグ (`Seconds behind master` フィールド) が 0 に達したときに、リードレプリカを削除できます。 |
| MySQL (外部) | **外部 MySQL データベースのバイナリログを有効にするには** 外部 MySQL データベースのバイナリログファイルは Amazon RDS によって管理されていないため、手動で削除されるまでは保持されます。 レプリケーションが開始された後、レプリカに対して `SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを実行し、`Seconds behind master` フィールドを調べることで、変更がレプリカに適用されたことを確認できます。`Seconds behind master` フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、古いバイナリログファイルを削除できます。 |
## 3. レプリケーションソースのコピーまたはダンプを作成する
レプリケーションソースのスナップショット、クローン、またはダンプを使用して、データのベースラインコピーをレプリカにロードします。次に、その時点からレプリケーションを開始します。
次の指示に従って、データベースエンジンのレプリケーションソースのコピーまたはダンプを作成します。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターのコピーを作成するには** 次のいずれかの方法を使用します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **バイナリログファイルの名前と位置を確認するには** 次のいずれかの方法を使用します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Aurora MySQL DB クラスターのダンプを作成するには** レプリカターゲットが外部 MySQL データベースまたは RDS for MySQL DB インスタンスの場合、Aurora DB クラスターからダンプファイルを作成する必要があります。 作成したソース DB クラスターのコピーに対して、必ず `mysqldump` コマンドを実行してください。これは、ダンプを取る際のロックに関する考慮事項を避けるためです。ダンプがソース DB クラスターで直接作成された場合は、ダンプの進行中にソーステーブルへの同時書き込みを防ぐために、ソーステーブルをロックする必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Amazon RDS DB インスタンスのスナップショットを作成するには** Amazon RDS DB インスタンスのリードレプリカを作成します。詳細については、*Amazon Relational Database Service ユーザーガイド*の「[リードレプリカの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)」を参照してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **外部 MySQL データベースのダンプを作成するには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 4. レプリカターゲットにダンプをロードする (必要な場合)
Amazon RDS の外部 MySQL データベースのダンプからデータをロードする場合、ダンプファイルのコピー先となる EC2 インスタンスを作成しなければならない場合があります。その後、その EC2 インスタンスから DB クラスターまたは DB インスタンスにデータをロードできます。この方法では、ダンプファイルを EC2 インスタンスにコピーする前に圧縮して、Amazon RDS へのデータのコピーに関連するネットワークコストを削減できます。また、ダンプファイルを暗号化して、ネットワーク経由で転送されるデータを保護することもできます。
**注記**
レプリカターゲットとして新しい Aurora MySQL DB クラスターを作成する場合、ダンプファイルをロードする必要はありません。
DB クラスタースナップショットから復元することで新しい DB クラスターを作成できます。詳細については、「[DB クラスタースナップショットからの復元](aurora-restore-snapshot.md)」を参照してください。
ソース DB クラスターのクローンを作成して、新しい DB クラスターを作成できます。詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。
DB インスタンススナップショットから新しい DB クラスターにデータを移行できます。詳細については、「[Amazon Aurora MySQL DB クラスターへのデータの移行](AuroraMySQL.Migrating.md)」を参照してください。
次のステップに従って、レプリケーションソースのダンプをデータベースエンジンのレプリカターゲットにロードします。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターにダンプをロードするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| RDS for MySQL | **Amazon RDS DB インスタンスにダンプをロードするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
| MySQL (外部) | **外部 MySQL データベースにダンプをロードするには** 外部 MySQL データベースに DB スナップショットまたは DB クラスターのスナップショットをロードすることはできません。代わりに、`mysqldump` コマンドの出力を使用する必要があります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
## 5. レプリケーションソースでレプリケーションユーザーを作成する
レプリケーション専用のユーザー ID をソースに作成します。次の例は、RDS for MySQL または外部の MySQL ソースデータベース用です。
```
mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';
```
Aurora MySQL ソースデータベースの場合、`skip_name_resolve`DB クラスターパラメータは `1` (`ON`) に設定され、変更できないため、ドメイン名の代わりにホストの IP アドレスを使用する必要があります。詳細については、MySQL ドキュメントの「[skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve)」を参照してください。
```
mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';
```
ユーザーには `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限が必要です。ユーザーのこれらの権限を付与します。
暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。例えば、以下のいずれかのステートメントを使用して、ユーザーアカウント `repl_user` に SSL 接続を要求できます。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
```
```
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
```
**注記**
`REQUIRE SSL` が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。
## 6. レプリカターゲットでレプリケーションを有効にする
レプリケーションを有効化する前に、MySQL DB インスタンスレプリカターゲットの Aurora MySQL DB クラスターまたは RDS のスナップショットを手動で作成することをお勧めします。問題が発生し、DB クラスターまたは DB インスタンスレプリカターゲットとのレプリケーションを再開する必要がある場合は、このスナップショットから DB クラスターまたは DB インスタンスを復元できます。そのために、再びレプリカターゲットにデータをインポートする必要はありません。
次のステップに従って、データベースエンジンでレプリケーションを有効にします。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターからのレプリケーションを有効にするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) SSL 暗号化を使用するには、最終値を `0` ではなく `1` に設定します。 |
| RDS for MySQL | **Amazon RDS DB インスタンスからのレプリケーションを有効にするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) SSL 暗号化を使用するには、最終値を `0` ではなく `1` に設定します。 |
| MySQL (外部) | **外部 MySQL データベースからのレプリケーションを有効にするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) |
レプリケーションが失敗した場合、レプリカにおいて意図しない I/O が大幅に増加することで、パフォーマンスが低下する可能性があります。レプリケーションが失敗するか、不要になった場合は、[mysql.rds\$1reset\$1external\$1master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) または [mysql.rds\$1reset\$1external\$1source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) ストアドプロシージャを実行して、レプリケーション設定を削除できます。
### リードレプリカへのレプリケーションを停止する場所の設定
Aurora MySQL バージョン 3.04 以降では、[mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを使用してレプリケーションを開始してバイナリログファイルの指定した位置で停止できます。
**リードレプリカへのレプリケーションをスタートして指定の位置でレプリケーションを停止するには**
1. MySQL クライアントを使用して、マスターユーザーとしてレプリカ Aurora MySQL DB クラスターに接続します。
1. [mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを実行します。
次の例では、レプリケーションをスタートし、`120` バイナリログファイルの場所 `mysql-bin-changelog.000777` に達するまで変更をレプリケートします。災害対策シナリオでは、場所 `120` は災害発生直前の時点として想定されます。
```
call mysql.rds_start_replication_until(
'mysql-bin-changelog.000777',
120);
```
停止ポイントに達すると、レプリケーションは自動的に停止します。RDS イベントとして、`Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure` が生成されます。
GTID ベースのレプリケーションを使用する場合は、[mysql.rds\$1start\$1replication\$1until\$1gtid(Aurora MySQL バージョン 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) ストアドプロシージャの代わりに、[mysql.rds\$1start\$1replication\$1until(Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを実行します。GTID ベースのレプリケーションの詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
## 7. レプリカをモニタリングする
Aurora MySQL DB クラスターと MySQL との間のレプリケーションを設定する場合、Aurora MySQL DB クラスターがレプリカターゲットであれば、そのクラスターのフェイルオーバーイベントをモニタリングする必要があります。フェイルオーバーが発生すると、レプリカターゲットである DB クラスターが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
また、レプリカターゲットがどれほどレプリケーションソースに遅れをとっているかをモニタリングするには、レプリカターゲットに接続して、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを実行します。このコマンドの出力の `Seconds Behind Master` フィールドに、マスターからレプリカターゲットへのコピーの進行状況が示されます。
**重要**
DB クラスターをアップグレードし、カスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動してください。これにより、クラスターは新しいカスタムパラメータ設定を使用し、バイナリログレプリケーションを再開します。
## レプリケーション出典とレプリケーションターゲット間でのパスワードの同期
SQL ステートメントを使用してレプリケーション出典のユーザーアカウントとパスワードを変更すると、それらの変更はレプリケーションターゲットに自動的にレプリケートされます。
AWS マネジメントコンソール、AWS CLI、または RDS API を使用してレプリケーション出典のマスターパスワードを変更した場合、それらの変更はレプリケーションターゲットに自動的にレプリケートされません。出典システムとターゲットシステム間でマスターユーザーとマスターパスワードを同期する場合は、レプリケーションターゲットに対して同様の変更を自分で行う必要があります。
# Aurora MySQL のバイナリログレプリケーションの停止
MySQL DB インスタンス、外部 MySQL データベース、または別の Aurora DB クラスターでのバイナリログのレプリケーションを停止するには、このトピックの後で詳しく説明するステップに従ってください。
[1. レプリカターゲットでバイナリログのレプリケーションを停止する](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication)
[2. レプリケーション出典のバイナリログ記録を無効にする](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging)
## 1. レプリカターゲットでバイナリログのレプリケーションを停止する
データベースエンジンのバイナリログレプリケーションを停止するには、以下の説明を参照してください。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Aurora MySQL DB クラスターレプリカターゲットでのバイナリログのレプリケーションを停止するには** レプリカターゲットである Aurora DB クラスターに接続し、[mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) プロシージャを呼び出します。 |
| RDS for MySQL | **Amazon RDS DB インスタンスのバイナリログのレプリケーションを停止するには** レプリカターゲットである RDS DB インスタンスに接続し、[mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) プロシージャを呼び出します。 |
| MySQL (外部) | **外部 MySQL データベースのバイナリログのレプリケーションを停止するには** MySQL データベースに接続し、`STOP SLAVE` (バージョン 5.7) または`STOP REPLICA` (バージョン 8.0) コマンドを実行します。 |
## 2. レプリケーション出典のバイナリログ記録を無効にする
次の表の説明に従って、データベースエンジンのレプリケーションソースで、バイナリログを無効にします。
| データベースエンジン | 手順 |
| --- | --- |
| Aurora MySQL | **Amazon Aurora DB クラスターのバイナリログ記録を無効にするには** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| RDS for MySQL | **Amazon RDS DB インスタンスのバイナリログ記録を無効にするには** Amazon RDS DB インスタンスでは、バイナリログ記録を直接無効にすることはできませんが、以下のいずれかの操作により有効にすることができます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
| MySQL (外部) | **外部 MySQL データベースのバイナリログ記録を無効にするには** MySQL データベースに接続して、`STOP REPLICATION` コマンドを呼び出します。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) |
# Amazon Aurora を使用した MySQL データベースの読み取りスケーリング
MySQL DB インスタンスで Amazon Aurora を使用することで、Amazon Aurora の読み取りスケーリング機能を活用して MySQL DB インスタンスの読み取りワークロードを拡張できます。Aurora を使用して MySQL DB インスタンスの読み取りを拡張するには、Amazon Aurora MySQL DB クラスターを作成し、MySQL DB インスタンスのリードレプリカに指定します。これは、RDS for MySQL DB インスタンス、または Amazon RDS の外部で実行されている MySQL データベースに適用されます。
Amazon Aurora DB クラスターの作成については、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。
MySQL DB インスタンスと Amazon Aurora DB クラスターの間でレプリケーションを設定するときは、以下のガイドラインに従ってください。
+ Amazon Aurora DB クラスターを参照するときは、Amazon Aurora MySQL DB クラスターのエンドポイントアドレスを使用します。フェイルオーバーが発生すると、Aurora MySQL DB クラスターのプライマリインスタンスに昇格された Aurora レプリカで、引き続きこの DB クラスターのエンドポイントアドレスが使用されます。
+ ライターインスタンスのバイナリログが Aurora レプリカに適用されたことを確認するまで、これらのバイナリログを保持します。このメンテナンスによって、障害発生時にライターインスタンスを復元できます。
**重要**
自己管理型レプリケーションを使用する場合、ユーザー自身で発生する可能性のあるすべてのレプリケーションの問題をモニタリングし、解決する必要があります。詳細については、「[リードレプリカ間の遅延の診断と解決](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag)」を参照してください。
**注記**
Amazon Aurora MySQL DB クラスターでレプリケーションを開始するために必要なアクセス許可は制限されており、Amazon RDS マスターユーザーは使用できません。このため、Aurora MySQL DB クラスターと MySQL DB インスタンスの間でレプリケーションを設定するには、[mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) または [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) と [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) プロシージャを使用する必要があります。
## 外部のソースインスタンスと Aurora MySQL DB クラスターの間でレプリケーションを開始する
1. 出典 MySQL DB インスタンスを読み取り専用にします。
```
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
```
1. 出典 MySQL DB インスタンスで `SHOW MASTER STATUS` コマンドを実行して、binlog の場所を特定します。以下の例のような出力を受け取ります。
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
1. `mysqldump` を使用して、外部の MySQL DB インスタンスから Amazon Aurora MySQL DB クラスターにデータベースをコピーします。大規模なデータベースの場合、「*Amazon Relational Database Service ユーザーガイド*」の「[ダウンタイムを短縮して Amazon RDS for MySQL データベースにデータをインポートする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html)」の手順を使用することが必要になる場合があります。
Linux、macOS、Unix の場合:
```
mysqldump \
--databases \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-p local_password | mysql \
--host aurora_cluster_endpoint_address \
--port 3306 \
-u RDS_user_name \
-p RDS_password
```
Windows の場合:
```
mysqldump ^
--databases ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-p local_password | mysql ^
--host aurora_cluster_endpoint_address ^
--port 3306 ^
-u RDS_user_name ^
-p RDS_password
```
**注記**
`-p` オプションと入力するパスワードの間にスペースがないことを確認します。
`--host` コマンドで、`--user (-u)`、`--port`、`-p`、`mysql` オプションを使用して、Aurora DB クラスターに接続するためのホスト名、ユーザー名、ポート、パスワードを指定します。このホスト名は、Amazon Aurora DB クラスターのエンドポイントの DNS 名 (例えば `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`) です。エンドポイントの値は、Amazon RDS マネジメントコンソールでクラスターの詳細を確認できます。
1. もう一度出典 MySQL DB インスタンスを書き込み可能にします。
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
レプリケーションで使用するバックアップの作成の詳細については、MySQL ドキュメントの [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) を参照してください。
1. Amazon RDS マネジメントコンソールで、出典 MySQL データベースをホストするサーバーの IP アドレスを、Amazon Aurora DB クラスターの VPC セキュリティグループに追加します。VPC セキュリティグループの変更方法の詳細については、**「Amazon Virtual Private Cloud ユーザーガイド」の「[VPC のセキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
出典 MySQL インスタンスと通信できるようにするために、Amazon Aurora DB クラスターの IP アドレスからの接続を許可するようにローカルネットワークを設定することも必要になる場合があります。Amazon Aurora DB クラスターの IP アドレスを確認するには、`host` コマンドを使用します。
```
host aurora_endpoint_address
```
このホスト名は、Amazon Aurora DB クラスターのエンドポイントからの DNS 名です。
1. 選択したクライアントを使用して、外部の MySQL インスタンスに接続し、レプリケーションに使用される MySQL ユーザーを作成します。このアカウントはレプリケーション専用に使用され、セキュリティを強化するためにドメインに制限する必要があります。次に例を示します。
```
CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password';
```
1. 外部の MySQL インスタンスについて、`REPLICATION CLIENT` と `REPLICATION SLAVE` の特権をレプリケーションユーザーに付与します。例えば、すべてのデータベースに対する `REPLICATION CLIENT` および `REPLICATION SLAVE` 権限を "`repl_user`" ユーザーに付与するには、以下のコマンドを実行します。
```
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'
IDENTIFIED BY 'password';
```
1. レプリケーションを設定する前に、Aurora MySQL DB クラスターの手動スナップショットをリードレプリカに指定します。DB クラスターをリードレプリカとしてレプリケーションを再構築する必要がある場合は、このスナップショットから Aurora MySQL DB クラスターを復元でき、MySQL DB インスタンスから新しい Aurora MySQL DB クラスターにデータをインポートする必要はありません。
1. Amazon Aurora DB クラスターをレプリカとして指定します。Amazon Aurora DB クラスターにマスターユーザーとして接続し、[mysql.rds\$1set\$1external\$1master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) または [mysql.rds\$1set\$1external\$1source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) と [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) プロシージャを使用して、ソース MySQL データベースをレプリケーションソースとして指定します。
ステップ 2 で特定したバイナリログファイル名と場所を使用します。以下に例を示します。
```
For Aurora MySQL version 2:
CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
For Aurora MySQL version 3:
CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306,
'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);
```
1. Amazon Aurora DB クラスターで、[mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) プロシージャを呼び出してレプリケーションを開始します。
```
CALL mysql.rds_start_replication;
```
出典 MySQL DB インスタンスと Amazon Aurora DB クラスター間のレプリケーションが確立されると、Aurora レプリカを Amazon Aurora DB クラスターに追加できます。その後で、Aurora レプリカに接続してデータの読み取りを拡張できます。Aurora レプリカの作成については、「[DB クラスターに Aurora レプリカを追加する](aurora-replicas-adding.md)」を参照してください。
# Aurora MySQL でのバイナリログのレプリケーションの最適化
次に、Aurora MySQL でバイナリログのレプリケーションのパフォーマンスを最適化し、関連する問題のトラブルシューティングを行う方法について説明します。
**ヒント**
この説明は、MySQL バイナリログのレプリケーションメカニズムとその仕組みに精通していることを前提としています。背景情報については、MySQL ドキュメントの「[レプリケーション実装ガイド](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html)」を参照してください。
## マルチスレッドバイナリログレプリケーション
マルチスレッドのバイナリログレプリケーションでは、SQL スレッドはリレーログからイベントを読み取り、SQL ワーカースレッドが適用されるようにキューに入れます。SQL ワーカースレッドは、コーディネータスレッドによって管理されます。バイナリログイベントは、可能な場合はパラレルに適用されます。並列処理のレベルは、バージョン、パラメータ、スキーマ設計、ワークロード特性などの要因によって異なります。
マルチスレッドバイナリログレプリケーションは、Aurora MySQL バージョン 3 および Aurora MySQL バージョン 2.12.1 以降でサポートされています。マルチスレッドレプリカがバイナリログイベントを効率的に並列処理するには、マルチスレッドバイナリログレプリケーションのソースを設定し、ソースでバイナリログファイルに並列処理情報を含むバージョンを使用する必要があります。
Aurora MySQL DB インスタンスがバイナリログレプリケーションを使用するように構成されている場合、レプリカインスタンスはデフォルトで 3.04 より前の Aurora MySQL バージョンに対してシングルスレッドレプリケーションを使用します。マルチスレッドレプリケーションを有効にするには、カスタムパラメータグループの `replica_parallel_workers` パラメータを `1` より大きい値に設定します。
Aurora MySQL バージョン 3.04 以降では、レプリケーションはデフォルトでマルチスレッド化され、`replica_parallel_workers` は `4` に設定されています。このパラメータはカスタムパラメータグループで変更できます。
予期しない停止に対するデータベースの耐障害性を高めるには、ソースで GTID レプリケーションを有効にし、レプリカで GTID を許可することをお勧めします。GTID レプリケーションを許可するには、ソースとレプリカの両方で `gtid_mode` を `ON_PERMISSIVE` に設定します。GTID ベースのレプリケーションの詳細については、「[GTID ベースレプリケーションを使用する](mysql-replication-gtid.md)」を参照してください。
以下の構成オプションを使用して、マルチスレッドレプリケーションを微調整することができます。使用量に関する情報については、*MySQL リファレンスマニュアル*の[レプリケーションとバイナリログのオプションと可変](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html)を参照してください。マルチスレッドレプリケーションの詳細については、MySQL ブログ「[https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/)」を参照してください。
最適なパラメータ値は、いくつかの要因によって決まります。例えば、バイナリログレプリケーションのパフォーマンスは、データベースワークロードの特性と、レプリカが実行されている DB インスタンスクラスの影響を受けます。したがって、新しいパラメータ設定を本番インスタンスに適用する前に、これらの構成パラメータに対するすべての変更を徹底的にテストすることをお勧めします。
+ `binlog_format recommended value` - に設定`ROW`
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_transaction_dependency_history_size`
+ `binlog_transaction_dependency_tracking` - 推奨値は `WRITESET` です。
+ `replica_preserve_commit_order`
+ `replica_parallel_type` - 推奨値は `LOGICAL_CLOCK` です。
+ `replica_parallel_workers`
+ `replica_pending_jobs_size_max`
+ `transaction_write_set_extraction` - 推奨値は `XXHASH64` です。
スキーマとワークロードの特性は、レプリケーションに並行して影響を与える要因です。最も一般的な問題を次に挙げます。
+ プライマリキーがない – RDS は、プライマリキーがないテーブルの writeset 依存関係を確立できません。`ROW` 形式を使用すると、ソースに対して 1 回のフルテーブルスキャンで 1 つの複数行ステートメントを実行できますが、レプリカで変更された行ごとに 1 回のフルテーブルスキャンになります。プライマリキーがないと、レプリケーションスループットが大幅に低下します。
+ 外部キーの存在 – 外部キーが存在する場合、Amazon RDS は FK 関係を持つテーブルの並列処理に writeset 依存関係を使用できません。
+ トランザクションのサイズ – 1 つのトランザクションが数十または数百メガバイトまたはギガバイトに及ぶ場合、コーディネータースレッドとワーカースレッドの 1 つがそのトランザクションのみの処理に長時間かかることがあります。その間、他のすべてのワーカースレッドは、以前のトランザクションの処理が終了した後もアイドル状態のままになる可能性があります。
Aurora MySQL バージョン 3.06 以降では、複数のセカンダリインデックスを持つ大きなテーブルのトランザクションをレプリケートするときにバイナリログレプリカのパフォーマンスを向上させることができます。この機能により、バイナリログレプリカにセカンダリインデックスの変更を並列で適用するスレッドプールが導入されます。この機能は `aurora_binlog_replication_sec_index_parallel_workers` DB クラスターパラメータによって制御されます。これにより、セカンダリインデックスの変更を適用できる並列スレッドの総数が制御されます。パラメータは、デフォルトで `0` (無効) に設定されています。この機能を有効にしてもインスタンスを再起動する必要はありません。この機能を有効にするには、進行中のレプリケーションを停止し、必要な数の並列ワーカースレッドを設定してから、レプリケーションを再開します。
## バイナリログのレプリケーションの最適化
Aurora MySQL 2.10 以降では、Aurora は、バイナリログのレプリケーションにバイナリログ I/O キャッシュと呼ばれる最適化を自動的に適用します。最後にコミットされたバイナリログイベントをキャッシュすることにより、この最適化は、バイナリログ出典インスタンスでのフォアグラウンドトランザクションへの影響を制限しながら、バイナリログのダンプスレッドのパフォーマンスを向上するように設計されています。
**注記**
この機能に使用されるこのメモリは、MySQL `binlog_cache` 設定とは無関係です。
この機能は、`db.t2` および `db.t3` インスタンスクラスを使用する Aurora DB インスタンスには適用されません。
この最適化を有効にするために、設定パラメータを調整する必要はありません。特に、以前の Aurora MySQL バージョンで設定パラメータ `aurora_binlog_replication_max_yield_seconds` をゼロ以外の値に調整した場合は、現在使用可能なバージョンでゼロに設定し直します。
これらのステータス変数 `aurora_binlog_io_cache_reads` と `aurora_binlog_io_cache_read_requests` は、バイナリログ I/O キャッシュからデータが読み込まれる頻度をモニタリングするのに役立ちます。
+ `aurora_binlog_io_cache_read_requests` はキャッシュからのバイナリログ I/O 読み取りリクエストの数を示します。
+ `aurora_binlog_io_cache_reads` はキャッシュから情報を取得するバイナリログ I/O 読み取り数を示します。
次の SQL クエリは、キャッシュされた情報を利用するバイナリログ読み取りリクエストの割合を計算します。この場合、比率が 100 に近づくほど、より良好であることを意味します。
```
mysql> SELECT
(SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads')
/ (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS
WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests')
* 100
as binlog_io_cache_hit_ratio;
+---------------------------+
| binlog_io_cache_hit_ratio |
+---------------------------+
| 99.99847949080622 |
+---------------------------+
```
バイナリログ I/O キャッシュ機能には、バイナリログのダンプスレッドに関連する新しいメトリクスも含まれています。*ダンプスレッド*は、新しいバイナリログレプリカがバイナリログ出典インスタンスに接続したときに作成されるスレッドです。
ダンプスレッドメトリクスは、60 秒ごとにプレフィックス `[Dump thread metrics]` を伴ってデータベースログに出力されます。メトリクスには、`Secondary_id`、`Secondary_uuid`、バイナリログのファイル名、各レプリカが読み込んでいる位置など、各バイナリログのレプリカの情報が含まれます。メトリクスには、レプリケーション出典とレプリカの間の距離をバイト単位で表す `Bytes_behind_primary` も含まれます。このメトリクスは、レプリカ I/O スレッドのラグを測定します。この数値は、バイナリログのレプリカの `seconds_behind_master` メトリクスによって表されるレプリカ SQL 適用元スレッドのラグとは異なります。距離が減少するか増加するかを確認することで、バイナリログレプリカが出典に追いついているのか、遅れているのかを判断できます。
## インメモリリレーログ
Aurora MySQL バージョン 3.10 以降では、レプリケーションのスループットを向上させるために、インメモリリレーログと呼ばれる最適化を導入しています。この最適化では、すべての中間リレーログコンテンツをメモリにキャッシュすることで、リレーログの I/O パフォーマンスを向上させます。その結果、リレーログコンテンツはメモリ内で簡単にアクセスできる状態となるため、ストレージ I/O オペレーションが最小限に抑えられ、コミットレイテンシーが短縮されます。
デフォルトでは、レプリカが次のいずれかの設定を満たす場合、インメモリリレーログ機能は Aurora マネージドレプリケーションシナリオ (ブルー/グリーンデプロイ、Aurora-Aurora レプリケーション、クロスリージョンレプリカなど) で自動的に有効になります。
+ シングルスレッドレプリケーションモード (replica\$1parallel\$1workers = 0)
+ GTID モードが有効になっているマルチスレッドレプリケーション:
+ 自動位置設定の有効化
+ レプリカで GTID モードを ON に設定
+ replica\$1preserve\$1commit\$1order = ON によるファイルベースのレプリケーション
インメモリリレーログ機能は、t3.large より大きいインスタンスクラスでサポートされていますが、Aurora Serverless インスタンスでは利用できません。リレーログの循環バッファのサイズは 128 MB に固定されています。この機能のメモリ消費量をモニタリングするには、次のクエリを実行できます。
```
SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache';
```
インメモリリレーログ機能は、aurora\$1in\$1memory\$1relaylog パラメータで制御します。このパラメータは、DB クラスターまたはインスタンスレベルで設定できます。この機能は、インスタンスを再起動しなくても、動的に有効化または無効化できます。
1. 進行中のレプリケーションを停止する
1. パラメータグループで aurora\$1in\$1memory\$1relaylog を ON (有効) または OFF (無効) に設定します。
1. レプリケーションを再開する
例:
```
CALL mysql.rds_stop_replication;
set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group
CALL mysql.rds_start_replication;
```
aurora\$1in\$1memory\$1relaylog を ON に設定している場合でも、特定の条件下ではインメモリリレーログ機能が無効になっている場合があります。この機能の現在のステータスを確認するには、次のコマンドを使用できます。
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status';
```
この機能が予期せず無効になっている場合は、次のコマンドを実行して理由を特定できます。
```
SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason';
```
このコマンドは、この機能が現在無効になっている理由を説明するメッセージを返します。
# Aurora MySQL の拡張バイナリログの設定
拡張バイナリログを使用すると、バイナリログを有効にすることによるコンピューティングパフォーマンスのオーバーヘッドを、場合によっては最大 50% まで削減できます。拡張バイナリログを使用すると、このオーバーヘッドを約 13% まで削減できます。オーバーヘッドを減らすために、拡張バイナリログはバイナリログとトランザクションログをストレージに並行に書き込みます。これにより、トランザクションコミット時に書き込まれるデータが最小限に抑えられます。
また、拡張バイナリログを使用すると、コミュニティ MySQL バイナリログと比較して、再起動およびフェイルオーバー後のデータベースの回復時間が最大 99% 向上します。拡張バイナリログは既存のバイナリログベースのワークロードと互換性があり、コミュニティ MySQL バイナリログと同じ方法で操作できます。
拡張バイナリログは Aurora MySQL 3.03.1 バージョン以降で利用できます。
**Topics**
+ [拡張バイナリログパラメータの設定](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)
+ [その他の関連パラメータ](#AuroraMySQL.Enhanced.binlog.other.parameters)
+ [拡張バイナリログとコミュニティ MySQL バイナリログの違い](#AuroraMySQL.Enhanced.binlog.differences)
+ [拡張バイナリログの Amazon CloudWatch メトリクス](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics)
+ [拡張バイナリログの制限](#AuroraMySQL.Enhanced.binlog.limitations)
## 拡張バイナリログパラメータの設定
拡張バイナリログパラメータをオン/オフにすることで、コミュニティ MySQL バイナリログと拡張バイナリログを切り替えることができます。既存のバイナリログコンシューマーは、バイナリログファイルシーケンスにギャップがなく、引き続きバイナリログファイルを読み込んで使用できます。
拡張バイナリログを有効にするには、次のパラメータを設定します。
| パラメータ | デフォルト | 説明 |
| --- | --- | --- |
| binlog\$1format | – | binlog\$1format パラメータを、選択したバイナリログ形式に設定して、拡張バイナリログをオンにします。binlog\$1format parameter がオフに設定されていないことを確認してください。詳細については、「[Aurora MySQL バイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html)」を参照してください。 |
| aurora\$1enhanced\$1binlog | 0 | Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、このパラメータの値を 1 に設定します。このパラメータの値を変更する場合、DBClusterParameterGroupStatus 値が pending-reboot と表示されている状態でライターインスタンスを再起動する必要があります。 |
| binlog\$1backup | 1 | 拡張バイナリログをオンにするには、このパラメータをオフにしてください。そのためには、このパラメータの値を 0 に設定します。 |
| binlog\$1replication\$1globaldb | 1 | 拡張バイナリログをオンにするには、このパラメータをオフにしてください。そのためには、このパラメータの値を 0 に設定します。 |
**重要**
`binlog_backup` と `binlog_replication_globaldb` パラメータは、拡張バイナリログを使用する場合にのみオフにできます。
拡張バイナリログを無効にするには、次のパラメータを設定します。
| パラメータ | 説明 |
| --- | --- |
| aurora\$1enhanced\$1binlog | Aurora MySQL クラスターに関連付けられている DB クラスターのパラメータグループで、このパラメータの値を 0 に設定します。このパラメータの値を変更する際は必ず、DBClusterParameterGroupStatus 値が pending-reboot と表示されている状態でライターインスタンスを再起動する必要があります。 |
| binlog\$1backup | 拡張バイナリログをオフにするには、このパラメータをオンにしてください。そのためには、このパラメータの値を 1 に設定します。 |
| binlog\$1replication\$1globaldb | 拡張バイナリログをオフにするには、このパラメータをオンにしてください。そのためには、このパラメータの値を 1 に設定します。 |
拡張バイナリログがオンになっているかどうかを確認するには、MySQL クライアントで次のコマンドを実行します。
```
mysql>show status like 'aurora_enhanced_binlog';
+------------------------+--------+
| Variable_name | Value |
+------------------------+--------+
| aurora_enhanced_binlog | ACTIVE |
+------------------------+--------+
1 row in set (0.00 sec)
```
拡張バイナリログがオンになっている場合、`aurora_enhanced_binlog` の出力は `ACTIVE` と表示されます。
## その他の関連パラメータ
拡張バイナリログを有効にすると、次のパラメータが影響を受けます。
+ `max_binlog_size` パラメータは表示されますが、変更できません。デフォルト値 `134217728` は、拡張バイナリログがオンになったときに `268435456` に自動調整されます。
+ コミュニティ MySQL バイナリログとは異なり、拡張バイナリログがオンになっていても、`binlog_checksum` は動的パラメータとして動作しません。このパラメータへの変更を有効にするには、`ApplyMethod` が `immediate` の場合にも DB クラスターを手動で再起動する必要があります。
+ `binlog_order_commits` パラメータに設定した値は、拡張バイナリログがオンになっているときのコミットの順序には影響しません。コミットは常に順序付けられ、それ以上パフォーマンスへの影響はありません。
## 拡張バイナリログとコミュニティ MySQL バイナリログの違い
拡張バイナリログは、コミュニティ MySQL バイナリログと比較したとき、クローン、バックアップ、Aurora グローバルデータベースとのインタラクションが異なります。拡張バイナリログを使用する前に、次の違いを理解しておくことをお勧めします。
+ ソース DB クラスターの拡張バイナリログファイルは、クローンされた DB クラスターでは使用できません。
+ 拡張バイナリファイルは Aurora バックアップには含まれていません。そのため、DB クラスターに保持期間が設定されていても、DB クラスターを復元した後は、ソース DB クラスターの拡張バイナリログファイルを使用できません。
+ Aurora グローバルデータベースで使用する場合、プライマリ DB クラスターの拡張バイナリログファイルはセカンダリリージョンの DB クラスターに複製されません。
****例****
次の例は、拡張バイナリログとコミュニティ MySQL バイナリログの違いを示しています。
**復元またはクローンされた DB クラスター上**
拡張バイナリログがオンになっている場合、復元またはクローンされた DB クラスターでは過去のバイナリログファイルを使用できません。復元またはクローン操作の後、バイナリログがオンになっている場合、新しい DB クラスターは 1 (mysql-bin-changelog.000001) から始まる独自のバイナリログファイルのシーケンスの書き込みを開始します。
復元またはクローン操作後に拡張バイナリログを有効にするには、復元またはクローンされた DB クラスターに必要な DB クラスターパラメーターを設定します。詳細については、「[拡張バイナリログパラメータの設定](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)」を参照してください。
**Example 例: 拡張バイナリログがオンになっているときに実行されるクローンまたは復元操作**
ソース DB クラスター:
```
mysql> show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
復元またはクローンされた DB クラスターでは、拡張バイナリログがオンになっていても、バイナリログファイルはバックアップされません。バイナリログデータの不連続性を避けるため、拡張バイナリログを有効にする前に書き込まれたバイナリログファイルも使用できません。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example 例: 拡張バイナリログがオフになっているときに実行されるクローンまたは復元操作**
ソース DB クラスター:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
拡張バイナリログは `mysql-bin-changelog.000003` の後に無効になります。復元またはクローンされた DB クラスターでは、拡張バイナリログをオフにした後に書き込まれたバイナリログファイルを使用できます。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Amazon Aurora Global Database で**
Amazon Aurora Global Database では、プライマリ DB クラスターのバイナリログデータはセカンダリ DB クラスターに複製レプリケートされません。クロスリージョンフェイルオーバープロセスの後、新たに昇格されたプライマリ DB クラスターでバイナリログデータを使用できなくなります。バイナリログがオンになっている場合、新たに昇格された DB クラスターは 1 (mysql-bin-changelog.000001) から始まる独自のバイナリログファイルのシーケンスを開始します。
フェイルオーバー後に拡張バイナリログを有効にするには、セカンダリ DB クラスターで必要な DB クラスターパラメータを設定する必要があります。詳細については、「[拡張バイナリログパラメータの設定](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters)」を参照してください。
**Example 例: 拡張バイナリログがオンになっている場合、グローバルデータベースフェイルオーバー操作が実行されます。**
古いプライマリ DB クラスター (フェイルオーバー前):
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No |
| mysql-bin-changelog.000003 | 156 | No |
| mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
新しいプライマリ DB クラスター (フェイルオーバー後):
拡張バイナリログがオンになっている場合、バイナリログファイルはセカンダリリージョンに複製されません。バイナリログデータの不連続性を避けるため、拡張バイナリログを有効にする前に書き込まれたバイナリログファイルは使用できません。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files
+----------------------------+-----------+-----------+
1 row in set (0.00 sec)
```
**Example 例: 拡張バイナリログがオフになっている場合、グローバルデータベースフェイルオーバー操作が実行されます。**
ソース DB クラスター:
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
6 rows in set (0.00 sec)
```
**復元またはクローンされた DB クラスター:**
拡張バイナリログは `mysql-bin-changelog.000003` の後に無効になります。拡張バイナリログをオフにした後に書き込まれたバイナリログファイルは複製され、新たに格された DB クラスターで使用できます。
```
mysql>show binary logs;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000004 | 156 | No |
| mysql-bin-changelog.000005 | 156 | No |
| mysql-bin-changelog.000006 | 156 | No |
+----------------------------+-----------+-----------+
3 rows in set (0.00 sec)
```
## 拡張バイナリログの Amazon CloudWatch メトリクス
以下の Amazon CloudWatch メトリクスは、拡張バイナリログがオンになっている場合にのみ公開されます。
| [CloudWatch メトリクス] | 説明 | 単位 |
| --- | --- | --- |
| ChangeLogBytesUsed | 拡張バイナリログで使用されるストレージ容量。 | バイト |
| ChangeLogReadIOPs | 5 分以内の、拡張バイナリログで実行される読み取り I/O オペレーションの数。 | 5 分あたりのカウント |
| ChangeLogWriteIOPs | 5 分以内の、拡張バイナリログで実行される書き込みディスク I/O オペレーションの数。 | 5 分あたりのカウント |
## 拡張バイナリログの制限
拡張バイナリログがオンになっている場合、Amazon Aurora DB クラスターには次の制限が適用されます。
+ 拡張バイナリログは Aurora MySQL 3.03.1 バージョン以降でのみサポートされています。
+ プライマリ DB クラスターに書き込まれた拡張バイナリログファイルは、クローンまたは復元された DB クラスターにはコピーされません。
+ Amazon Aurora Global Database で使用する場合、プライマリ DB クラスターの拡張バイナリログファイルはセカンダリ DB クラスターに複製されません。そのため、フェイルオーバープロセス後、過去のバイナリログデータは新しいプライマリ DB クラスターで使用できなくなります。
+ 以下のバイナリログ設定パラメータは無視されます。
+ `binlog_group_commit_sync_delay`
+ `binlog_group_commit_sync_no_delay_count`
+ `binlog_max_flush_queue_time`
+ データベース内の破損したテーブルを削除したり、名前を変更したりすることはできません。これらのテーブルを削除するには、サポート にお問い合わせください。
+ 拡張バイナリログがオンになっている場合、バイナリログ I/O キャッシュは無効になります。詳細については、「[Aurora MySQL でのバイナリログのレプリケーションの最適化](binlog-optimization.md)」を参照してください。
**注記**
拡張バイナリログでは、バイナリログ I/O キャッシュと同様の読み取りパフォーマンスと、向上した書き込みパフォーマンスが提供されます。
+ バックトラック機能はサポートされていません。次の条件では、拡張バイナリログを DB クラスターで有効にできません。
+ バックトラック機能が現在有効になっている DB クラスター。
+ バックトラック機能が以前に有効になっていたが、現在は無効化されていない DB クラスター。
+ ソース DB クラスターまたはバックトラック機能が有効になっているスナップショットから復元された DB クラスター。
# GTID ベースレプリケーションを使用する
以下では、Aurora MySQL クラスターと外部ソースとの間において、バイナリログ (binlog) レプリケーションでグローバルトランザクション ID (GTID) を使用する方法について説明します。
**注記**
Aurora では、この機能は、外部 MySQL データベースとの間で binlog レプリケーションを使用する Aurora MySQL クラスターでのみ使用できます。もう一方のデータベースは、Amazon RDS MySQL インスタンス、オンプレミス MySQL データベース、または別の AWS リージョン にある Aurora DB クラスターです。その種類のレプリケーションを設定する方法については、「[Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション (バイナリログレプリケーション)](AuroraMySQL.Replication.MySQL.md)」を参照してください。
binlog レプリケーションを使用する際に MySQL での GTID ベースのレプリケーションに慣れていない場合は、MySQL ドキュメントの「[Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html)」を参照してください。
GTID ベースのレプリケーションは、Aurora MySQL バージョン 2 および 3 でサポートされています。
**Topics**
+ [グローバルトランザクション ID (GTID) の概要](#mysql-replication-gtid.overview)
+ [GTID ベースレプリケーションのパラメータ](#mysql-replication-gtid.parameters)
+ [Aurora MySQL クラスターの GTID ベースのレプリケーションを有効にする](mysql-replication-gtid.configuring-aurora.md)
+ [Aurora MySQL DB クラスターの GTID ベースレプリケーションを無効にする](mysql-replication-gtid.disabling.md)
## グローバルトランザクション ID (GTID) の概要
*グローバルトランザクション ID (GTID)* はコミットされた MySQL トランザクションに対して生成される一意の ID です。GTID を使用することで、簡単に binlog をレプリケーションおよびトラブルシューティングできるようになります。
**注記**
Aurora がクラスター内の DB インスタンス間でデータを同期する場合、そのレプリケーションメカニズムにバイナリログ (binlog) は含まれません。Aurora MySQL では、GTID ベースのレプリケーションは、binlog レプリケーションも使用して外部の MySQL 互換データベースから Aurora MySQL DB クラスター間でレプリケートする場合にのみ適用されます。
MySQL では、binlog レプリケーションに 2 種類のトランザクションを使用します。
+ *GTID トランザクション* - GTID によって識別されるトランザクション。
+ *匿名トランザクション* - GTID が割り当てられていないトランザクション。
レプリケーション設定では、GTID はすべての DB インスタンスで一意です。GTID を使用すると、ログファイルの位置を参照する必要がないため、GTID はレプリケーション設定を簡素化します。GTID はまた、レプリケートされたトランザクションを追跡し、出典インスタンスとレプリカが一致しているかどうかの判断を容易にします。
外部の MySQL 互換データベースから Aurora クラスターにレプリケートする場合は通常、GTID ベースのレプリケーションを Aurora と共に使用します。このレプリケーション設定は、オンプレミスまたは Amazon RDS データベースから Aurora MySQL への移行の一環として行うことができます。外部データベースで既に GTID が使用されている場合に、Aurora クラスターに対して GTID ベースのレプリケーションを有効にすると、レプリケーションプロセスが簡単になります。
Aurora MySQL クラスター用に GTID ベースのレプリケーションを設定するには、まず DB クラスターパラメータグループの関連設定パラメータを設定します。その後、そのパラメータグループとクラスターを関連付けます。
## GTID ベースレプリケーションのパラメータ
以下のパラメータを使用して、GTID ベースレプリケーションを設定します。
| Parameter | 有効な値 | 説明 |
| --- | --- | --- |
| `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` は新しいトランザクションが匿名トランザクション (つまり GTID を持たない) であることを指定し、トランザクションは匿名でレプリケートされる必要があります。 `OFF_PERMISSIVE` は新しいトランザクションが匿名トランザクションであることを指定しますが、すべてのトランザクションをレプリケートできます。 `ON_PERMISSIVE` は新しいトランザクションが GTID トランザクションであることを指定しますが、すべてのトランザクションをレプリケートできます。 `ON` は新しいトランザクションが GTID トランザクションであることを指定し、トランザクションは複製される GTID トランザクションでなければなりません。 |
| `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` はトランザクションが GTID の整合性に違反することを許可します。 `ON` はトランザクションが GTID の整合性に違反することを防ぎます。 `WARN` は、トランザクションが GTID の整合性に違反することを許可しますが、違反が発生すると警告を生成します。 |
**注記**
AWS マネジメントコンソール では、`gtid_mode` パラメータは `gtid-mode` のように表示されます。
GTID ベースのレプリケーションでは、Aurora MySQL DB クラスターの DB クラスターパラメータグループでこれらの設定を使用します。
+ `ON` と `ON_PERMISSIVE` は、Aurora MySQL クラスターからの送信レプリケーションにのみ適用されます。いずれの値でも、Aurora DB クラスターは、外部データベースにレプリケートされるトランザクションに GTID を使用します。`ON` の場合は、外部データベースも GTID ベースのレプリケーションを使用する必要があります。`ON_PERMISSIVE` の場合、GTID ベースのレプリケーションは、外部データベースでオプションになります。
+ `OFF_PERMISSIVE` が設定された場合、これは、Aurora DB クラスターが、外部データベースからの受信レプリケーションを受け入れることができることを意味します。これは、外部データベースで GTID ベースのレプリケーションが使用されているかどうかにかかわらず実行することができます。
+ `OFF` が設定された場合、これは、Aurora DB クラスターが、GTID ベースのレプリケーションを使用しない外部データベースからの受信レプリケーションのみを受け入れることができることを意味します。
**ヒント**
受信レプリケーションは、Aurora MySQL クラスターの最も一般的な binlog レプリケーションのシナリオです。受信レプリケーションでは、GTID モードを `OFF_PERMISSIVE` に設定することをお勧めします。この設定では、レプリケーション出典の GTID 設定に関係なく、外部データベースからの受信レプリケーションが可能になります。
パラメータグループの詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
# Aurora MySQL クラスターの GTID ベースのレプリケーションを有効にする
GTID ベースのレプリケーションが Aurora MySQL DB クラスターで有効になっている場合、GTID 設定は、インバウンドとアウトバウンドの binlog レプリケーションのいずれにも適用されます。
**Aurora MySQL クラスターの GTID ベースのレプリケーションを有効にするには**
1. DB クラスターパラメータグループを作成または編集するには、以下のパラメータ設定を使用します。
+ `gtid_mode` - `ON` または `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. DB クラスターパラメータグループを Aurora MySQL クラスターに関連付けます。そのためには、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」の手順に従います。
1. (オプション) GTID を含まないトランザクションに GTID を割り当てる方法を指定します。これを行うには、[mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL バージョン 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions) でストアドプロシージャを呼び出します。
# Aurora MySQL DB クラスターの GTID ベースレプリケーションを無効にする
Aurora MySQL DB クラスターに対する GTID ベースのレプリケーションは、無効にすることができます。これを行うと、Aurora クラスターは、GTID ベースのレプリケーションを使用する外部データベースとのインバウンドまたはアウトバウンドの binlog レプリケーションを実行できなくなります。
**注記**
次の手順で、*リードレプリカ*は、外部データベースとの間で binlog レプリケーションを伴う Aurora 設定のレプリケーションターゲットを意味します。読み取り専用の Aurora レプリカ DB インスタンスを意味するものではありません。例えば、Aurora クラスターが外部出典からの受信レプリケーションを受け入れる場合、Aurora プライマリインスタンスは binlog レプリケーションのリードレプリカとして機能します。
このセクションで示されているストアドプロシージャの詳細については、「[Aurora MySQL ストアドプロシージャリファレンス](AuroraMySQL.Reference.StoredProcs.md)」を参照してください。
**に対して Aurora MySQL DB クラスターの GTID ベースのレプリケーションを無効にするには**
1. Aurora レプリカで、次の手順を実行します。
バージョン 3 の場合
```
CALL mysql.rds_set_source_auto_position(0);
```
バージョン 2 の場合
```
CALL mysql.rds_set_master_auto_position(0);
```
1. `gtid_mode` を `ON_PERMISSIVE` にリセットします。
1. Aurora MySQL クラスターに関連付けられている DB クラスターパラメータグループで、`gtid_mode` が `ON_PERMISSIVE` に設定されていることを確認します。
パラメータグループを使用して設定パラメータの設定の詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
1. Aurora MySQL DB クラスターを再起動します。
1. `gtid_mode` を `OFF_PERMISSIVE` にリセットします。
1. Aurora MySQL クラスターに関連付けられている DB クラスターパラメータグループで、`gtid_mode` が `OFF_PERMISSIVE` に設定されていることを確認します。
1. Aurora MySQL DB クラスターを再起動します。
1. すべての GTID トランザクションが Aurora プライマリインスタンスに適用されるまで待ちます。適用されたことを確認するには、次の手順を実行します。
1. Aurora プライマリインスタンスで、`SHOW MASTER STATUS` コマンドを実行します。
出力は次のようになります。
```
File Position
------------------------------------
mysql-bin-changelog.000031 107
------------------------------------
```
出力のファイルと位置に注意してください。
1. リードレプリカごとに、前のステップで得たソースインスタンスのファイルと位置の情報を使用して、次のクエリを実行します。
バージョン 3 の場合
```
SELECT SOURCE_POS_WAIT('file', position);
```
バージョン 2 の場合
```
SELECT MASTER_POS_WAIT('file', position);
```
例えば、ファイル名が `mysql-bin-changelog.000031` で、場所が `107` の場合は、次のステートメントを実行します。
バージョン 3 の場合
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
バージョン 2 の場合
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
1. GTID パラメータをリセットして、GTID ベースのレプリケーションを無効にします。
1. Aurora MySQL クラスターに関連付けられた DB クラスターパラメータグループに次のパラメータが設定されていることを確認します。
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. Aurora MySQL DB クラスターを再起動します。