MySQL (6) マスター/スレーブ レプリケーション

MySQL シリーズの記事

MySQL (1) 基本構造、SQL 文の操作、
MySQL の試行 (2) インデックスの原則と最適化
MySQL (3) SQL の最適化、バッファプール、変更バッファ
MySQL (4) トランザクションの原則と分析
MySQL (5) キャッシュ戦略
MySQL (6)マスター/スレーブ レプリケーションデータベース
の 3 つのパラダイム

---

序文

MySQL には独自のマスタ/スレーブ同期機構があり、MySQL がインストールされたデバイスは関連パラメータを設定することでマスタ/スレーブ データベースの同期機能を実現できます。

MySQL マスター/スレーブをセットアップする利点は何ですか?

• クラスタリングの利点と同様に、可用性、パフォーマンス、耐障害性などが向上します。
• 読み取りと書き込みの分離
• 負荷分散

マスター/スレーブはどのモードを使用しますか?

通常は 1 つのマスターと 1 つのスレーブ、または 1 つのマスターと多数のスレーブです。

マスター サーバーは書き込みのみを担当し、スレーブ サーバーは読み取りのみを担当するため、効率が向上し、負荷が軽減されます。

マスター/スレーブ レプリケーションの原理

1. メイン データベースが更新されます。つまり、更新、挿入、削除の操作を実行すると、メイン データベースは io-thread を介して操作ロジックを binlog に書き込みます。
2. スレーブ ライブラリはメイン ライブラリからのバイナリ ログの読み取りを要求し、メイン ライブラリはログ ダンプ スレッドを通じてバイナリ ライブラリにバイナリ ログの内容を送信します。
3. スレーブ ライブラリは、更新された binlog を io-thread スレッドを通じてスレーブ ライブラリのローカル リレー ログ (リレー ログ) に書き込みます。
4. スレーブ ライブラリは最終的に SQL スレッドを通じてリレー ログを読み取り、内容を解析して特定の操作を行い、最終的にマスターとスレーブのデータが一貫していることを確認します。

データ同期方法

同期プロセス中に渡されるバイナリログ データには、ステートメント データと行データの 2 種類があります。

ステートメントのレプリケーション

つまり、マスター/スレーブ レプリケーション プロセス全体で、データベース データの代わりに操作レコードが送信されます。そのため、最終的にデータ結果をディスクに同期するには、データベースに複雑化してからデータベースから操作コマンドを実行する必要があります。

アドバンテージ：

• これにより、データ送信量とレプリケーション遅延が削減され、マスター/スレーブ レプリケーションの効率が向上します (データを転送するにはライブラリ全体を転送する必要があるため)。
• テーブルに 100 万レコードがあり、1 つの SQL ですべてのテーブルが更新されると仮定すると、ステートメントベースのレプリケーションでは 1 つの SQL を送信するだけで済みますが、行ベースのレプリケーションでは 100 万の更新されたレコードを送信する必要があります。

欠点:

• 正しくコピーできない旨の警告が出る場合があります
• Insert ... select ステートメントは、多数の行レベルのロック テーブルを実行します。
• Update ステートメントは、テーブル全体をスキャンするために多数の行レベルのテーブル ロックを実行します。

mysql5.6 ではステートメント レプリケーション モードがデフォルトで使用されます。

行データのコピー

つまり、実際のライブラリ内のデータの各行を更新します。これにより、レプリケーションに比較的大きな負荷がかかり、ログによって占有されるスペースが大きくなり、大量の送信帯域幅が必要になります。ただし、この方法はステートメントベースのレプリケーションよりも正確です。
アドバンテージ：

• クエリ プランは必要ありません。

• どのようなステートメントが実行されているのかわかりません。

• たとえば、ユーザーの合計ポイントを更新するステートメントでは、ユーザーのすべてのポイントをカウントし、それらをユーザー テーブルに書き込む必要があります。ステートメントレプリケーションに基づいている場合、スレーブデータベースはユーザーのポイントを再度カウントする必要がありますが、行レプリケーションに基づいている場合、ユーザーポイントをカウントせずにレコードが直接更新されます。

欠点:

• ログが膨大になる

同期モード

MySQL は、非同期レプリケーション、同期レプリケーション、および半同期レプリケーションをサポートします。

非同期レプリケーション

このモードでは、マスター ノードはスレーブ ノードにデータを積極的にプッシュしません。マスター ライブラリは、クライアントによって送信されたトランザクションの実行後、すぐに結果をクライアントに返します。スレーブ ライブラリがそれを受信して​​処理したかどうかは気にしません。 。

このようにしてしまうと、マスターノードがクラッシュすると、その時点でマスターノード上で投入されたトランザクションが不完全なデータとしてスレーブノードに送信されない可能性があります。

同期レプリケーション

MySQL クラスターにおける独自のレプリケーション方法。

マスター データベースがトランザクションを実行すると、すべてのスレーブ データベースがトランザクションをコピーし、正常に実行されてから、クライアントに成功メッセージが返されます。

成功情報を返す前に、すべてのスレーブ ライブラリがトランザクションを実行するのを待つ必要があるため、完全同期レプリケーションのパフォーマンスは必然的に重大な影響を受けます。

半同期レプリケーション

非同期レプリケーションに基づいて、マスター ライブラリ上のトランザクションが送信される前に、少なくとも 1 つのスレーブ ライブラリがトランザクションを受信して​​記録していることが保証されます。
非同期レプリケーションと完全同期レプリケーションの間では、マスター ライブラリは、クライアントによって送信されたトランザクションの実行後すぐにクライアントに戻りませんが、少なくとも 1 つのスレーブ ライブラリが受信してリレー ログに書き込むのを待ってから、成功情報をクライアントに返します。 end (メイン ライブラリの Binlog が少なくとも 1 つのスレーブ ノードに転送されていることを確認することしかできません)。それ以外の場合は、タイムアウト期間まで待ってから送信する前に非同期モードに切り替える必要があります。

準同期レプリケーションは、非同期レプリケーションと比較してデータのセキュリティが向上し、データをスレーブ データベースにある程度正常にバックアップできますが、同時にある程度の遅延も発生しますが、その遅延は非同期レプリケーションよりも低くなります。最も遅延が少ない完全同期モードの遅延は、TCP/IP の 1 往復にかかる時間です。したがって、半同期レプリケーションは、低遅延ネットワークで使用するのが最適です。

詳細については、「MySQL マスター/スレーブ レプリケーションの
原則」 「MySQL マスター/スレーブ同期の構成(レプリケーション)」を参照してください。