マスターは並列で実行され、スレーブはシリアルで実行されます。マスターが実際の 1 時間で 1.5 時間の挿入/更新/実行を処理できる場合、スレーブは遅れをとります。
スレーブの書き込みパフォーマンスを改善する方法 (メモリを増やす、ディスクを高速化する、不要なインデックスを削除する) が見つからない場合は、アプリケーション アーキテクチャの制限に達しています。最終的には、マスターが変更を並行して実行できるほど速く変更をリアルタイムで実行できない点に到達します。
多くの大規模なサイトはデータベースを分割しています: マスター + スレーブを複数のマスター + スレーブ クラスターに分割することを検討してください。次に、顧客ベースをこれらのクラスターに分割します。スレーブが遅れを取り始めたら、別のクラスターを追加します。
安くはありませんが、バイナリログ レプリケーションでステートメントを並列実行する方法を見つけられない限り、おそらくそれ以上の方法は見つからないでしょう。
更新 (2017) : MySQL が並列スレーブ ワーカー スレッドをサポートするようになりました。スレーブが遅れる原因となる変数はまだたくさんありますが、スレーブはシリアル順に書き込む必要がなくなりました。並列スレーブ スレッドのコミット順序を保持することを選択することは、任意の時点でのスレーブの正確な状態が重要な場合に確認する重要なオプションです。
試しましたか：1）SET innodb_flush_log_at_trx_commit = 0 2）SET sync_binlog = 0
どちらも、サーバーに障害が発生した場合に、わずかなリスクを追加してスレーブを高速化するのに役立ちます.
スレーブにメモリを追加すると、おそらく役立つでしょう。32 MB から 128 MB になり、遅延は多かれ少なかれ解消されました。しかし、それは安くないし、すべての状況で十分ではありません.
3台目のサーバーを購入しても、おそらくそれほど役に立たないでしょう。おそらく、遅れている別のスレーブを取得するだけです.