mysqlバイナリログによりディスクがいっぱいになる
突然、ウェブサイトがダウンし（drupal 6.19）、mysqlを起動できなくなりました（クラッシュしたテーブルが多すぎます）。 df -hを確認したところ、非常に大きなバイナリログファイルが原因でMySQLパーティションがいっぱいであることがわかりました（バイナリログは1日だけ保持します- expire_logs_days = 1）; binbinログの1つをmysqlbinlogで確認すると、ほとんどのエントリはキャッシュテーブル（cache_form、boost_cache、boost_cache_relationships、cache_contentなど）とセッションテーブル用であることがわかりました。一部のデータは何度も繰り返されます。
ちなみに、私はwatch ls -lhを持っており、bin-logファイルは指数的に大きくなりました（1〜2分ごとに100Mのファイルサイズの新しいbinlogファイルを取得しました!!）
これを引き起こす原因について何か知っていますか？この問題を解決するにはどうすればよいですか？
明らかな改善の1つは、別のキャッシュバックエンドを使用することだと思います。
単一のサーバーと十分なメモリがある場合、APCバックエンド（D6： http://drupal.org/project/cacherouter 、D7： http：// drupal。 org/project/apc ）頻繁に使用されるさまざまなキャッシュを直接共有メモリに配置します。それはおそらくあなたが得ることができる最も速いキャッシュソリューションです。
別の選択肢は Memcached です。これは、キャッシュを共有する複数のサーバーがある場合に特に興味深いものです。
Cache_formは移動できないことに注意してください。これには、現在表示されているフォームに関する情報が含まれ、常にクリアできる他のもののような集約された情報だけでなく、一意の情報が含まれているため、実際にはキャッシュではありません。また、他の一部のキャッシュ、特にcache_updateは、使用したモジュールの更新情報に関する情報が含まれているため、他のキャッシュと同様に消去しないでくださいthat頻繁にあり、それらが多数ある場合、再フェッチが非常に遅くなる可能性があります。
また、セッション情報をデータベースから移動することもできます。たとえば、それを MongoDB に配置できますが、他にもある可能性があります。
ビンログの日付を確認しましたか？ expire_logs_days設定が「自動マジック」ではありません。これは、mysqlを再起動するとき、またはflush_logsコマンドを実行するとき、またはmax_binlog_sizeに達したときにのみ有効になります。
次に、mysqlは現在のログファイルをローテーションし（新しいログファイルを作成）、1日より古いファイルを削除します（あなたの場合）。
my.cnfでこの最後の設定をセットアップして、expire_log_days。