# 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 クラスターのバイナリログ記録を有効にするには** <br />`binlog_format` DB クラスターパラメータを `ROW`、`STATEMENT`、または `MIXED` に設定します。特定のバイナリログ形式の必要性がない限り、`MIXED` をお勧めします。(デフォルト値は`OFF`です。)<br />`binlog_format` パラメータを変更するには、カスタム DB クラスターパラメータグループを作成し、そのカスタムパラメータグループを DB クラスターに関連付けます。デフォルト DB クラスターパラメータグループのパラメータは変更できません。<br />`binlog_format` パラメータを `OFF` から別の値に変更した場合、変更を有効にするには、Aurora DB クラスターを再起動する必要があります。<br /> 詳細については、「[Amazon Aurora の DB クラスターパラメータと DB インスタンスパラメータ](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups)」および「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。 | 
|  RDS for MySQL  |  **Amazon RDS DB インスタンスのバイナリログ記録を有効にするには** <br /> Amazon RDS DB インスタンスでは、バイナリログ記録を直接有効にすることはできませんが、以下のいずれかの操作により有効にすることができます。+   DB インスタンスの自動バックアップを有効にする。自動バックアップの有効化は、DB インスタンス作成時、または既存の DB インスタンスを変更することで可能です。詳細については、*Amazon RDS ユーザーガイド*の「[DB インスタンスの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)」を参照してください。 <br />+   DB インスタンスのリードレプリカを作成します。詳細については、*Amazon RDS ユーザーガイド*の「[リードレプリカの使用](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)」を参照してください。  | 
|  MySQL (外部) | **暗号化レプリケーションを設定するには**<br />Aurora MySQL バージョン 2 を使用してデータを安全に複製するには、暗号化されたレプリケーションを使用できます。  暗号化レプリケーションを使う必要がない場合、このステップをスキップできます。 <br /> 暗号化レプリケーションを使用するための前提条件は次のとおりです。+   Secure Sockets Layer (SSL) は、外部の MySQL マスターデータベースで有効になっている必要があります。 <br />+   クライアントのキーとクライアントの証明書が Aurora MySQL DB クラスター用に準備されている必要があります。 <br /> 暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。1.   暗号化レプリケーションのための準備があることを確認してください。    外部の MySQL マスターデータベースに有効になった SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアント証明書を生成します。    SSL が外部マスターで有効になっている場合は、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL 出典データベースで SSL の設定に使用した認証局キーが必要です。   <br /> 詳細については、MySQL ドキュメントの「[Creating SSL Certificates and Keys Using openssl](https://dev.mysql.com/doc/refman/8.0/en/creating-ssl-files-using-openssl.html)」を参照してください。 <br /> 認証局証明書、クライアントキーおよびクライアント証明書が必要となります。 <br />2.   SSL を使用して、マスターユーザーとして Aurora MySQL DB クラスターに接続します。 <br /> SSL で Aurora MySQL DB クラスターに接続する詳細については、「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。 <br />3.   `mysql.rds_import_binlog_ssl_material` ストアドプロシージャを実行して、Aurora MySQL DB クラスターに SSL 情報をインポートします。 <br /> `ssl_material_value` パラメータには、正しい JSON ペイロードで Aurora MySQL DB クラスター用の .pem 形式から情報を挿入します。 <br /> 次の例では、SSL 情報を Aurora MySQL DB クラスターにインポートします。.pem 形式ファイルでは、通常の場合、コード本文に例に示されるコード本文より長くなっています。 <pre>call mysql.rds_import_binlog_ssl_material(<br />'{"ssl_ca":"-----BEGIN CERTIFICATE-----<br />AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V<br />hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr<br />lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ<br />qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb<br />BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE<br />-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----<br />AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V<br />hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr<br />lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ<br />qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb<br />BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE<br />-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----<br />AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V<br />hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr<br />lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ<br />qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb<br />BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE<br />-----END RSA PRIVATE KEY-----\n"}');<br /></pre> <br /> 詳細については、「[mysql.rds\_import\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_import_binlog_ssl_material)」および「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。   手順を実行したあと、シークレットはファイルに保存されます。ファイルを後で消去するには、[mysql.rds\_remove\_binlog\_ssl\_material](mysql-stored-proc-replicating.md#mysql_rds_remove_binlog_ssl_material) ストアドプロシージャを実行できます。  <br /> **外部 MySQL データベースのバイナリログ記録を有効にするには** 1.   コマンドラインシェルから、mysql サービスを停止します。 <pre>sudo service mysqld stop</pre> <br />2.   `my.cnf` ファイルを編集します (このファイルは通常 `/etc` にあります)。 <pre>sudo vi /etc/my.cnf</pre> <br /> `log_bin` オプションと `server_id` オプションを `[mysqld]` に追加します。`log_bin` オプションは、バイナリログファイルのファイル名識別子を提供します。`server_id` オプションは、出典とレプリカの関係のサーバーに一意の識別子を提供します。 <br /> 暗号化レプリケーションが求められない場合、バイナリログが有効で、SSL は無効な状態で外部 MySQL データベースがスタートされるようにします。 <br /> 非暗号化データ用の `/etc/my.cnf` ファイルの関連するエントリを以下に示します。 <pre>log-bin=mysql-bin<br />server-id=2133421<br />innodb_flush_log_at_trx_commit=1<br />sync_binlog=1<br /></pre> <br /> 暗号化レプリケーションが求められる場合、外部 MySQL データベースが SSL およびバイナリログ有効化された状態でスタートすることを確認します。 <br /> `/etc/my.cnf` ファイルのエントリには、MySQL データベースサーバーの .pem ファイルの場所が含まれます。 <pre>log-bin=mysql-bin<br />server-id=2133421<br />innodb_flush_log_at_trx_commit=1<br />sync_binlog=1<br /><br /># Setup SSL.<br />ssl-ca=/home/sslcerts/ca.pem<br />ssl-cert=/home/sslcerts/server-cert.pem<br />ssl-key=/home/sslcerts/server-key.pem<br /></pre> <br /> また、MySQL DB インスタンスの `sql_mode` オプションを 0 に設定するか、my.cnf ファイルから除外する必要があります。 <br /> 外部の MySQL データベースに接続するときに、外部の MySQL データベースのバイナリログの場所を記録します。 <pre>mysql> SHOW MASTER STATUS;</pre> <br /> 出力は次のようになります。 <pre>+------------------+----------+--------------+------------------+-------------------+<br />| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |<br />+------------------+----------+--------------+------------------+-------------------+<br />| mysql-bin.000031 |      107 |              |                  |                   |<br />+------------------+----------+--------------+------------------+-------------------+<br />1 row in set (0.00 sec)<br /></pre> <br /> 詳細については、MySQL ドキュメントの [Setting the replication source configuration](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html) を参照してください。 <br />3.   mysql サービスをスタートします。 <pre>sudo service mysqld start</pre>  | 

## 2. レプリケーション出典のバイナリログを不要になるまで保持する
<a name="AuroraMySQL.Replication.MySQL.RetainBinlogs"></a>

MySQL バイナリログのレプリケーションを使用する場合、Amazon RDS はレプリケーションプロセスを管理しません。したがって、レプリケーション出典のバイナリログファイルは、変更がレプリカに適用されるまで保持する必要があります。このメンテナンスによって、障害発生時にソースデータベースを復元しやすくなります。

次のステップに従って、データベースエンジンのバイナリログを保持します。


|  データベースエンジン  |  手順  | 
| --- | --- | 
|  Aurora MySQL | **Aurora MySQL DB クラスターのバイナリログを保持するには**<br />Aurora MySQL DB クラスターのバイナリログファイルにはアクセスできません。そのため、確実に変更がレプリカに適用されてから、レプリケーション出典のバイナリログファイルが Amazon RDS によって削除されるように、バイナリログファイルの保持期間は十分に長く設定する必要があります。Aurora MySQL DB クラスターのバイナリログファイルは最大 90 日間、保持できます。<br />MySQL データベースまたは RDS for MySQL DB インスタンスをレプリカとしてレプリケーションを設定する場合、レプリカを作成するデータベースが巨大なときには、レプリカへのデータベースの初期のコピーが完了し、レプリカラグが 0 に達するまで、バイナリログファイルが保持されるように、保持期間を長く設定してください。<br />バイナリログの保持期間を設定するには、「[mysql.rds\_set\_configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration)」の手順を使用して、DB クラスターのバイナリログファイルの保持時間数に合わせて、`'binlog retention hours'` の設定パラメータを指定します。Aurora MySQL バージョン 2 以降、およびバージョン 3 の最大値は 2160 (90 日) です。<br />以下の例では、バイナリログファイルの保持期間を 6 日に設定しています。<pre>CALL mysql.rds_set_configuration('binlog retention hours', 144);</pre><br />レプリケーションが開始された後、レプリカに対して `SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを実行し、`Seconds behind master` フィールドを調べることで、変更がレプリカに適用されたことを確認できます。`Seconds behind master` フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、`binlog retention hours` 設定パラメータをより短い期間に設定することで、バイナリログファイルの保持期間を短くします。<br />この設定を指定しない場合、Aurora MySQL のデフォルト値は 24 (1 日) です。<br />`'binlog retention hours'` に最大値より大きい値を指定すると、Aurora MySQL は最大値を使用します。 | 
|  RDS for MySQL  |  **Amazon RDS DB インスタンスのバイナリログを保持するには** <br /> 前の行で説明したように、Amazon RDS DB インスタンスのバイナリログファイルを保持するには、保持期間を Aurora MySQL DB クラスターと同様に設定します。<br />DB インスタンスのリードレプリカを作成しても、Amazon RDS DB インスタンスのバイナリログファイルを保持できます。このリードレプリカはバイナリログファイルの保持専用に一時的に作成されます。リードレプリカが作成されたら、リードレプリカに対して [mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) プロシージャを呼び出します。レプリケーションの停止中に Amazon RDS がレプリケーション出典のバイナリログファイルを削除することはありません。永続レプリカとのレプリケーションを設定した後、レプリケーション出典と永続レプリカ間のレプリカラグ (`Seconds behind master` フィールド) が 0 に達したときに、リードレプリカを削除できます。 | 
|  MySQL (外部)  | **外部 MySQL データベースのバイナリログを有効にするには**<br />外部 MySQL データベースのバイナリログファイルは Amazon RDS によって管理されていないため、手動で削除されるまでは保持されます。<br />レプリケーションが開始された後、レプリカに対して `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 クラスターのコピーを作成するには**<br />次のいずれかの方法を使用します。+  DB クラスタースナップショットから復元します。   Amazon Aurora DB クラスターのスナップショットを作成します。詳細については、「[DB クラスタースナップショットの作成](USER_CreateSnapshotCluster.md)」を参照してください。   先ほど作成した DB クラスターのスナップショットから復元することで、新しい Aurora DB クラスターを作成します。 <br />復元された DB クラスターの DB パラメータグループは、元の DB クラスターと同一のものを維持してください。これを実行することで、DB クラスターのコピーでも確実にバイナリログ作成が有効になります。詳細については、「[DB クラスタースナップショットからの復元](aurora-restore-snapshot.md)」を参照してください。   <br />+  DB クラスターのクローンを作成します。詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。 <br />**バイナリログファイルの名前と位置を確認するには**<br />次のいずれかの方法を使用します。+  AWS マネジメントコンソール で次の操作を行います。   [**データベース**] を選択し、新しい Aurora DB クラスターのプライマリインスタンス (ライター) を選択して、その詳細を表示します。   [**最近のイベント**] までスクロールします。binlog ファイル名と場所を含むイベントメッセージが表示されます。イベントメッセージの形式は以下のとおりです。 <pre>Binlog position from crash recovery is {{binlog-file-name}} {{binlog-position}}</pre>   レプリケーションをスタートしたときの binlog ファイルの名前と場所の値を保存します。   <br />+  次の例のように、[describe-events](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-events.html) AWS CLI コマンドを呼び出します。 <pre>aws rds describe-events<br /><br />{<br />    "Events": [<br />        {<br />            "EventCategories": [],<br />            "SourceType": "db-instance",<br />            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",<br />            "Date": "2016-10-28T19:43:46.862Z",<br />            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",<br />            "SourceIdentifier": "sample-restored-instance"<br />        }<br />    ]<br />}</pre> <br />+  MySQL エラーログで、MySQL バイナリログファイルの最後の位置を確認します。 <br />**Aurora MySQL DB クラスターのダンプを作成するには**<br />レプリカターゲットが外部 MySQL データベースまたは RDS for MySQL DB インスタンスの場合、Aurora DB クラスターからダンプファイルを作成する必要があります。<br />作成したソース DB クラスターのコピーに対して、必ず `mysqldump` コマンドを実行してください。これは、ダンプを取る際のロックに関する考慮事項を避けるためです。ダンプがソース DB クラスターで直接作成された場合は、ダンプの進行中にソーステーブルへの同時書き込みを防ぐために、ソーステーブルをロックする必要があります。1.  MySQL クライアントを使用して DB クラスターに接続します。 <br />2.  `mysqldump` コマンドを発行します。例えば、次のようになります。 <pre>PROMPT> mysqldump --databases {{database_name}} --single-transaction<br />--order-by-primary -r backup.sql -u {{local_user}}s -p</pre> <br />3.  ダンプファイルを作成した後、DB クラスターのコピーを削除できます。  | 
| RDS for MySQL | **Amazon RDS DB インスタンスのスナップショットを作成するには**<br />Amazon RDS DB インスタンスのリードレプリカを作成します。詳細については、*Amazon Relational Database Service ユーザーガイド*の「[リードレプリカの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create)」を参照してください。1.  リードレプリカに接続し、[mysql.rds\_stop\_replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) プロシージャを実行することでレプリケーションを停止します。 <br />2.  リードレプリカが **停止** している間に、リードレプリカに接続して、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドを実行します。`Relay_Master_Log_File` フィールドから現在のバイナリログファイルの名前を、`Exec_Master_Log_Pos` フィールドからそのログファイルの場所を取得します。レプリケーションをスタートするときのために、これらの値を保存します。 <br />3.  リードレプリカが [**Stopped**] の状態のままで、リードレプリカの DB スナップショットを作成します。詳細については、*Amazon Relational Database Service ユーザーガイド*の「[DB スナップショットの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)」を参照してください。 <br />4.  リードレプリカを削除します。  | 
| MySQL (外部) | **外部 MySQL データベースのダンプを作成するには**1.  ダンプを作成する前に、ダンプのバイナリログの場所がソースインスタンスのデータで更新されていることを確認する必要があります。そのためには、まず以下のコマンドを使用して、インスタンスへの書き込みオペレーションを停止する必要があります。 <pre>mysql> FLUSH TABLES WITH READ LOCK;</pre> <br />2.  以下の `mysqldump` コマンドを使用して、MySQL データベースのダンプを作成します。 <pre>PROMPT> sudo mysqldump --databases {{database_name}} --master-data=2  --single-transaction \<br />--order-by-primary -r backup.sql -u {{local_user}} -p<br /></pre> <br />3.  ダンプを作成した後、次のコマンドを実行して、MySQL データベースのテーブルのロックを解除します。 <pre>mysql> UNLOCK TABLES;<br /></pre>  | 

## 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 クラスターにダンプをロードするには** 1.  `mysqldump` コマンドの出力をレプリケーション出典から、Aurora MySQL DB クラスターにも接続できる場所にコピーします。 <br />2.  `mysql` コマンドを使用して Aurora MySQL DB クラスターに接続します。次に例を示します。 <pre>PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p</pre> <br />3.  `mysql` プロンプトで、データベースダンプファイルの名前を渡して `source` コマンドを実行することで、Aurora MySQL DB クラスターにデータをロードします。例えば、以下のようになります。 <pre>mysql> source backup.sql;</pre>  | 
|  RDS for MySQL  | **Amazon RDS DB インスタンスにダンプをロードするには**1.  `mysqldump` コマンドの出力をレプリケーション出典から、MySQL DB インスタンスにも接続できる場所にコピーします。 <br />2.  `mysql` コマンドを使用して MySQL DB インスタンスに接続します。次に例を示します。 <pre>PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p</pre> <br />3.  `mysql` プロンプトで、データベースダンプファイルの名前を渡して `source` コマンドを実行することで、MySQL DB インスタンスにデータをロードします。例えば、以下のようになります。 <pre>mysql> source backup.sql;</pre>  | 
| MySQL (外部) | **外部 MySQL データベースにダンプをロードするには**<br />外部 MySQL データベースに DB スナップショットまたは DB クラスターのスナップショットをロードすることはできません。代わりに、`mysqldump` コマンドの出力を使用する必要があります。1.  `mysqldump` コマンドの出力をレプリケーション出典から、MySQL データベースにも接続できる場所にコピーします。 <br />2.  `mysql` コマンドを使用して MySQL データベースに接続します。次に例を示します。 <pre>PROMPT> mysql -h {{host_name}} -port=3306 -u {{db_master_user}} -p</pre> <br />3.  `mysql` プロンプトで、データベースダンプファイルの名前を渡して `source` コマンドを実行することで、MySQL データベースにデータをロードします。次に例を示します。 <pre>mysql> source backup.sql;</pre>  | 

## 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\_name\_resolve](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 クラスターからのレプリケーションを有効にするには** 1.  複製の開始点を見つけます。バイナリログのファイル名と位置が必要です。 <br />DB クラスターのレプリカターゲットが以下から作成された場合:   DB クラスタースナップショットまたはクローン — [3. レプリケーションソースのコピーまたはダンプを作成する](#AuroraMySQL.Replication.MySQL.CreateSnapshot) に示すように、DB クラスターの最近のイベントからバイナリログファイルの名前と位置を取得します。   DB snapshot – レプリケーションソースのスナップショットを作成した際、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドから、バイナリログファイルの名前と位置を取得しました。   <br />2.  DB クラスターに接続し、前の手順からのバイナリログファイルの名前と場所を使用して次のプロシージャを呼び出し、レプリケーションソースとのレプリケーションを開始します。   [mysql.rds\_set\_external\_source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source)   [mysql.rds\_set\_external\_master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master)   [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) (すべてのバージョン)   <br />次の例は、Aurora MySQL バージョン 3 の場合です。 <pre>CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,<br />    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);<br />CALL mysql.rds_start_replication;</pre> <br />SSL 暗号化を使用するには、最終値を `0` ではなく `1` に設定します。 | 
|  RDS for MySQL  |  **Amazon RDS DB インスタンスからのレプリケーションを有効にするには** 1.   DB インスタンスレプリカターゲットが DB スナップショットから作成された場合は、レプリケーションにはまずバイナリログファイルの名前と場所が必要になります。レプリケーションソースのスナップショットを作成した際、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドから、これらの値を取得しました。 <br />2.  DB インスタンスに接続し、[mysql.rds\_set\_external\_master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) または [mysql.rds\_set\_external\_source (Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) と [mysql.rds\_start\_replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) プロシージャを呼び出して、レプリケーションソースとのレプリケーションを開始します。前のステップで取得したバイナリログファイルの名前と場所を使用します。以下に例を示します。 <pre>CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,<br />    'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0);<br />CALL mysql.rds_start_replication;</pre> <br />SSL 暗号化を使用するには、最終値を `0` ではなく `1` に設定します。 | 
|  MySQL (外部)  |  **外部 MySQL データベースからのレプリケーションを有効にするには** 1.   レプリケーションにまず必要になるバイナリログファイルの名前と場所を取得します。レプリケーションソースのスナップショットを作成した際、`SHOW SLAVE STATUS` (Aurora MySQL バージョン 2) または `SHOW REPLICA STATUS` (Aurora MySQL バージョン 3) コマンドから、これらの値を取得しました。外部の MySQL レプリカターゲットへのデータロードに `mysqldump` オプションを指定して実行した `--master-data=2` コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。以下に例を示します。 <pre>--<br />-- Position to start replication or point-in-time recovery from<br />--<br /><br />-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;</pre> <br />2.   外部の MySQL レプリカターゲットに接続し、`CHANGE MASTER TO` と `START SLAVE` (Aurora MySQL バージョン 2) または `START REPLICA` (Aurora MySQL バージョン 3) を発行して、前のステップで確認したバイナリログファイル名と場所を使用してレプリケーションソースとのレプリケーションを開始します。次に例を示します。 <pre>CHANGE MASTER TO<br />  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',<br />  MASTER_PORT = 3306,<br />  MASTER_USER = 'repl_user',<br />  MASTER_PASSWORD = 'password',<br />  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',<br />  MASTER_LOG_POS = 107;<br />-- And one of these statements depending on your engine version:<br />START SLAVE; -- Aurora MySQL version 2<br />START REPLICA; -- Aurora MySQL version 3</pre>  | 

レプリケーションが失敗した場合、レプリカにおいて意図しない I/O が大幅に増加することで、パフォーマンスが低下する可能性があります。レプリケーションが失敗するか、不要になった場合は、[mysql.rds\_reset\_external\_master (Aurora MySQL バージョン 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) または [mysql.rds\_reset\_external\_source (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\_start\_replication\_until(Aurora MySQL バージョン 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) ストアドプロシージャを使用してレプリケーションを開始してバイナリログファイルの指定した位置で停止できます。

**リードレプリカへのレプリケーションをスタートして指定の位置でレプリケーションを停止するには**

1. MySQL クライアントを使用して、マスターユーザーとしてレプリカ Aurora MySQL DB クラスターに接続します。

1. [mysql.rds\_start\_replication\_until(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\_start\_replication\_until\_gtid(Aurora MySQL バージョン 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) ストアドプロシージャの代わりに、[mysql.rds\_start\_replication\_until(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 を使用してレプリケーション出典のマスターパスワードを変更した場合、それらの変更はレプリケーションターゲットに自動的にレプリケートされません。出典システムとターゲットシステム間でマスターユーザーとマスターパスワードを同期する場合は、レプリケーションターゲットに対して同様の変更を自分で行う必要があります。