このページは機械翻訳したものです。

17.1.3.5 フェイルオーバーおよびスケールアウトでの GTID の使用

MySQL レプリケーションをグローバルトランザクション識別子 (GTID) とともに使用して新しいレプリカをプロビジョニングする場合、スケールアウトに使用し、フェイルオーバーのために必要に応じてソースに昇格する方法が多数あります。 このセクションでは、次の手法について説明します:

• 単純なレプリケーション

• レプリカへのデータおよびトランザクションのコピー

• 空のトランザクションの注入

• gtid_purged によるトランザクションの除外

• GTID モードの複製の復元

グローバルトランザクション識別子は、特にレプリケーションデータフローおよびフェイルオーバーアクティビティーの一般管理を簡易化するために、MySQL Replication に追加されました。 各識別子は、全体でトランザクションを構成するバイナリログイベントセットを一意に識別します。 GTID はデータベースに変更を適用する際に重要な役割を果たします。サーバーは、以前に処理済みと認識している識別子のトランザクションを自動的にスキップします。 この動作は、自動レプリケーションポジショニングおよび正確なフェイルオーバーのために重要です。

トランザクションを構成する識別子とイベントセットとの間のマッピングは、バイナリログで取得されます。 このことは、別の既存のサーバーからのデータで新しいサーバーをプロビジョニングする際に、いくつかの課題を提起します。 新しいサーバーに設定された識別子を再現するには、古いサーバーから新しいサーバーに識別子をコピーし、識別子と実際のイベントの関係を保持する必要があります。 これは、フェイルオーバーまたはスイッチオーバー時に新しいソースになる候補としてすぐに使用可能なレプリカをリストアするために必要です。

単純なレプリケーション.  新しいサーバーですべての識別子とトランザクションを再現する最も簡単な方法は、新しいサーバーを実行履歴全体を持つソースのレプリカにし、両方のサーバーでグローバルトランザクション識別子を有効にすることです。 詳細については、セクション17.1.3.4「GTID を使用したレプリケーションのセットアップ」を参照してください。

レプリケーションが開始されると、新しいサーバーはバイナリログ全体をソースからコピーするため、すべての GTID に関するすべての情報を取得します。

この方法は単純で効果的ですが、レプリカがソースからバイナリログを読み取る必要があります。新しいレプリカがソースに追いつくまでに比較的長い時間がかかる場合があるため、この方法は高速フェイルオーバーやバックアップからの復元には適していません。 このセクションでは、バイナリログファイルを新しいサーバーにコピーして、ソースからすべての実行履歴をフェッチしない方法について説明します。

レプリカへのデータおよびトランザクションのコピー.  ソースサーバーが以前に多数のトランザクションを処理している場合、トランザクション履歴全体の実行に時間がかかることがあり、これは新しいレプリカの設定時の大きなボトルネックを表している可能性があります。 この要件をなくすために、データセットのスナップショット、バイナリログおよびソースサーバーに含まれるグローバルトランザクション情報を新しいレプリカにインポートできます。 スナップショットが作成されるサーバーは、ソースまたはそのレプリカのいずれかになりますが、データをコピーする前に、サーバーが必要なすべてのトランザクションを処理していることを確認する必要があります。

この方法にはいくつかのバリアントがあります。違いは、データダンプとバイナリログからのトランザクションがレプリカに転送される方法です。次に概要を示します:

データセット

1. ソースサーバーで mysqldump を使用してダンプファイルを作成します。 バイナリロギング情報を含む CHANGE REPLICATION SOURCE TO|CHANGE MASTER TO ステートメントを含めるように、mysqldump オプション --master-data (デフォルト値は 1) を設定します。 実行されたトランザクションに関する情報をダンプに含めるには、--set-gtid-purged オプションを AUTO (デフォルト) または ON に設定します。 次に、mysql クライアントを使用して、ダンプファイルをターゲットサーバーにインポートします。

2. または、RAW データファイルを使用してソースサーバーのデータスナップショットを作成し、セクション17.1.2.5「データスナップショットの方法の選択」 の手順に従ってこれらのファイルをターゲットサーバーにコピーします。 InnoDB テーブルを使用する場合、MySQL Enterprise Backup コンポーネントから mysqlbackup コマンドを使用して、一貫性のあるスナップショットを作成できます。 このコマンドは、レプリカで使用されるスナップショットに対応するログ名とオフセットを記録します。 MySQL Enterprise Backup は MySQL Enterprise サブスクリプションの一部として同梱される製品です。 詳細は、セクション30.2「MySQL Enterprise Backup の概要」を参照してください。

3. または、ソースサーバーとターゲットサーバーの両方を停止し、ソースデータディレクトリの内容を新しいレプリカデータディレクトリにコピーしてから、レプリカを再起動します。 この方法を使用する場合は、GTID ベースのレプリケーション、つまり gtid_mode=ON でレプリカを構成する必要があります。 この方法の手順および重要な情報については、セクション17.1.2.8「レプリケーション環境へのレプリカの追加」 を参照してください。

トランザクション履歴

ソースサーバーのバイナリログに完全なトランザクション履歴がある (GTID セット@@GLOBAL.gtid_purged が空である) 場合は、次の方法を使用できます。

1. --read-from-remote-server および --read-from-remote-master オプションを指定して、mysqlbinlog を使用してバイナリログをソースサーバーから新しいレプリカにインポートします。

2. または、ソースサーバーのバイナリログファイルをレプリカにコピーします。 --read-from-remote-server および --raw オプションを指定した mysqlbinlog を使用して、レプリカからコピーを作成できます。 これらは、mysqlbinlog > file (--raw オプションなし) を使用してバイナリログファイルを SQL ファイルにエクスポートし、これらのファイルを mysql クライアントに渡して処理することでレプリカに読み取ることができます。 すべてのバイナリログファイルが、複数の接続ではなく単一の mysql プロセスを使用して処理されていることを確認します。 例:

   shell> mysqlbinlog copied-binlog.000001 copied-binlog.000002 | mysql -u root -p

   詳細は、セクション4.6.8.3「バイナリログファイルのバックアップのための mysqlbinlog の使用」を参照してください。

この方法には、ほとんどすぐに新しいサーバーを使用できるという利点があります。スナップショットまたはダンプファイルのリプレイ中にコミットされたトランザクションのみ、既存のソースから取得する必要があります。 つまり、レプリカの可用性は瞬時ではありませんが、レプリカがこれらの少数の残りのトランザクションに追いつくには比較的短い時間しか必要ありません。

通常、バイナリログをターゲットサーバーに事前にコピーする方が、ソースからリアルタイムでトランザクション実行履歴全体を読み取るより高速です。 ただし、サイズやその他の考慮事項により、必要なときにこれらのファイルをターゲットに移動することが常に実現できるとはかぎらない場合があります。 このセクションで説明する新しいレプリカをプロビジョニングするための残りの 2 つの方法では、他の方法を使用してトランザクションに関する情報を新しいレプリカに転送します。

空のトランザクションの注入.  ソースグローバル gtid_executed 変数には、ソースで実行されたすべてのトランザクションのセットが含まれます。 新しいサーバーをプロビジョニングするためにスナップショットを作成するときにバイナリログをコピーする代わりに、スナップショットが作成されたサーバーで gtid_executed の内容に注目できます。 新しいサーバーをレプリケーションチェーンに追加する前に、次のように、ソース gtid_executed に含まれるトランザクション識別子ごとに新しいサーバーで空のトランザクションをコミットします:

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';

BEGIN;
COMMIT;

SET GTID_NEXT='AUTOMATIC';

空のトランザクションを使用してすべてのトランザクション識別子をこの方法で回復したら、次に示すようにレプリカバイナリログをフラッシュしてパージする必要があります。ここで、N は現在のバイナリログファイル名のゼロ以外の接尾辞です:

FLUSH LOGS;
PURGE BINARY LOGS TO 'source-bin.00000N';

後でソースに昇格された場合に、このサーバーが false トランザクションでレプリケーションストリームをフラッディングしないようにするには、これを行うようにしてください。 (FLUSH LOGS ステートメントは強制的に新しいバイナリログファイルを作成します。PURGE BINARY LOGS は空のトランザクションをパージしますが、その識別子を保持します。)

このメソッドは、基本的にスナップショットであるサーバーを作成しますが、バイナリログ履歴がレプリケーションストリームのバイナリログ履歴と収束する (つまり、ソースとキャッチアップする) と同時にソースになることができます。 この結果は、残りのプロビジョニング方法を使用して得られる結果に実質的に似ています (次のいくつかの段落で説明します)。

gtid_purged によるトランザクションの除外.  ソースグローバル gtid_purged 変数には、ソースバイナリログからパージされたすべてのトランザクションのセットが含まれます。 前に説明した方法と同様に (空のトランザクションの注入を参照してください)、スナップショットが作成されたサーバーで (バイナリログを新しいサーバーにコピーする代わりに) gtid_executed の値を記録できます。 前述の方法とは異なり、空のトランザクションをコミットする (または PURGE BINARY LOGS を発行する) 必要はありません。かわりに、バックアップまたはスナップショットが作成されたサーバー上の gtid_executed の値に基づいて、レプリカに gtid_purged を直接設定できます。

空のトランザクションを使用する方法と同様に、この方法では、機能的にスナップショットであるサーバーが作成されますが、バイナリログ履歴がソースおよびほかのレプリカのものと収束すると、時間内にソースになることができます。

GTID モードの複製の復元.  エラーが発生した GTID ベースのレプリケーション設定でレプリカをリストアする場合、イベントに GTID がないため、空のトランザクションをインジェクトしても問題が解決しないことがあります。

mysqlbinlog を使用して、次のトランザクション (イベント後の次のログファイルの最初のトランザクション) を検索します。 SET @@SESSION.gtid_next が含まれていることを確認して、そのトランザクションの COMMIT までのすべてをコピーします。 行ベースレプリケーションを使用していない場合でも、コマンドラインクライアントでバイナリログ行イベントを実行できます。

レプリカを停止し、コピーしたトランザクションを実行します。 mysqlbinlog 出力ではデリミタが/*!*/;に設定されるため、再度設定します:

mysql> DELIMITER ;

正しい位置からレプリケーションを自動的に再開します:

mysql> SET GTID_NEXT=automatic;
mysql> RESET SLAVE;
mysql> START SLAVE;
Or from MySQL 8.0.22:
mysql> SET GTID_NEXT=automatic;
mysql> RESET REPLICA;
mysql> START REPLICA;