MySql マスタースレーブレプリケーションメカニズムの包括的な分析

リレーショナル データベースとして、MySQL には組み込みのデータ レプリケーション メカニズムが用意されており、そのレプリケーション メカニズムに基づいて高可用性アーキテクチャなどの高度な機能を実装できるため、追加のプラグインやその他のツールを必要とせずに、MySQL を実稼働環境に適したものにすることができます。これは、MySQL が実際に広く使用されるための条件の 1 つです。

MySQL ベースのレプリケーション メカニズムは、データベースの高可用性を実現するだけでなく、パフォーマンス拡張、オフサイト災害復旧、ホットとコールドの分離などの高度な機能も実現します。

• 高可用性: 特定のレプリケーション メカニズムを構成することにより、MySQL はホスト間のデータ レプリケーションを実装し、ある程度の高可用性を実現します。より高い可用性を実現する必要がある場合は、複数のコピーを構成するか、カスケード レプリケーションを実行するだけで目標を達成できます。
• パフォーマンスの拡張: レプリケーション メカニズムは複数のデータ バックアップを提供するため、読み取り/書き込みの一貫性要件が高くないシナリオでは、1 つ以上のレプリカを構成して読み取り要求をレプリカ ノードに分散し、全体的な読み取り/書き込みパフォーマンスを向上させることができます。
• オフサイト災害復旧: 特定のオフサイト災害復旧機能を簡単に得るには、レプリカ ノードをオフサイトのコンピュータ ルームに展開するだけで済みます。実際には、全体的なパフォーマンスに影響を与える可能性のあるネットワーク遅延などの要因を考慮する必要があります。
• トランザクションの分離: レプリケーション メカニズムを構成し、低頻度で高計算のトランザクションをレプリカ ノードに送信して実行することで、これらのトランザクションが計算リソースをめぐって高頻度のトランザクションと競合するのを防ぎ、全体的なパフォーマンスの問題を回避できます。

上記の機能を利用するには、基本的な MySQL レプリケーション メカニズムを理解し、実際のアプリケーション シナリオに基づいて適切な構成を選択する必要があります。

マスタースレーブレプリケーションメカニズム

MySQL は、binlog に基づいてマスター スレーブ レプリケーションを実装します。スレーブ ノードは、マスター ノードの binlog 内の最新の更新を追跡して取得し、それを自身で再生することで、マスター ノードのデータを複製します。

次の図は、MySQL マスター スレーブ レプリケーション プロセスの概略図です。プロセス全体には 3 つのスレッドが関与しており、それぞれの役割は次のとおりです。

• マスター ノード binlog ダンプ スレッド: このスレッドは、スレーブ ノードがマスター ノードに接続した後に作成され、binlog に新しく書き込まれたデータをスレーブ ノードに送信する役割を担います。 binlog を読み取る場合、ダンプ スレッドは最初に binlog ロックを取得し、読み取り後すぐにロックを解除し、読み取ったデータをスレーブ ノードに送信します。
• スレーブ ノード I/O スレッド: スレーブ ノード I/O スレッドは、マスター ノードにデータ同期要求を送信し、マスター ノードから送信されたデータを受信して​​リレー ログに書き込む役割を担います。
• スレーブ ノード SQL スレッド: このスレッドは、リレー ログからデータ更新を読み取り、再生します。

非同期レプリケーション

デフォルトでは、MySQL のマスター スレーブ レプリケーションは非同期レプリケーションです。このメカニズムでは、マスター ノードはローカル ログの書き込みを完了するとすぐにクライアントの要求に応答し、スレーブ ノードのデータ レプリケーション プロセスは非同期で実行されます。

当然のことながら、このメカニズムでは、レプリケーション プロセスはクライアント要求に対するプライマリ ノードの応答に影響を与えないため、単一ノードと比較して全体的なパフォーマンスに大きな損失はありません。

ただし、このメカニズムでは、データがコミットされたがスレーブノードに同期されていないときにマスターノードがクラッシュし、マスターとスレーブの切り替えが発生して新しいデータが書き込まれると、データの損失や不整合が発生する可能性があります。

準同期レプリケーション

MySQL バージョン 5.6 以降では、非同期レプリケーションと比較して次の違いがある半同期レプリケーションをサポートしています。

マスター ノードは、クライアントの要求を受信した後、自身のノードのログ書き込みを完了し、少なくとも 1 つのスレーブ ノードがデータ同期応答を完了する (またはタイムアウトする) まで待機してから、要求に応答する必要があります。

スレーブ ノードは、リレー ログに書き込み、ディスク フラッシュを完了した後にのみ、マスター ノードに応答します。

スレーブ ノードがタイムアウトに応答すると、マスター ノードは同期メカニズムを非同期レプリケーションに縮退します。少なくとも 1 つのスレーブ ノードが回復し、データのキャッチアップを完了すると、マスター ノードは同期メカニズムを半同期​​レプリケーションに復元します。

非同期レプリケーションと比較すると、半同期レプリケーションではデータの可用性がある程度向上していることがわかります。非同期レプリケーションに退化していない場合は、マスターノードがダウンしても、データは少なくとも 1 つのスレーブノードにコピーされています。

同時に、スレーブノードはクライアントへの応答を完了する必要があるため、非同期レプリケーションと比較して、マスターノードとスレーブノード間のネットワーク相互作用に多くの時間がかかり、スレーブノードがファイルを書き込んでディスクにフラッシュするのにも時間がかかります。そのため、クラスター全体のクライアントへの応答パフォーマンスは低下することになります。

マスタースレーブレプリケーション形式

MySQL のレプリケーション メカニズムは binlog に基づいているため、binlog の形式によってマスター スレーブ レプリケーションの形式が決まります。 binlog には行ベースとステートメント ベースの 2 種類があるため、レプリケーションにも対応する 2 つの形式があります。

ステートメントベースのレプリケーション (SBR)

ステートメントベースのレプリケーションの場合、バイナリログには実行されたステートメントのみが記録されます。この方法には次の利点があります。

• これはバージョン 3.23 から存在しており、長い間実績のあるテクノロジーです。
• ログ ファイルに書き込まれるデータが少なくなるため、ファイルの書き込みとネットワーク転送の消費が減り、マスター スレーブ レプリケーションが全体的に速く完了し、パフォーマンスが向上します。
• ログ ファイルには、データベースで実行されたすべてのステートメントが記録され、監査やその他の目的に使用できます。
  

次のような欠点があります。

• ユーザー定義関数 (UDF) や実行結果が不確実な関数はコピーできません。
• データを更新する場合、行ベースのレプリケーションよりも多くの行ロックが必要になります。
• 最初に挿入してから更新するなどの複雑なステートメントの場合、スレーブ ノードは対応する完全な再生を実行する必要がありますが、行ベースのレプリケーションでは最終結果のみを実行する必要があります。
  

行ベースのレプリケーション (RBR)

行ベースのレプリケーション メカニズムでは、対応する binlog も行ベースになります。この場合、データが更新されて binlog に書き込まれるたびに、影響を受けるすべての行の変更が変換されます。

このレプリケーション方法には次の利点があります。

• すべてのデータ変更は安全に複製でき、UDF や特殊関数の影響を受けません。
• ほとんどの DBMS はこのレプリケーション方式を採用しており、知識の移行コストは低くなります。
• データを更新するときに必要な行ロックが少なくなり、パフォーマンスが向上します。
  

次のような欠点があります。

• DML に大量のデータが関係する場合、行ベースのログは大量のログ データを生成します。大量のデータは、ログ ファイルの書き込みとネットワーク転送に長い時間がかかることを意味し、全体的なパフォーマンスが大幅に低下する可能性があり、同時実行の問題も発生する可能性があります。
• 実行されたステートメントをログから確認することはできず、スレーブ ノードで実行されたステートメントを知ることもできません。
  

実際のアーキテクチャアプリケーションでは、システムのビジネス特性に応じてマスタースレーブレプリケーションメカニズムを合理的に使用し、適切なマスタースレーブレプリケーション形式を選択する必要があります。

上記は、MySql マスタースレーブレプリケーションメカニズムの包括的な分析の詳細な内容です。MySql マスタースレーブレプリケーションメカニズムの詳細については、123WORDPRESS.COM の他の関連記事に注目してください。