MySQL マスタースレーブ遅延問題の解決方法

今日は、マスタースレーブ遅延が発生する理由とその対処方法について説明します。

しっかり座って出発の準備をしてください!

マスタースレーブ共通アーキテクチャ

アクセス数の増加に伴い、単一のデータベースの応答容量が不十分になってきました。そこで、マスターデータベースがデータを書き込み、スレーブデータベースがデータを読み取る、読み取りと書き込みを分離するマスタースレーブアーキテクチャが導き出されました。

実稼働環境では、一般的なマスター スレーブ アーキテクチャが多数存在します。ここでは、一般的なアーキテクチャ パターンをいくつか紹介します。

マスタースレーブ複製原理

マスタースレーブの基本的なアーキテクチャと関連する構成を理解した後、本題に入りましょう。

マスターとスレーブの関係では、通常の操作では、マスター データベースを使用してデータを書き込み、スレーブ データベースを使用してデータを読み取ります。これの利点は、読み取りと書き込みの負荷が分散され、すべてのリクエストがメイン データベースに配置されることが回避されることです。同時に、データベースからの水平拡張により、システムの拡張性と負荷容量が大幅に向上しました。

しかし、問題が発生します。スレーブ データベースのデータをマスター データベースと一貫性のある状態に保つには、マスター データベースのデータが書き込まれた後にスレーブ データベースに同期される必要があります。マスター データベースとスレーブ データベース間のデータの一貫性を維持する方法と、マスター データベースがスレーブ データベースにデータをリアルタイムで同期する方法を教えてください。

根拠

MySQL マスター スレーブ レプリケーションには、非常に重要なログ ファイルが 2 つあります。

• binlog (バイナリログファイル)
• リレーログ

マスターとスレーブの同期プロセス中、マスター データベースはすべての操作イベントを binlog に記録します。スレーブ データベースは、I/O スレッドを開いてマスター データベースとの通信を維持し、一定の時間間隔で binlog ログ ファイルが変更されたかどうかを検出します。バイナリログが変更されると、マスター ライブラリはバイナリログ ダンプ スレッドを生成し、バイナリログをスレーブ ライブラリ I/O スレッドに送信します。スレーブ上の I/O スレッドは、バイナリログを独自のリレー ログにコピーします。最終的に、スレーブ データベースの SQL スレッドはリレー ログ内のイベントを読み取り、スレーブ データベースに再生します。

マスタースレーブ遅延の原​​因

上記のプロセスでマスタースレーブレプリケーションの関連プロセスはすでにわかっていますが、マスターデータベースが更新されると、スレーブデータベースが同期されます。では、なぜマスタースレーブ遅延が発生するのでしょうか?

ランダムリプレイ

MySQL メイン データベースへの binlog の書き込み操作は、順次書き込まれます。前述したように、ディスクの順次読み取りおよび書き込み速度は非常に高速です。同様に、ライブラリ内の I/O スレッドからのログ操作の速度と効率も非常に高いです。ただし、データを再生するための SQL スレッドもあり、再生プロセスはディスクへのランダム書き込みであることを忘れないでください。ここまでで、ある時点でリレー ログ内のデータをスレーブ データベースに再生できなくなり、マスター スレーブ間の遅延が発生することを理解できたはずです。

メインデータベースの高同時実行性

スレーブ データベースの SQL スレッドの再生ステータスがわかれば、マスター データベースの高い同時実行性がマスター スレーブ間の遅延を引き起こす理由を理解するのは難しくありません。ある瞬間に、マスター データベースに大量の書き込み要求が送信され、binlog を継続的に書き込む必要があることを意味します。このとき、スレーブ データベースの SQL スレッドが圧倒され、マスター スレーブ間の遅延が自然に発生します。

ロック待機

シングルスレッドの SQL ステートメントの場合、ブロックが発生すると、ステートメントは実行が成功するまで待機してから続行されます。ある瞬間に、スレーブ データベースがクエリによるロック待機状態になった場合、次の操作は現在の操作が完了した後にのみ実行されます。同様に、マスター スレーブ間の遅延が発生します。

マスタースレーブ遅延処理

マスタースレーブ遅延の原​​因がわかったので、対処方法を見てみましょう。

並列レプリケーション

SQL シングルスレッド再生の速度には制限があるため、マルチスレッド再生を使用できますか? MySQL バージョン 5.6 以降では、SQL スレッドを複数のワーカー スレッドに変換して再生する並列レプリケーション メソッドが提供されており、マスター スレーブの遅延問題が解決されます。

メインデータベースの同時実行性を減らす

現在、古いバージョンのデータベースを使用しており、バージョンをアップグレードできないのですが、どうすればよいでしょうか?マスター データベースの同時実行性が高い状況では、この方法で同時実行性を制御することによってのみ遅延を解決できます。Redis をより頻繁に使用してください。

メインライブラリを読む

あなたもこのような状況によく慣れているはずです。リアルタイム性が求められるデータの場合、データベースから読み取るだけでは不十分です。半日遅れると、年末ボーナスに影響が出てしまいます。

要約する

マスタースレーブ複製原理

マスター スレーブ レプリケーションには、binlog とリレー ログという 2 つの非常に重要なログ ファイルがあり、それぞれマスター ライブラリとスレーブ ライブラリに配置されています。 Binlog はマスター スレーブ レプリケーションの基礎です。操作イベントは Binlog に書き込まれ、同期のために I/O スレッドを介してスレーブ データベースに送信されます。

マスタースレーブ遅延の原​​因

• スレーブ データベース内の SQL スレッドの再生プロセスはディスクにランダムに書き込まれ、SQL スレッドはシングル スレッドであるため、データが時間内に再生できない場合は、マスター スレーブ間の遅延が発生します。
• マスター データベースの同時実行性が高くなると、書き込み操作が継続的に binlog に書き込まれるため、SQL スレッドが過負荷になり、マスター スレーブ間の遅延が発生する可能性があります。
• 再生中のロック待機も遅延の原因の 1 つです。

マスタースレーブ遅延処理

MySQL バージョン 5.6 以降では、並列レプリケーションを使用して、SQL シングル スレッドによって発生するマスター スレーブ遅延問題を解決します。下位バージョンの場合、この問題はメイン ライブラリの同時実行性を減らすことで解決できます。データのリアルタイム要件が厳しい場合は、メイン データベースを読み取ることでこの目標を達成できます。

上記は、MySQL マスタースレーブ遅延問題を解決する詳細な内容です。MySQL マスタースレーブ遅延の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。