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

MySQL 5.6.9 でグローバルトランザクション識別子 (GTID) に基づいて MySQL Replication を使用するとき、さらにあとで新しいスレーブ (スケールアウトに使用でき、必要に応じてフェイルオーバー時にマスターに昇格される) をプロビジョニングするために、いくつかの技術があります。このセクションでは、次に示す 4 つの技術について説明します。

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

• データとトランザクションをスレーブにコピーする

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

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

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

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

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

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

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

データとトランザクションをスレーブにコピーする  再生を トランザクション履歴全体で行うには時間がかかることがあり、新しいレプリケーションスレーブをセットアップするときに大きなボトルネックになります。この要件を解消するために、マスターに含まれているデータセットのスナップショット、バイナリログ、およびグローバルトランザクション情報がスレーブにインポートされます。バイナリログが再生されたあとにレプリケーションを開始できるため、スレーブは残りのトランザクションに追い付くことができます。

この方法にはいくつかの種類があり、ここで示すように、データダンプとバイナリログからのトランザクションがスレーブに転送される方法に違いがあります。

データセット

トランザクション履歴

mysql クライアントを使用して、mysqldump で作成されたダンプファイルをインポートします。--master-data オプションを使用してバイナリロギング情報を取り込み、AUTO (デフォルト) または ON の --set-gtid-purged (MySQL 5.6.9 以降で使用可能) を使用して実行済みトランザクションに関する情報を取り込みます。スレーブでダンプをインポートするときは、--gtid-mode=ON にしてください。(Bug #14832472) スレーブを停止し、マスターのデータディレクトリの内容をスレーブのデータディレクトリにコピーしてから、スレーブを再起動します。

gtid_mode が ON でない場合、GTID モードを有効にした状態でサーバーを再起動します。 mysqlbinlog を --read-from-remote-server および --read-from-remote-master オプションで使用してバイナリログをインポートします。 マスターのバイナリログファイルをスレーブにコピーします。mysqlbinlog --read-from-remote-server --raw を使用して、スレーブからコピーを作成できます。これらは、次のいずれかの方法でスレーブに読み取ることができます。 スレーブの binlog.index ファイルを更新して、コピーされたログファイルをポイントします。次に、mysql クライアントで CHANGE MASTER TO ステートメントを実行して最初のログファイルをポイントし、START SLAVE を実行してそれらを読み取ります。 mysqlbinlog > file (--raw オプションなし) を使用して、mysql クライアントが処理できる SQL ファイルにバイナリログファイルをエクスポートします。

セクション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 'master-bin.00000N';

あとでマスターに昇格されたときにこのサーバーが不適切なトランザクションでレプリケーションストリームがあふれるのを回避するために、これを行うことをお勧めします。(FLUSH LOGS ステートメントは強制的に新しいバイナリログファイルを作成します。PURGE BINARY LOGS は空のトランザクションをパージしますが、その識別子を保持します。)

この方法は、本質的にはスナップショットであるけれども、あとでマスターになれるサーバーを作成します (そのバイナリログ履歴がレプリケーションストリームのそれに一致したとき、つまりマスターに追い付いたとき)。この結果は、残りのプロビジョニング方法を使用して得られる結果に実質的に似ています (次のいくつかの段落で説明します)。

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

注記

MySQL 5.6.9 より前は、gtid_purged を設定できませんでした。(Bug #14797808)

空のトランザクションを使用する方法と同様に、この方法は、機能的にはスナップショットであるけれども、あとでマスターになれるサーバーを作成します (そのバイナリログ履歴がレプリケーションマスターまたはグループのそれに一致したとき)。