現在、3つのスレーブデータベースがあります。
ただし、ほとんどの場合、そのうちの1つは他のデータベースよりも非常に低速です(マスターデータベースから1時間後になる可能性があります)
誰かが同様の問題に遭遇しましたか?原因は何でしょうか?
現在、3つのスレーブデータベースがあります。
ただし、ほとんどの場合、そのうちの1つは他のデータベースよりも非常に低速です(マスターデータベースから1時間後になる可能性があります)
誰かが同様の問題に遭遇しましたか?原因は何でしょうか?
遅いレプリカと同じホストで他のプロセスが実行されていると思いますが、リソースを大量に消費しています。
「top」を実行してみて (または Nagios や Cactus などを使用して)、3 つのレプリカ ホストでシステム パフォーマンスを監視し、観察できる傾向があるかどうかを確認してください。mysqld 以外の別のプロセスによって固定された CPU 使用率、または I/O が常に飽和状態にある、などです。
更新: MySQL パフォーマンス エキスパートの Peter Zaitsev による次の 2 つの記事をお読みください。
著者は、レプリケーションはシングルスレッドであり、レプリカはマスターで実行されたように並列ではなく、順次クエリを実行すると指摘しています。そのため、非常に長時間実行されるレプリケートされたクエリがいくつかある場合、それらは「キューを保持する」ことができます。
彼は、解決策として、実行時間の長い SQL クエリを単純化して、より高速に実行することを提案しています。例えば:
何百万もの行に影響を与える UPDATE がある場合は、それを行のサブセットに作用する複数の UPDATE に分割します。
UPDATE または INSERT クエリに複雑な SELECT ステートメントが組み込まれている場合は、SELECT を独自のステートメントに分割し、アプリケーション コードで一連のリテラル値を生成してから、これらに対して UPDATE または INSERT を実行します。もちろん、SELECT はレプリケートされません。レプリカは、リテラル値を持つ UPDATE/INSERT のみを参照します。
実行時間の長いバッチ ジョブがある場合、他の更新プログラムがレプリカで実行されるのをブロックしている可能性があります。いくつかのスリープをバッチ ジョブに入れるか、バッチ ジョブを記述して、間隔を置いてレプリケーション ラグをチェックし、必要に応じてスリープすることもできます。
すべてのスレーブ サーバーは同じ場所にありますか? 私の場合、スレーブ サーバーの 1 つが別の場所にあり、ネットワークの問題でした。