5.3.6 フェイルオーバでのマスタ切り替え

5.3.6. フェイルオーバでのマスタ切り替え

障害が発生した場合にマスタとスレーブ間でのフェイルオーバに対応する正式なソリューションは現在の段階ではありません。現在利用可能な機能内では、マスタとスレーブ (または複数のスレーブ) をセットアップし、状況を把握するためにマスタを監視するスクリプトを作成することが挙げられます。そのときには、アプリケーションとスレーブに障害を認識した場合にマスタを変更するよう指示します。

CHANGE MASTER TO ステートメントを使用して、いつでもスレーブにマスタを変えるように指示することが重要です。スレーブはマスタのデータベースがスレーブとの互換性を保持しているかどうかを確認することができないため、新しいマスタが指定するログと場所からイベントを実行し始めます。フェイルオーバの状況で、グループ内すべてのサーバが同一のバイナリログからの同一のイベントを実行しています。そのため、イベント元の変更がデータベースストラクチャまたは整合性に影響することのないように慎重に扱う必要があります。

スレーブを --log-bin はあるけれども --log-slave-updates はないという組み合わせで実行します。この方法では、スレーブで RESET MASTER と CHANGE MASTER TO を実行し、別のスレーブで STOP SLAVE を実行すると同時に、スレーブがマスタになる準備ができます。図 5.9. 「レプリケーションを活用した冗長性、初期ストラクチャ」のストラクチャで例示を参照してください。

図 5.9. レプリケーションを活用した冗長性、初期ストラクチャ

この図では、MySQL Master にはマスタデータベースがあり、MySQL Slave のコンピュータはレプリケーションスレーブ、そして Web Client マシンは読み書き込みをするデータベースという関係になります。通常スレーブに接続していて読み込みだけを行うウェブクライアントは、障害イベントで新しいサーバへは切り替わらないため、図には含まれていません。読み書き込みのスケールアウトソリューションストラクチャに関しては、項5.3.3. 「スケールアウトのレプリケーション」を参照してください。

MySQL Slave のそれぞれ (Slave 1、Slave 2、Slave 3) は、 --log-slave-updates を伴わずに、--log-bin だけで実行しているスレーブです。--log-slave-updates の指定がなければマスタからスレーブが受信したアップデートがバイナリログに記録されないため、それぞれのスレーブのバイナリログは最初から空です。何らかの原因により MySQL Master が利用不可になる場合、複数あるスレーブの中から新しいマスタを選ぶことができます。たとえば、Slave 1 を選択する場合、すべての Web Clients を Slave 1 にリダイレクトして、そこのバイナリログにアップデートを記録します。つまり、Slave 2 と Slave 3 は Slave 1 から複製することになります。

--log-slave-updates なしで実行するという理由には、複数のスレーブの中から一つが新たなマスタに切り替わるときに、アップデートを 2 度受信しないようにするためです。たとえば、Slave 1 は --log-slave-updates するようになると、Master から受信するアップデートを自分のバイナリログに書き込みます。Slave 2 が Master から Slave 1 に切り替わった場合は、Master からアップデートをすでに受信しているにも関わらず、Slave 1 から再度、アップデートを受信するという結果になります。

すべてのスレーブがリレーログ内のクエリを処理したかどうかを確認してください。それぞれのスレーブでは、STOP SLAVE IO_THREAD を発行して、Has read all relay log を確認できまるまで、SHOW PROCESSLIST の出力をチェックします。すべてのスレーブでこれが確認できたら、これらを新たな設定として構成できます。マスタに昇格した Slave 1 のスレーブでは、STOP SLAVE と RESET MASTER を発行します。

別のスレーブ Slave 2 と Slave 3 では、STOP SLAVE とCHANGE MASTER TO MASTER_HOST='Slave1' を使います。 ('Slave 1' が、Slave1 の実際のホスト名を表示する場合).CHANGE MASTER には、Slave 2 または Slave 3 から Slave 1 へのどのようにするかに関するすべての情報を付加します。(user、password、port など) CHANGE MASTER では、Slave 1 のバイナリログ名や読み込み先のバイナリログ位置を指定する必要はありません。CHANGE MASTER のデフォルトでは、一番初めのバイナリログ、そして位置は 4 です。そして最後に、Slave 2 と Slave 3 で START SLAVE を使用します。

新たなレプリケーションを整えた後に、Web Client が Slave 1 へクエリを送信するよう指示します。この時点から、Web Client が Slave 1 へ送信したすべてのアップデートクエリが Slave 1 のバイナリログに書き込まれ、すでに Master は機能していないため、Slave 1 へ送信したすべてのアップデートクエリが含まれることになります。

サーバストラクチャの結果は図 5.10. 「レプリケーションを活用した冗長性、マスタ障害後」に示す通りです。

図 5.10. レプリケーションを活用した冗長性、マスタ障害後

Master マスタの再稼動するときは、Slave 2 と Slave 3 に発行した通りに、同様の CHANGE MASTER を発行してください。これにより、Master はスレーブの S1 になり、ダウン後に実行された Web Client の書き込みをすべてピックアップします。

たとえば、マスタが最もパワフルなマシンであるなど物理的な理由で、Master をマスタへ戻すには、Slave 1 を利用不可の状態、Master が新たなマスタになる、というようにそれぞれの立場を逆にしてこの手順を繰り返します。この手順では、Slave 1、Slave 2 そして Slave 3 を Master のスレーブにする前に、Master に RESET MASTER を実行することを忘れないでください。これをしないと、Master が動かなくなる前の古い Web Client 書き込みをピックアップすることになります。

複数スレーブとマスタは同期していません。スレーブのいくつかは他のスレーブよりも前に出ていることがあります。つまり、前述の例で示したコンセプトが機能しない可能性があるということです。しかし、実情では、複数スレーブのリレーログがマスタからそれほど遅れをとらないので、この方法が適用できるとの考えに基づいています。そのため、この方法が確証できるものではないことに留意してください。

動的な DNS エントリをマスタに持たせると、マスタの位置に応じてアプリケーションを調節することをお勧めします。bind で、 DNS を動的に更新するnsupdate を使います。