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など）とセッションテーブル用であることがわかりました。一部のデータは何度も繰り返されます。
ちなみに、私は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は、あなたは、データベースに保存しておきたいかもしれないことを、多くの場合、缶をそれらが多数ある場合は、再フェッチが非常に遅くなります。

また、セッション情報をデータベースの外に移動することもできます。たとえば、MongoDBに配置したり、他にもある可能性があります。

ビンログの日付を確認しましたか？expire_logs_days設定は「自動マジック」ではありません。mysqlを再起動するとき、コマンドを実行するとき、flush_logsまたはmax_binlog_sizeに達したときにのみ有効になります。

次に、mysqlは現在のログファイルをローテーションし（新しいファイルを作成）、1日より古いファイルを削除します（あなたの場合）。

my.cnfでこの最後の設定をセットアップして、それがexpire_log_daysと組み合わせて機能するかどうかを確認してください。