MySQL マスタースレーブレプリケーションのいくつかのレプリケーション方法の概要

非同期レプリケーション

MySQL レプリケーションは、デフォルトでは非同期です。マスター スレーブ レプリケーションには、少なくとも 2 つの MYSQL サービスが必要です。これらの MySQL サービスは、異なるサーバーまたは同じサーバーに分散できます。

MySQL マスター/スレーブ非同期レプリケーションは、最も一般的なレプリケーション シナリオです。データの整合性は、マスター データベースの BINLOG が失われないことに依存します。マスター データベースの BINLOG が失われない限り、マスター データベースがクラッシュした場合でも、失われたデータを BINLOG を介してスレーブ データベースに手動で同期できます。

注: マスター データベースがダウンした場合、DBA は mysqlbinlog ツールを使用してマスター データベースの binlog に手動でアクセスし、不足しているログを抽出してスレーブ データベースに同期できます。また、高可用性 MHA アーキテクチャを構成して不足しているデータを自動的に抽出してスレーブ データベースを補完したり、グローバル トランザクション ID (GTID) を有効にして不足している binlog をスレーブ データベースに自動的に抽出したりすることもできます。

MySQL はトランザクション (または SQL ステートメント) を BINLOG に記録します。つまり、トランザクションをサポートするエンジン (InnoDB など) の場合は、各トランザクションがコミットされるときに BINLOG を書き込む必要があり、トランザクションをサポートしないエンジン (MyISAM など) の場合は、各 SQL ステートメントが実行されるときに BINLOG が必要になります。 Binlog のセキュリティを確保するために、MySQL では、BINLOG をディスクにフラッシュする頻度を制御する sync_binlog パラメータが導入されています。

'sync_binlog' のような変数を表示します。 

• デフォルトでは、sync_binlog=1 は、トランザクションがコミットされる前に、MySQL が BINLOG をディスクにフラッシュする必要があることを意味します。このようにすると、データベース ホストのオペレーティング システムがクラッシュしたり、ホストの電源が突然切れたりしても、システムは準備状態にあるトランザクションをほとんど失うことはありません。sync_binlog=1 を設定して、データのセキュリティを最大限に確保します。
• sync_binlog=0 は、MySQL が binlog の更新を制御せず、ファイル システム自体がファイル キャッシュの更新を制御することを意味します。
• sync_binlog=N、N が 0 または 1 でない場合、更新方法は sync_binlog=1 と同様ですが、更新頻度が N 個の binlog 送信グループの後に拡張される点が異なります。
  

上記は従来の非同期レプリケーションです。MySQL 5.7 の並列レプリケーション技術 (マルチスレッド レプリケーションとも呼ばれます) が登場する前は、最も批判されていた問題は効率性でした。スレーブのレイテンシは慢性的な問題でした。スキーマ レベルの並列レプリケーションは以前から登場していましたが、実際の効果は良くありませんでした。

マルチスレッドレプリケーション

MySQL 5.7 では、マスターと同じスキーマのデータが変更されたときにスレーブが同時にデータを適用できない問題を解決する新しいマルチスレッド レプリケーション テクノロジが導入されました。また、binlog グループ送信の利点を最大限に活用し、スレーブがリレー ログを同時に適用できることを保証します。

MySQL 8.0では、マルチスレッドレプリケーションの技術的なアップデートが行われ、writesetの概念が導入されました。以前のバージョンでは、マスターデータベースの同じセッションが複数の異なる関連オブジェクトのトランザクションを順番に実行する場合、たとえば、最初にUpdate Aテーブルデータが実行され、次にUpdate Bテーブルデータが実行されました。BINLOGがスレーブデータベースにコピーされた後、これら2つのトランザクションを並行して実行することはできませんでした。writesetの登場により、この制限が解消されました。

強化された準同期レプリケーション

上記のレプリケーションは非同期操作です。マスターデータベースとスレーブデータベースのデータの間には、必然的に一定の遅延が発生します。これは隠れた危険をもたらします。トランザクションがマスターデータベースに書き込まれ、正常に送信されたが、スレーブデータベースがマスターデータベースの BINLOG ログをまだ取得していない場合、ディスクの損傷、メモリ障害、停電などによりマスターデータベースが予期せずクラッシュし、マスターデータベース上のトランザクションの BINLOG が失われます。このとき、スレーブデータベースはこのトランザクションを失い、マスターとスレーブの間に不整合が発生します。

この問題を解決するために、MySQL 5.5 から準同期レプリケーションが導入されました。当時の技術は、一時的に従来の準同期レプリケーションと呼ばれていました。この技術は MySQL 5.7 に開発され、強化された準同期レプリケーション (ロスレス レプリケーションとも呼ばれます) に進化しました。非同期レプリケーションでは、図に示すように、マスター データベースは、コミット操作を実行して BINLOG ログを書き込んだ後、BINLOG ログがスレーブ データベースに送信されるのを待たずに、クライアントに正常に戻ることができます。

半同期レプリケーションでは、マスター データベース上のすべての BINLOG トランザクションがスレーブ データベースに確実にレプリケートされるようにするため、マスター データベースはトランザクションが正常にコミットされるたびにフロントエンド アプリケーション ユーザーにすぐにフィードバックしません。代わりに、少なくとも 1 つのスレーブ データベース (詳細については、パラメータ rpl_semi_sync_master_wait_for_slave_count を参照) も BINLOG トランザクションを受信し、リレー ログに正常に書き込むまで待機します。その後、マスター データベースはクライアントにコミット操作の成功を返します (従来の半同期レプリケーションでも拡張半同期レプリケーションでも目的は同じですが、2 つの方法には 1 か所違いがあります。これについては後で説明します)。

半同期レプリケーションでは、トランザクションが正常にコミットされた後、少なくとも 2 つのログ レコード (マスター ライブラリの BINLOG ログに 1 つ、少なくとも 1 つのスレーブ ライブラリのリレー ログに 1 つ) が存在することが保証されるため、データの整合性がさらに確保されます。

従来の半同期レプリケーションでは、マスターデータベースが BINLOG にデータを書き込んでコミット操作を実行した後、スレーブデータベースからの ACK を待機します。つまり、スレーブデータベースがリレーログを書き込んでデータをディスクに保存した後、マスターデータベースにメッセージを返し、フロントエンドアプリケーション操作を正常に返すことができることをマスターデータベースに通知します。これにより問題が発生します。つまり、マスターデータベースは実際にトランザクションをトランザクションエンジン層にコミットしており、アプリケーションはデータが変更したことをすでに確認できますが、戻りを待っているだけです。この時点でマスターデータベースがクラッシュすると、スレーブデータベースがまだリレーログを書き込むことができていない可能性があり、マスターデータベースとスレーブデータベースの間に不整合が発生します。拡張された半同期レプリケーションは、この問題を解決するために設計されています。マスター データベースが BINLOG にデータを書き込んだ後、少なくとも 1 つのスレーブ データベースがリレー ログに書き込み、データをディスクに保存するまで、スレーブ データベースの応答 ACK を待機します。次に、マスター データベースにメッセージを返します。これにより、コミット操作を実行できることが通知されます。その後、マスター データベースはトランザクション エンジン レイヤーへのコミットを開始し、アプリケーションはデータが変更されたことを確認できます。拡張された半同期レプリケーションの一般的なプロセスを次の図に示します。

半同期レプリケーション モードでは、スレーブ データベースに BINLOG ログを送信するときにスレーブ データベースがクラッシュしたり、ネットワークが遅延したりすると、BINLOG ログは時間内にスレーブ データベースに送信されません。このとき、マスター データベース上のトランザクションは一定時間待機します (時間の長さは、パラメータ rpl_semi_sync_master_timeout で設定されたミリ秒数によって決まります)。この時間内に BINLOG ログをスレーブ データベースに正常に送信できない場合、MySQL は自動的にレプリケーションを非同期モードに調整し、トランザクションは正常にクライアントに送信結果を返します。

半同期レプリケーションは、マスター データベースとスレーブ データベース間のネットワーク状態に大きく依存します。往復遅延 RTT が小さいほど、スレーブ データベースのリアルタイム パフォーマンスは向上します。簡単に言えば、マスター データベースとスレーブ データベース間のネットワークが高速であるほど、スレーブ データベースのリアルタイム性が高まります。

注: ラウンドトリップ時間 (RTT) は、コンピュータ ネットワークにおける重要なパフォーマンス指標です。これは、データ送信の開始から受信者からの確認の受信までの合計時間を示します (これは少しわかりにくいかもしれませんが、TCP 3 ウェイ ハンドシェイクの最初の 2 つのハンドシェイクとして理解できます)。

要約する

これで、MySQL マスタースレーブ レプリケーションに関するこの記事は終了です。MySQL マスタースレーブ レプリケーションの詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。