データコピーにまだまだ時間がかかるんで何がどうなってどうなったのか書いてみたりすると、blogmap用にRSSを収集するプロセス（収集プロセス）があるわけです。そいつはまず各種アンテナからサイトの更新状態を取得し（本当は更新情報チェックプロセスも別プロセスになってるけど）、その更新状態を見ながら新しいRSSを収集してきます。で、RSSをアイテム単位にばらしてDBに突っ込みます。このとき内容はチェックしません。で、それとは別プロセスとして、収集したRSSの内容から被リンク情報とかもろもろを解析し、その後不要になった情報を捨て去るというプロセス（解析プロセス）があります。集めて捨てるというプロセスが正常に動作していることで、生態系が安定していたわけですが、この間気づかないうちに結構長い間解析プロセスの方がこけていました。んでもって、最近スパム系のいらん情報がものすごく増えているのもあって、そのすきにデータ収集用テーブルのサイズがMySQL（＋Linux）の限界を超えてしまったわけです。そうなるとMySQLは4G境界あたりに腐ったデータ（インデックスとの整合性がないやつ）を作り出したりしてしまい、DBが腐ります。ひとまず解析プロセスを復活させてデータサイズに余裕を持たせてみたのですが、あまり時間がなかったのでデータサイズには多少しか余裕がなくなっていました。また、腐ったDBからレプリケーションしていた分散用DBのデータも徐々に腐っていたのですが、同期をとる時間がなかったのでそのまま運用を続けていました。多少不正確でも許される検索にしか使っていないレプリケーションサーバーなんで、そのまま使ってきましたが、レプリケーションサーバーはあまり腐る（マスターとの不整合が大きすぎると）とレプリケーション自体ができなくなります。で、限界を超えたんでレプリケーションサーバーを切り離したところ、マスターサーバーにかかる負荷が倍増して、高負荷で接続できない状態が断続的に起こるようになったわけです。で、昨夜あたりにサービスをいったん止めて、不要データを削除するプロセスを一晩走らせてから、マスターDBを完全復旧させ、さらにそれとレプリケーションとの同期を取り直している最中、というのが現状なわけです。まあ一番の敗因はキーになるテーブル（RSS情報管理）を作業テンポラリ兼用にしていた設計なわけなんですが、トランザクションのないMySQL（MyISAM）と例外処理のないPHPの組み合わせだと、その辺分離するよりもまとめちゃった方がいろいろましかなーと思ったんだよねー。結果としてこんなことになったんで、多少苦労してでも作業テーブルは分離しておくべきだったね。