

# Amazon RDS for MySQL のマルチソースレプリケーションの設定
<a name="mysql-multi-source-replication"></a>

マルチソースレプリケーションを使用すると、Amazon RDS for MySQL DB インスタンスを、複数の RDS for MySQL ソース DB インスタンスからバイナリログイベントを受信するレプリカとして設定できます。マルチソースレプリケーションは、次のエンジンバージョンを実行している RDS for MySQL DB インスタンスでサポートされています。
+ すべての MySQL 8.4 バージョン
+ 8.0.35 以降のマイナーバージョン
+ 5.7.44 以降のマイナーバージョン

MySQL マルチソースレプリケーションの詳細については、MySQL ドキュメントの「[MySQL マルチソースレプリケーション](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html)」を参照してください。MySQL ドキュメントにはこの機能に関する詳細情報が含まれていますが、このトピックでは RDS for MySQL DB インスタンスでマルチソースレプリケーションチャネルを設定および管理する方法を説明します。

## マルチソースレプリケーションのユースケース
<a name="mysql-multi-source-replication-benefits"></a>

以下のケースは、RDS for MySQL でマルチソースレプリケーションを使用するのに適しています。
+ 個別の DB インスタンス上の複数のシャードを 1 つのシャードにマージまたは結合する必要があるアプリケーション。
+ 複数のソースから統合されたデータからレポートを生成する必要があるアプリケーション。
+ 複数の RDS for MySQL DB インスタンスに分散されるデータの統合された長期バックアップを作成するための要件。

## マルチソースレプリケーションの前提条件
<a name="mysql-multi-source-replication-prerequisites"></a>

マルチソースレプリケーションを設定する前に、以下の前提条件を完了してください。
+ 各ソース RDS for MySQL DB インスタンスで自動バックアップが有効になっていることを確認します。自動バックアップを有効にすると、バイナリログ記録が有効になります。自動バックアップを有効にする方法については、「[自動バックアップの有効化](USER_WorkingWithAutomatedBackups.Enabling.md)」を参照してください。
+ レプリケーションエラーを回避するには、ソース DB インスタンスへの書き込み操作をブロックすることをお勧めします。そのためには、RDS for MySQL ソース DB インスタンスにアタッチされたカスタムパラメータグループで、`read-only` パラメータを `ON` に設定します。AWS マネジメントコンソール または AWS CLI を使用して、新しいカスタムパラメータグループを作成するか、既存のものを変更できます。詳細については、「[Amazon RDS での DB パラメータグループの作成](USER_WorkingWithParamGroups.Creating.md)」および「[Amazon RDS の DB パラメータグループのパラメータの変更](USER_WorkingWithParamGroups.Modifying.md)」を参照してください。
+ ソース DB インスタンスごとに、インスタンスの IP アドレスをマルチソース DB インスタンスの Amazon 仮想プライベートクラウド (VPC) セキュリティグループに追加します。ソース DB インスタンスの IP アドレスを識別するには、 コマンド `dig RDS Endpoint` を実行します。送信先のマルチソース DB インスタンスと同じ VPC 内の Amazon EC2 インスタンスから コマンドを実行します。
+ 次の例のように、ソース DB インスタンスごとに、クライアントを使用して DB インスタンスに接続し、レプリケーションに必要な権限を持つデータベースユーザーを作成します。

  ```
  CREATE USER 'repl_user' IDENTIFIED BY 'password';
  GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user';
  ```
**注記**  
MySQL 8.4 以降、`REPLICATION SLAVE` 権限は廃止され、`REPLICATION REPLICA` に置き換えられました。MySQL 8.4 以降のバージョンでは、次の構文を代わりに使用します。  

  ```
  CREATE USER 'repl_user' IDENTIFIED BY 'password';
  GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user';
  ```

## RDS for MySQL DB インスタンスでのマルチソースレプリケーションチャネルの設定
<a name="mysql-multi-source-replication-configuring-channels"></a>

マルチソースレプリケーションチャネルの設定は、シングルソースレプリケーションの設定と同様です。マルチソースレプリケーションの場合、まず、ソースインスタンスのバイナリログ記録を有効にします。次に、ソースからマルチソースレプリカにデータをインポートします。次に、バイナリログ座標を使用するか、GTID 自動配置を使用して、各ソースからレプリケーションを開始します。

RDS for MySQL DB インスタンスを 2 つ以上の RDS for MySQL DB インスタンスのマルチソースレプリカとして設定するには、以下のステップを実行します。

**Topics**
+ [ステップ 1: ソース DB インスタンスからマルチソースレプリカにデータをインポートする](#mysql-multi-source-replication-import)
+ [ステップ 2: ソース DB インスタンスからマルチソースレプリカへのレプリケーションを開始する](#mysql-multi-source-replication-setting-up-start-replication-other)

### ステップ 1: ソース DB インスタンスからマルチソースレプリカにデータをインポートする
<a name="mysql-multi-source-replication-import"></a>

各ソース DB インスタンスで以下のステップを実行します。

ソースからマルチソースレプリカにデータをインポートする前に、 `SHOW MASTER STATUS` コマンドを実行して、現在のバイナリログファイルと場所を決定します。次のステップで使用するために、これらの詳細を書き留めておきます。この出力例では、ファイルは `mysql-bin-changelog.000031` であり、場所は `107` です。

**注記**  
MySQL 8.4 以降、`SHOW MASTER STATUS` コマンドは廃止され、`SHOW BINARY LOG STATUS` に置き換えられました。MySQL 8.4 以降のバージョンでは、代わりに `SHOW BINARY LOG STATUS` を使用します。

```
File                        Position   
-----------------------------------
mysql-bin-changelog.000031      107   
-----------------------------------
```

次に、次の例のように、`mysqldump` を使用して、ソース DB インスタンスからマルチソースレプリカにデータベースをコピーします。

```
mysqldump --databases database_name \
 --single-transaction \
 --compress \
 --order-by-primary \
 -u RDS_user_name \
 -p RDS_password \
 --host=RDS Endpoint | mysql \
 --host=RDS Endpoint \
 --port=3306 \
 -u RDS_user_name \
-p RDS_password
```

データベースをコピーしたら、ソース DB インスタンスの読み取り専用パラメータを `OFF` に設定できます。

### ステップ 2: ソース DB インスタンスからマルチソースレプリカへのレプリケーションを開始する
<a name="mysql-multi-source-replication-setting-up-start-replication-other"></a>

ソース DB インスタンスごとに、管理者ユーザーの認証情報を使用してインスタンスに接続し、次の 2 つのストアドプロシージャを実行します。これらのストアドプロシージャは、チャネルでレプリケーションを設定し、レプリケーションを開始します。この例では、前のステップの出力例のバイナリログファイルの名前と場所を使用します。

```
CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1');
CALL mysql.rds_start_replication_for_channel('channel_1');
```

これらのストアドプロシージャやその他を使用してレプリケーションチャネルを設定および管理する方法の詳細については、「[マルチソースレプリケーションの管理](mysql-stored-proc-multi-source-replication.md)」を参照してください。

## マルチソースレプリケーションでのフィルターの使用
<a name="mysql-multi-source-replication-filters"></a>

レプリケーションフィルターを使用して、マルチソースレプリカでレプリケートするデータベースとテーブルを指定できます。レプリケーションフィルターは、データベースとテーブルをレプリケーションに含めることも、レプリケーションから除外することもできます。レプリケーションフィルターの詳細については、「[MySQL でのレプリケーションフィルターの設定](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md)」を参照してください。

マルチソースレプリケーションでは、レプリケーションフィルターをグローバルまたはチャネルレベルで設定できます。チャネルレベルのフィルタリングは、 バージョン 8.0 または 8.4 を実行するサポートされている DB インスタンスでのみ使用できます。次の例は、グローバルまたはチャネルレベルでフィルターを設定する方法を示しています。

マルチソースレプリケーションでのフィルタリングでは、次の要件と動作に注意してください。
+ チャネル名をバッククォート (``) で囲む必要があります。
+ パラメータグループのレプリケーションフィルターを変更すると、更新を含むすべてのチャネルのマルチソースレプリカの `sql_thread` が再起動され、変更が動的に適用されます。更新にグローバルフィルターが含まれる場合、実行状態のすべてのレプリケーションチャネルが再起動されます。
+ すべてのグローバルフィルターは、チャネル固有のフィルターの前に適用されます。
+ フィルタがグローバルに適用され、チャネルレベルで適用されている場合、チャネルレベルのフィルタのみが適用されます。例えば、フィルターが `replicate_ignore_db="db1,`channel_22`:db2"` の場合、`db1` に設定された `replicate_ignore_db` が `channel_22` 以外のすべてのチャネルに適用された場合、`channel_22` のみは `db2` からの変更を無視します。

例 1: グローバルフィルターの設定

次の例では、`temp_data` データベースはすべてのチャネルのレプリケーションから除外されます。

Linux、macOS、Unix の場合:

```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate"
```

例 2: チャネルレベルフィルターの設定

次の例では、`sample22` データベース からの変更はチャネル `channel_22` にのみ含まれます。同様に、`sample99` データベース からの変更は、チャンネル `channel_99` にのみ含まれます。

Linux、macOS、Unix の場合:

```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate"
```

## マルチソースレプリケーションチャネルのモニタリング
<a name="mysql-multi-source-replication-monitoring"></a>

次の方法を使用して、マルチソースレプリカの個々のチャネルをモニタリングできます。
+ すべてのチャネルまたは特定のチャネルのステータスをモニタリングするには、マルチソースレプリカに接続し、`SHOW REPLICA STATUS` または `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` コマンドを実行します。詳細については、MySQL ドキュメントの「[レプリケーションステータスのチェック](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html)」を参照してください。
+ レプリケーションチャネルが開始、停止、または削除されたときに通知を受け取るには、RDS イベント通知を使用します。詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
+ 特定のチャネルの遅延をモニタリングするには、そのチャネルの `ReplicationChannelLag`メトリクスを確認します。このメトリクスのデータポイントは期間が 60 秒 (1 分) であり、15 日間使用できます。チャネルのレプリケーションチャネルラグを特定するには、インスタンス識別子とレプリケーションチャネル名を使用します。この遅延が特定のしきい値を超えたときに通知を受け取るには、CloudWatch アラームを設定できます。詳細については、「[Amazon CloudWatch を使用した Amazon RDS メトリクスのモニタリング](monitoring-cloudwatch.md)」を参照してください。

## マルチソースレプリケーションの考慮事項とベストプラクティス
<a name="mysql-multi-source-replication-considerations"></a>

RDS for MySQL でマルチソースレプリケーションを使用する前に、以下の考慮事項とベストプラクティスを確認してください。
+ マルチソースレプリカとして設定された DB インスタンスに、複数のソースインスタンスからのワークロードを処理するのに十分なリソース (スループット、メモリ、CPU、IOPS など) があることを確認します。
+ マルチソースレプリカのリソース使用率を定期的にモニタリングし、リソースに負荷をかけずにワークロードを処理するようにストレージまたはインスタンスの設定を調整します。
+ システム変数 `replica_parallel_workers` を `0` より大きい値に設定することで、マルチソースレプリカでマルチスレッドレプリケーションを設定できます。この場合、各チャネルに割り当てられるスレッド数は、この変数の値に、適用スレッドを管理する 1 つのコーディネータースレッドを足した数です。
+ 競合を避けるために、レプリケーションフィルターを適切に設定します。データベース全体をレプリカの別のデータベースにレプリケートするには、`--replicate-rewrite-db` オプションを使用できます。例えば、データベース A のすべてのテーブルをレプリカインスタンスのデータベース B にレプリケートできます。このアプローチは、すべてのソースインスタンスが同じスキーマ命名規則を使用している場合に役立ちます。`--replicate-rewrite-db` オプションの詳細については、MySQL ドキュメントで「[Replica Server Options and Variables](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html)」を参照してください。
+ レプリケーションエラーを回避するには、レプリカに書き込まないでください。マルチソースレプリカで `read_only` パラメータを有効にして、書き込み操作をブロックすることをお勧めします。これにより、書き込み操作の競合によるレプリケーションの問題を排除できます。
+ マルチソースレプリカで実行されるソートや高負荷結合などの読み取り操作のパフォーマンスを向上させるには、RDS Optimized Reads の使用を検討してください。この機能は、大きな一時テーブルまたはソートファイルに依存するクエリに役立ちます。詳細については、「[Amazon RDS Optimized Reads による RDS for MySQL のクエリパフォーマンスの向上](rds-optimized-reads.md)」を参照してください。
+ レプリケーションの遅延を最小限に抑え、マルチソースレプリカのパフォーマンスを向上させるには、最適化された書き込みを有効にすることを検討してください。詳細については、「[RDS Optimized Writes for MySQL による書き込みパフォーマンスの向上](rds-optimized-writes.md)」を参照してください。
+ 一度に 1 つのチャネルで管理操作 (設定の変更など) を実行し、複数の接続から複数のチャンネルに変更を実行しないようにします。これらのプラクティスにより、レプリケーション操作で競合が発生する可能性があります。例えば、複数の接続から `rds_skip_repl_error_for_channel` と `rds_start_replication_for_channel` プロシージャを同時に実行すると、意図したのとは異なるチャネルでイベントがスキップされる可能性があります。
+ マルチソースレプリケーションインスタンスでバックアップを有効にし、そのインスタンスから Amazon S3 バケットにデータをエクスポートして、長期間保存できます。ただし、個々のソースインスタンスで適切な保持期間を持つバックアップを設定することも重要です。Amazon S3 へのスナップショットデータのエクスポートの詳細については、「[Amazon RDS の Amazon S3 への DB スナップショットデータのエクスポート](USER_ExportSnapshot.md)」を参照してください。
+ マルチソースレプリカへの読み取りワークロードを分散するには、マルチソースレプリカからリードレプリカを作成できます。これらのリードレプリカは、アプリケーションの要件に応じて異なる AWS リージョン に配置できます。リードレプリカの詳細については、「[MySQL リードレプリカの使用](USER_MySQL.Replication.ReadReplicas.md)」を参照してください。

## RDS for MySQL のマルチソースレプリケーションの制限事項
<a name="mysql-multi-source-replication-limitations"></a>

RDS for MySQL のマルチソースレプリケーションには、以下の制限が適用されます。
+ 現在、RDS for MySQL では、マルチソースレプリカに最大 15 個のチャネルを設定できます。
+ リードレプリカインスタンスをマルチソースレプリカとして設定することはできません。
+ エンジンバージョン 5.7 を実行している RDS for MySQL でマルチソースレプリケーションを設定するには、レプリカインスタンスで Performance Schema を有効にする必要があります。エンジンバージョン 8.0 または 8.4 を実行している RDS for MySQL では、Performance Schema の有効化はオプションです。
+ エンジンバージョン 5.7 を実行している RDS for MySQL の場合、レプリケーションフィルターはすべてのレプリケーションチャネルに適用されます。エンジンバージョン 8.0 または 8.4 を実行している RDS for MySQL では、すべてのレプリケーションチャネルまたは個々のチャネルに適用されるフィルターを設定できます。
+ RDS スナップショットを復元するか、ポイントインタイムリストア (PITR) を実行しても、マルチソースのレプリカチャネル設定は復元されません。
+ マルチソースレプリカのリードレプリカを作成すると、マルチソースインスタンスからのデータのみがレプリケートされます。チャネル設定は復元されません。
+ MySQL は、チャネルごとに異なる数の並列ワーカーの設定をサポートしていません。すべてのチャンネルが、`replica_parallel_workers` 値に基づいて同じ数の並列ワーカーを取得します。

マルチソースレプリケーションターゲットがマルチ AZ DB クラスターの場合、以下の追加制限が適用されます。
+ ソース RDS for MySQL インスタンスへの書き込みが発生する前に、そのインスタンスにチャネルを設定する必要があります。
+ 各ソース RDS for MySQL インスタンスでは、GTID ベースのレプリケーションが有効になっている必要があります。
+ DB クラスターのフェイルオーバーイベントにより、マルチソースレプリケーション設定が削除されます。その設定を復元するには、設定ステップを繰り返す必要があります。