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

17.4.8 フェイルオーバー中のソースの切替え

(MySQL 8.0.23 の)CHANGE REPLICATION SOURCE TO ステートメントまたは CHANGE MASTER TO ステートメント (MySQL 8.0.23 の前) を使用して、新しいソースに変更するようレプリカに指示できます。 レプリカは、ソース上のデータベースがレプリカ上のデータベースと互換性があるかどうかをチェックしません。単に、新しいソースバイナリログ内の指定された座標からイベントの読取りおよび実行を開始します。 フェイルオーバーの状況では、グループ内のすべてのサーバーが同じバイナリログファイルから同じイベントを実行するのが一般的であるため、イベントのソースを変更しても、変更を加えるときに注意することで、データベースの構造または完全性に影響を与えないはずです。

レプリカは、バイナリロギングを有効にして実行するようにしてください (--log-bin オプション)。これはデフォルトです。 GTID をレプリケーションに使用しない場合は、レプリカも --log-slave-updates=OFF で実行する必要があります (レプリカ更新のロギングがデフォルトです)。 このように、レプリカはレプリカ mysqld を再起動せずにソースになる準備ができています。 図17.4「レプリケーションを使用する冗長性、初期構造」で示す構造を想定してください。

図 17.4 レプリケーションを使用する冗長性、初期構造

この図では、MySQL Source はソースデータベースを保持し、MySQL Replica ホストはレプリカであり、Web Client マシンはデータベースの読取りおよび書込みを発行しています。 読取りのみを発行する (通常はレプリカに接続される) Web クライアントは、障害発生時に新しいサーバーに切り替える必要がないため、表示されません。 読み取り/書き込みスケールアウトレプリケーション構造の詳細例については、セクション17.4.5「スケールアウトのためにレプリケーションを使用する」を参照してください。

各 MySQL レプリカ (Replica 1、Replica 2 および Replica 3) は、バイナリロギングを有効にして --log-slave-updates=OFF で実行されるレプリカです。 --log-slave-updates=OFF が指定されている場合、ソースからレプリカによって受信された更新はバイナリログに記録されないため、各レプリカのバイナリログは最初は空になります。 なんらかの理由で MySQL Source が使用できなくなった場合は、いずれかのレプリカを選択して新しいソースにすることができます。 たとえば、Replica 1 を選択した場合、すべての Web Clients は Replica 1 にリダイレクトされ、バイナリログに更新が書き込まれます。 その後、Replica 2 および Replica 3 は Replica 1 からレプリケートする必要があります。

--log-slave-updates=OFF でレプリカを実行する理由は、いずれかのレプリカが新しいソースになった場合に、レプリカが更新を 2 回受信しないようにするためです。 Replica 1 で --log-slave-updates が有効になっている場合 (デフォルト)、Source から受信した更新が独自のバイナリログに書き込まれます。 つまり、Replica 2 が Source から Replica 1 にソースとして変更されると、Source からすでに受信した Replica 1 から更新を受信する可能性があります。

すべてのレプリカがリレーログ内のすべてのステートメントを処理したことを確認します。 各レプリカで STOP REPLICA | SLAVE IO_THREAD を発行し、Has read all relay log が表示されるまで SHOW PROCESSLIST の出力を確認します。 これがすべてのレプリカに当てはまる場合は、新しい設定に再構成できます。 ソースになるように昇格されるレプリカ Replica 1 で、STOP REPLICA | SLAVE および RESET MASTER を発行します。

他のレプリカ Replica 2 および Replica 3 では、STOP REPLICA | SLAVE および CHANGE REPLICATION SOURCE TO SOURCE_HOST='Replica1'または CHANGE MASTER TO MASTER_HOST='Replica1'を使用します ('Replica1'は Replica 1 の実際のホスト名を表します)。 CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO を使用するには、Replica 2 または Replica 3 (user, password, port) から Replica 1 に接続する方法に関するすべての情報を追加します。 このシナリオでは、最初のバイナリログファイルと位置 4 がデフォルトであるため、ステートメントを発行するときに、読み取る Replica 1 バイナリログファイルまたはログ位置の名前を指定する必要はありません。 最後に、Replica 2 および Replica 3 で START REPLICA | SLAVE を実行します。

新しいレプリケーションの設定が完了したら、そのステートメントを Replica 1 に送るように各 Web Client に指示する必要があります。 この時点から、Web Client から Replica 1 に送信されたすべての update ステートメントが Replica 1 のバイナリログに書き込まれ、Source の停止後に Replica 1 に送信されたすべての update ステートメントが含まれます。

結果のサーバー構造を図17.5「ソース障害後のレプリケーションを使用した冗長性」に示します。

図 17.5 ソース障害後のレプリケーションを使用した冗長性

Source が再び使用可能になったら、Replica 1 のレプリカにする必要があります。 これを行うには、Replica 2 および Replica 3 で発行されたのと同じ CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO ステートメントを Source で発行します。 その後、Source は Replica 1 のレプリカになり、オフライン中に失われた Web Client 書込みを取得します。

Source を再度ソースにするには、Replica 1 を使用できず、Source を新しいソースにする場合と同様に、前述の手順を使用します。 この手順では、Source の Replica 1、Replica 2 および Replica 3 レプリカを作成する前に、必ず Replica 1 で RESET MASTER を実行してください。 これを実行できない場合、レプリカは、Source が使用できなくなった時点より前の Web Client アプリケーションから失効した書込みを取得する可能性があります。

レプリカが同じソースを共有している場合でも、レプリカ間で同期が行われないため、一部のレプリカが他のレプリカよりかなり進んでいる可能性があることに注意してください。 これは場合によっては、前の例で説明した手順が期待どおりに機能しない可能性があることを意味します。 ただし、実際には、すべてのレプリカのリレーログを比較的近いものにする必要があります。

ソースの場所についてアプリケーションに通知する方法の 1 つは、ソースサーバーの動的 DNS エントリを保持することです。 bind で nsupdate を使用することで DNS を動的に更新できます。