今日のライブラリからライブラリデータベース増加から遅れを担当する私の同僚は、MySQLはInnoDBのログを：page_cleaner：1000msで意図したループは17915msを取りました。
理解し、なぜ、InnoDBのからスイッチバック遅延が増加し、MySQLのログにつながるライブラリーから、keepalivedのライブラリをスタンバイに切り替えた後、前記+ MySQLのマスター・レプリケーション・スキーム、MySQL5.7のバージョン、keepalivedの：page_cleaner：1000msで意図したループは17915msを取ったが。
Viewサーバのトップ、CPU待ち占有の多数を発見しました
同時に、ビューのiostatでも100％のutilました
オンラインの視聴方法：
1、より大きな値が最良innodb_buffer_pool_instancesと一致することができるinnodb_page_cleanersを調整するが、サーバのCPUコアの実際の数に応じて調整します
2、またはhttp://blog.itpub.net/7728585/viewspace-2157988/書かれた教師の葉
図3は、どのようにMySQLの警告を解決するために：「InnoDBテーブル：page_cleaner：1000msで意図したループは、XXXのミリ秒を取った設定が最適ではないかもしれませんか。」？ - スタックオーバーフローhttps://stackoverflow.com/questions/41134785/how-to-solve-mysql-warning-innodb-page-cleaner-1000ms-intended-loop-took-xxx
これは、8Gに2コアサーバのCPU、メモリであり、そして2つの例を実行しました。だから、これは本当に弱すぎるハードウェアリソースです。
一時的なアイデアは、変更後の1、0と2のinnodb_flush_log_at_trx_commitダブルセットかどうか、何の改善も見られない、MySQLのパラメータsync_binlogを見ることです。ハードウェアは、最適化されていないライブラリのパフォーマンスから回復するために、サーバーのアップグレード（クラウドサーバ）の後に、データが後に行くようになったようです。