# Aurora MySQL のバイナリログレプリケーションの設定
<a name="AuroraMySQL.Replication.MySQL.SettingUp"></a>

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. レプリケーション出典のバイナリログ記録を有効にする
<a name="AuroraMySQL.Replication.MySQL.EnableBinlog"></a>

 以下のデータベースエンジンのレプリケーション出典で、バイナリログを有効にする手順を確認します。


|  データベースエンジン  |  手順  | 
| --- | --- | 
|   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. レプリケーション出典のバイナリログを不要になるまで保持する
<a name="AuroraMySQL.Replication.MySQL.RetainBinlogs"></a>

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 日に設定しています。 <pre>CALL mysql.rds_set_configuration('binlog retention hours', 144);</pre> レプリケーションが開始された後、レプリカに対して `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. レプリケーションソースのコピーまたはダンプを作成する
<a name="AuroraMySQL.Replication.MySQL.CreateSnapshot"></a>

レプリケーションソースのスナップショット、クローン、またはダンプを使用して、データのベースラインコピーをレプリカにロードします。次に、その時点からレプリケーションを開始します。

次の指示に従って、データベースエンジンのレプリケーションソースのコピーまたはダンプを作成します。


| データベースエンジン | 手順 | 
| --- | --- | 
|   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. レプリカターゲットにダンプをロードする (必要な場合)
<a name="AuroraMySQL.Replication.MySQL.LoadSnapshot"></a>

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. レプリケーションソースでレプリケーションユーザーを作成する
<a name="AuroraMySQL.Replication.MySQL.CreateReplUser"></a>

レプリケーション専用のユーザー 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. レプリカターゲットでレプリケーションを有効にする
<a name="AuroraMySQL.Replication.MySQL.EnableReplication"></a>

レプリケーションを有効化する前に、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) ストアドプロシージャを実行して、レプリケーション設定を削除できます。

### リードレプリカへのレプリケーションを停止する場所の設定
<a name="AuroraMySQL.Replication.StartReplicationUntil"></a>

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. レプリカをモニタリングする
<a name="AuroraMySQL.Replication.MySQL.Monitor"></a>

 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 クラスターをアップグレードし、カスタムパラメータグループを指定した場合は、アップグレード終了後にクラスターを手動で再起動してください。これにより、クラスターは新しいカスタムパラメータ設定を使用し、バイナリログレプリケーションを再開します。

## レプリケーション出典とレプリケーションターゲット間でのパスワードの同期
<a name="AuroraMySQL.Replication.passwords"></a>

 SQL ステートメントを使用してレプリケーション出典のユーザーアカウントとパスワードを変更すると、それらの変更はレプリケーションターゲットに自動的にレプリケートされます。

 AWS マネジメントコンソール、AWS CLI、または RDS API を使用してレプリケーション出典のマスターパスワードを変更した場合、それらの変更はレプリケーションターゲットに自動的にレプリケートされません。出典システムとターゲットシステム間でマスターユーザーとマスターパスワードを同期する場合は、レプリケーションターゲットに対して同様の変更を自分で行う必要があります。