MySQL はどのようにしてマスターとスレーブの同期を実現するのでしょうか?

マスタースレーブ同期 (マスタースレーブレプリケーションとも呼ばれる) は、マスタースレーブデータの一貫性を保証する、MySQL が提供する高可用性ソリューションです。

実稼働環境では、データベース サービスの障害など、制御できない要因が多数存在します。アプリケーションの高可用性を確保するには、データベースも高可用性である必要があります。

したがって、実稼働環境では、マスター スレーブ同期が使用されます。アプリケーションの規模が小さい場合は、通常、マスター 1 つとバックアップ 1 つが使用されます。

データベース サービスに障害が発生したときにスタンバイ データベースにすばやく切り替えてアプリケーションが使用できなくなることを回避できることに加えて、マスター スレーブ同期を使用すると、次の利点があります。

データベースの読み取り同時実行性を向上させます。ほとんどのアプリケーションでは、書き込みよりも読み取りが多く必要になります。マスター スレーブ同期ソリューションを使用します。使用規模が拡大した場合は、スレーブ データベースを拡張して読み取り機能を向上させることができます。

バックアップ、マスタースレーブ同期により、リアルタイムで完全なバックアップ データベースを取得できます。

迅速なリカバリ: プライマリ データベースでエラーが発生した場合 (テーブルの誤った削除など)、スタンバイ データベースを通じてデータを迅速に復元できます。データ復旧速度に対する許容度が低い大規模アプリケーションの場合、プライマリ データベースから 30 分離れたデータ スナップショットを使用してバックアップ データベースを構成できます。プライマリ データベースからテーブルが誤って削除された場合、最大 30 分の待機時間で、バックアップ データベースと binlog を通じて迅速に復元できます。

マスター スレーブ同期とは何か、そしてその利点について説明したので、次にマスター スレーブ同期がどのように実現されるかを理解しましょう。

マスタースレーブ同期の実装原理

まず、マスターとスレーブの同期の原理を理解しましょう。以下では、更新ステートメントを使用して、マスター データベースとスレーブ データベースがどのように同期されるかを紹介します。

上の図は、ノード A で実行され、その後ノード B に同期される更新ステートメントの完全なフローチャートです。具体的な手順は次のとおりです。

1. マスター データベースは、クライアントから送信された更新ステートメントを受信し、内部トランザクション ロジックを実行し、同時に binlog を書き込みます。
2. スタンバイ データベースは、change master コマンドを使用して、マスター データベースの IP、ポート、ユーザー名、パスワード、および binlog の要求を開始する位置を設定します。この場所にはファイル名とオフセットが含まれます。
3. スレーブ データベースで start slave コマンドを実行して、io_thread と sql_thread の 2 つのスレッドを開始します。io_thread はホストへの接続を担当します。
4. マスター データベースはユーザー名とパスワードを検証した後、受信した場所に従って binlog を読み取り、スレーブ データベースに送信します。
5. スタンバイ データベースは、バイナリ ログを受信すると、それをローカル ファイル (リレー ログ、転送ファイル) に書き込みます。
6. スタンバイ データベースは転送ファイルを読み取り、コマンドを解析して実行します。
   

マスター スレーブ同期の動作原理は、実際には完全バックアップとバイナリ ログ バックアップの復元です。違いは、このバイナリ ログの復元操作は基本的にリアルタイムであることです。

スタンバイ データベースは、同期を実現するために 2 つのスレッドを使用します。

• 1 つは I/O スレッドで、メイン ライブラリのバイナリ ログを読み取り、リレー ログとして保存する役割を担います。
• 1 つは、リレー ログの実行を担当する SQL スレッドです。

上記のプロセスから、マスタースレーブ同期の鍵はbinlogであることがわかります。

2つの一般的なアクティブ/スタンバイ切り替えプロセス

MS構造

MS 構造には 2 つのノードがあり、1 つはプライマリ データベースとして機能し、もう 1 つはバックアップ データベースとして機能します。2 つのノードは役割を交換することはできません。

状態 1 では、クライアントの読み取りと書き込みはノード A に直接アクセスし、ノード B は A のバックアップ データベースです。A のすべての更新を同期し、ローカルで実行するだけです。これにより、ノード B とノード A のデータは同じままになります。

切り替えが必要な場合は、状態 2 に切り替えます。このとき、クライアントはノード B に対して読み取りと書き込みを行い、ノード A はノード B のバックアップ データベースとなります。

ダブルM構造

デュアル M 構造、2 つのノード、1 つはプライマリ データベースとして、もう 1 つはバックアップ データベースとして機能し、2 つのノードが役割を交換できます。

前の MS 構造図と比較すると、デュアル M 構造と MS 構造の唯一の違いは、もう 1 行あること、つまりノード A とノード B が常に相互にマスター スレーブ関係にあることであることがわかります。この方法では、切り替え時にマスターとスレーブの関係を変更する必要はありません。

二重M構造の循環コピー問題

実際の生産現場では、ほとんどの場合、ダブルM構造が採用されています。しかし、ダブルM構造にはまだ解決すべき問題が残っています。

ノード A でビジネス ロジックが更新されると、バイナリ ログが生成され、ノード B に同期されます。ノード B が同期された後、binlog も生成されます。 (log_slave_updates はオンに設定されており、スタンバイ データベースでも binlogs が生成されることを示します)。

ノード A がノード B のバックアップ データベースでもある場合、ノード B の binlog もノード A に送信され、循環レプリケーションが発生します。

解決：

1. ノードのサーバー ID を設定します。異なる必要があります。そうでない場合、マスター スレーブ構造として設定することはできません。
2. バックアップ データベースが binlog を受信して​​再生すると、元のレコードと同じサーバー ID が記録されます。つまり、そのサーバー ID は、それを生成したユーザーのものになります。
3. binlog を受信すると、各ノードはサーバー ID を判別し、それが自身のものである場合はそれを破棄します。

解決後のプロセス:

1. ビジネス ロジックはノード A で更新を実行し、ノード A のサーバー ID を使用して binlog を生成します。
2. ノード B はノード A から送信された binlog を受信して​​実行を完了すると、ノード A のサーバー ID を持つ binlog を生成します。
3. ノード A は binlog を受信し、それが自分のものであることがわかったら、それを破棄します。ここで無限ループは解消されます。

上記は、MySQL がマスタースレーブ同期を実現する方法の詳細です。MySQL マスタースレーブ同期の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。