スレーブが処理出来る量を超えた更新がマスターからやってくると、

スレーブでは更新が滞ってしまう。ひとつの大きなトランザクションによる遅延は突如としてやってくるが、こちらの場合は徐々にスレーブが遅れていくことになる。どのリソースがボトルネックになるかは状況次第だが、概ね次の３パターンに分けて考えると良い。
 
    CPU bound ... スレーブへの参照の負荷が高すぎて、スレーブSQLスレッドに割り当てるCPUリソースが枯渇してしまっている。
    Memory bound ... ワーキングセットがInnoDBバッファプールよりもずっと大きい。UPDATEやDELETEを実行する場合には、対象となるレコードがバッファプール内に存在している必要があるが、バッファプールが小さすぎる場合には頻繁にディスクから読み込む必要が生じることになり、ディスクI/Oは時間がかかるので遅延の原因となる。
    I/O bound ... マスターでは更新は並列に行われ、グループCOMMITによりログへの更新がまとめて行われるが、スレーブ上ではトランザクションはひとつずつしか実行できない。COMMITのたびにディスクへの同期が行われるが、その操作は時間がかかる。マスターとスレーブでの同期回数の差異により、スレーブが遅れてしまう。

マスターで１時間かかるようなトランザクションは、マスターでCOMMITされた後に

スレーブで開始され、同じように１時間かかるので、
スレーブが同じ状態に追いつくのは約１時間後になる

レプリケーションの遅延をモニタリングする、pt-heartbeatを使おう。

cat /etc/sysconfig/network

netstat -pl
netstat -pnve