LoginSignup
5
1

More than 1 year has passed since last update.

レプリケーション遅延とは【対応策含め】

Posted at

レプリケーション遅延とは

まずはじめに

レプリケーション遅延」という言葉は、サーバー、主にDB周りを扱っている方なら時折耳にすることは多いと思います。
私も業務内にて耳にする機会はあり、その上でおおざっぱな理解はしていたもののレプリケーション遅延が「なぜ起きるのか」「生じた場合どのように対応すればよいのか」というものを改めて確認がてらメモを残して置こうと思い記載させていただきます。

また、今回例として挙げているものはMySQLとなります。

間違っている部分や補足点あればご指摘いただけるととてもありがたいです。。。

レプリケーション遅延とはどういうものか

レプリケーション遅延を語る上で欠かせないものとして、まずレプリケーションから進めていきます。

レプリケーションとは

MySQLを使用する際、主に障害対策負荷分散を目的としてレプリケーションを使用しているケースは多くあると思います。
レプリケーションというものは、「複製(レプリカ)をつくること」を意味しており、今回のMySQLにおけるレプリケーションもDBの複製を他サーバーに作成することで特定のDBが破損した場合に他のものに切り替える、また複数の複製を作成しサーバーに配置することで、DBアクセスの負荷分散を行うというものです。

レプリケーションはどのように行われているのか

おおまかな流れは以下になります。

1.マスタ(オリジナルのDB)のバイナリログにDBへの処理内容を記録
2.スレーブ(レプリケーション先)側でマスタからバイナリログを取得
3.スレーブ側で取得したバイナリログの内容をDBに反映

上記手順を確認すると、「毎回遅延起きるんじゃない?」と疑問に感じると思います。
その通り、細かい部分まで確認すると実際毎回遅延は生じています。しかしながらなぜ日頃問題にならないのかというと、このレプリケーションが遅延が日頃問題にならないほどに高速に行われているからです。

しかしながらこの高速に行われており遅延が問題にならなくなっているレプリケーションが、問題になるほどに遅延してしまっている状態、これがレプリケーション遅延です。

レプリケーション遅延はどういう時に起きるのか

大まかな要因としては、以下が挙げられます。

ネットワークの遅延

レプリケーションはネットワークを通じて行われるため、ネットワークの状態や送信するデータ量の影響を受けることになります。
そのためにネットワーク回線が遅延している場合やスレーブ数が多くマスターからの送信データ量が大きい場合に生じる可能性があります。

巨大なドランザクションの実行

マスターとなるDBにて、処理に膨大な時間がかかるトランザクション(DBシステムで実行される処理のまとまり、 または作業単位のこと)が実行された場合、上記の手順にある通りスレーブ側でも同様のトランザクションが実行されることになります。
その場合、例えば反映に1時間かかるトランザクションがマスターで実行された場合、スレーブ側でその更新が反映されるのもまたその約1時間後ということになります。

スレーブの過負荷

スレーブ側で処理できる量を超えた更新がマスター側から送られると、スレーブ側では更新が滞った状態となります。これは一つの大きなトランザクションによる遅延ではなく、次々と処理が溜まっていくことで生じる遅延となります。

レプリケーション遅延の対策はどうするか

まずどのように遅延を調査するか

こちらはSHOW SLAVE STATUSを実行し、その中のSeconds_Behind_Masterを確認することで遅延が発生しているか確認することができます。(数値が1であれば1秒の遅延が生じている状態です。)

また、その要因を追求するために、SHOW SLAVE STATUS内のRelay_Log_Posをファイルサイズ(Relay_Log_Space)と比較するなどし、読み込みや実行途中となっているのであればスレーブ側で遅延が生じていることが分かります。

次に、遅延の調査に大きく役立つのがスロークエリログです。こちらを確認することで巨大なトランザクションが発生しているかどうかは即座に判断できます。

また、上記の確認を行う上でZABBIXなどの監視ツールや、その他レプリケーション監視ツールを利用するとより確認がしやすくなります。

対策について

対策として挙げられる方法としては、

  1. 巨大なトランザクション(一度に大量の行を更新するもの)は実行しない
    可能であればコミットする行数を少しずつに絞り込むようにしましょう。また、大きなテーブルに対してALTER TABLEを実行する際のような致し方ない場合は、メンテナンスを実施するなど準備を行った上で実施しましょう。

  2. CPUの増設やスレーブの追加
    CPUリソースが枯渇している場合はCPUを増設したり、スレーブを追加するなどの方法があります。

上記以外にも対策はあると思いますが(参考サイトには他にも記載があったのでご覧いただければと思います、)、それぞれの状態にあった対策を講じていければと思います。

最後に

今回の記事は以下ブログ・記事を参考として記載を進めさせて頂きました。
参考先にはより詳細の記載であったり図を用いた説明もございますので、ぜひご覧になっていただければより理解が深まると思います。

MySQLにおけるレプリケーション遅延の傾向と対策/漢のコンピュータ道
とほほのWWW入門/MySQL/MariaDBレプリケーション

5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1