マルチソースレプリケーショントポロジのソースに既存のデータがある場合、レプリケーションを開始する前にレプリカに関連データをプロビジョニングする時間を節約できます。 マルチソースレプリケーショントポロジでは、データディレクトリのクローニングまたはコピーを使用して、レプリカにすべてのソースのデータをプロビジョニングすることはできません。また、各ソースから特定のデータベースのみをレプリケートすることもできます。 したがって、このようなレプリカをプロビジョニングする最善の戦略は、mysqldump を使用して各ソースに適切なダンプファイルを作成し、mysql クライアントを使用してレプリカにダンプファイルをインポートすることです。
GTID ベースのレプリケーションを使用している場合は、mysqldump がダンプ出力に配置する SET @@GLOBAL.gtid_purged ステートメントに注意する必要があります。 このステートメントは、ソースで実行されたトランザクションの GTID をレプリカに転送し、レプリカはこの情報を必要とします。 ただし、あるソースから新しい空のレプリカをプロビジョニングするよりも複雑な場合は、レプリカで使用される MySQL のバージョンでステートメントの影響を確認し、それに応じてステートメントを処理する必要があります。 次のガイダンスは、適切なアクションの概要を示していますが、詳細は、mysqldump のドキュメントを参照してください。
mysqldump によって記述された SET @@GLOBAL.gtid_purged ステートメントの動作は、MySQL 8.0 と MySQL 5.6 および 5.7 のリリースでは異なります。 MySQL 5.6 および 5.7 では、このステートメントによってレプリカ上の gtid_purged の値が置き換えられ、それらのリリースでは GTID (gtid_executed セット) を含むトランザクションのレプリカレコードが空の場合にのみその値を変更できます。 したがって、マルチソースレプリケーショントポロジでは、ダンプファイルをリプレイする前に、ダンプ出力から SET @@GLOBAL.gtid_purged ステートメントを削除する必要があります。これは、このステートメントを含む別のダンプファイルまたは後続のダンプファイルを適用できないためです。 また、MySQL 5.6 および 5.7 の場合、この制限は、ソースのすべてのダンプファイルを空の gtid_executed セットを持つレプリカに対する単一の操作で適用する必要があることを意味します。 レプリカ上で RESET MASTER を発行することでレプリカ GTID 実行履歴をクリアできますが、レプリカ上に GTID との別のトランザクションが必要な場合は、セクション17.1.3.5「フェイルオーバーおよびスケールアウトでの GTID の使用」 で説明されているプロビジョニング方法から別の方法を選択します。
MySQL 8.0 から、SET @@GLOBAL.gtid_purged ステートメントは GTID セットをダンプファイルからレプリカ上の既存の gtid_purged セットに追加します。 したがって、レプリカでダンプファイルをリプレイすると、ダンプ出力にステートメントが残る可能性があり、ダンプファイルは異なるタイミングでリプレイできます。 ただし、SET @@GLOBAL.gtid_purged ステートメントの mysqldump に含まれる値には、ソース上の gtid_executed セット内のすべてのトランザクションの GTID(データベースの抑制された部分を変更したトランザクションや、部分ダンプに含まれていなかったサーバー上のその他のデータベースも含む) が含まれることに注意してください。 同じ GTID (たとえば、同じソースからの別の部分ダンプ、または重複するトランザクションを持つ別のソースからのダンプ) を含むレプリカ上の 2 番目または後続のダンプファイルをリプレイすると、2 番目のダンプファイル内の SET @@GLOBAL.gtid_purged ステートメントは失敗するため、ダンプ出力から削除する必要があります。
MySQL 8.0.17 からのソースの場合、SET @@GLOBAL.gtid_purged ステートメントを削除するかわりに、mysqldump の --set-gtid-purged オプションを COMMENTED に設定してステートメントを含め、コメントアウトして、ダンプファイルのロード時にアクションが実行されないようにできます。 同じソースから 2 つの部分ダンプを使用してレプリカをプロビジョニングし、2 つ目のダンプで設定された GTID が最初のダンプと同じである場合 (そのため、ダンプ間でソースで新しいトランザクションが実行されていない場合)、2 つ目のダンプファイルを出力するときに mysqldump の --set-gtid-purged オプションを OFF に設定して、ステートメントを省略できます。
次のプロビジョニング例では、SET @@GLOBAL.gtid_purged ステートメントをダンプ出力に残すことができず、ファイルから削除して手動で処理する必要があると想定しています。 また、プロビジョニングを開始する前に、GTID を含む必要なトランザクションがレプリカに存在しないことも前提としています。
-
db1という名前のデータベース (source1上) およびdb2という名前のデータベース (source2) のダンプファイルを作成するには、次のように mysqldump forsource1を実行します:mysqldump -u<user> -p<password> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db1 > dumpM1.sql次に、mysqldump for
source2を次のように実行します:mysqldump -u<user> -p<password> --single-transaction --triggers --routines --set-gtid-purged=ON --databases db2 > dumpM2.sql -
mysqldump が各ダンプファイルに追加した
gtid_purged値を記録します。 たとえば、MySQL 5.6 または 5.7 で作成されたダンプファイルの場合、次のような値を抽出できます:cat dumpM1.sql | grep GTID_PURGED | cut -f2 -d'=' | cut -f2 -d$'\'' cat dumpM2.sql | grep GTID_PURGED | cut -f2 -d'=' | cut -f2 -d$'\''フォーマットが変更された MySQL 8.0 から、次のような値を抽出できます:
cat dumpM1.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\'' cat dumpM2.sql | grep GTID_PURGED | perl -p0 -e 's#/\*.*?\*/##sg' | cut -f2 -d'=' | cut -f2 -d$'\''各ケースの結果は GTID セットである必要があります。次に例を示します:
source1: 2174B383-5441-11E8-B90A-C80AA9429562:1-1029 source2: 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695 -
SET @@GLOBAL.gtid_purgedステートメントを含む各ダンプファイルから行を削除します。 例:sed '/GTID_PURGED/d' dumpM1.sql > dumpM1_nopurge.sql sed '/GTID_PURGED/d' dumpM2.sql > dumpM2_nopurge.sql -
mysql クライアントを使用して、編集した各ダンプファイルをレプリカにインポートします。 例:
mysql -u<user> -p<password> < dumpM1_nopurge.sql mysql -u<user> -p<password> < dumpM2_nopurge.sql -
レプリカで、
RESET MASTERを発行して GTID 実行履歴をクリアします (前述のように、すべてのダンプファイルがインポートされており、GTID を含む必要なトランザクションがレプリカにないことを前提としています)。 次に、ステップ 2 で記録したように、SET @@GLOBAL.gtid_purgedステートメントを発行して、gtid_purged値をすべてのダンプファイルからのすべての GTID セットの和集合に設定します。 例:mysql> RESET MASTER; mysql> SET @@GLOBAL.gtid_purged = "2174B383-5441-11E8-B90A-C80AA9429562:1-1029, 224DA167-0C0C-11E8-8442-00059A3C7B00:1-2695";ダンプファイル内の GTID セット間に重複するトランザクションがあるか、または重複している可能性がある場合は、セクション17.1.3.8「GTID を操作するストアドファンクションの例」 で説明されているストアドファンクションを使用して、これを事前にチェックし、すべての GTID セットの結合を計算できます。