Gバイトのオーダーになっていたblogmap関連のDBサイズを圧縮する作業に失敗して、ただいまサーバートラブル中。blogmap以外にはあまり影響がないようにしていたつもりだったけど、DB負荷が高すぎて（さすがにGバイト単位になるとちょっとした操作にindex張り直しが付随するとめちゃめちゃ重いな）ほかにも影響が出ていたり。まあ正月中は更新しているサイトも少なくて、blogmapのランキングデータもちゃんと出てこないんで、餅でも食って復旧を気長にお待ちください。ああ、あけましておめでとうございます、でした。

なんとか最新のデータを生かしたまま復旧しようと思っていたんだけど、どうしてもindexの再生成に失敗する（ちなみにMySQLなんだけど、新規テーブルを作成して、.MYDを上書きしてindexを再生成する方法でもダメだった）んで、あきらめて昨日の朝の時点のデータに復旧中。1Gバイトのデータをひたすらinsertで復旧するのって数時間かかるのか。そこそこマシンパワーはあるんだけどなー。それが終わってもまだ何カ所か不整合があるはずなんで、そちらを調整してから、ようやくもう一度データの圧縮作業（DB側に任せていた部分をロジック側である程度吸収する＝CPUパワーとのトレードオフによってデータサイズを減らす）にかかることができて、その調整が終わったらようやく通常の裏タスクを復帰させる感じかな。これだけ苦労したんだから、いろいろ劇的な効果があるといいんだけど。目標はさまざまなコストの50％以上オフかな。

うげ、mysqldumpしたファイルをよく見たら、ちゃんと全データがdumpされていない。Gバイト（＆18+0+万行）を越えるテーブルの内容が途中まで（10+0+万行弱）しかdumpされていないみたいだけど、mysqldumpにサイズ制限とかレコード数制限ってあるんだっけ？　ってことで、欠けていないデータを復活させるためには、壊れたテーブルデータを何とか復旧するしかなくなったけど、それにこれ以上の労力をかける気になれないんで、ちょうど年の変わり目だしデータをリセットして新しくカウントし始めることにしよう。

壊れてしまったURL関連のデータはリセットして復旧。まあURL関連は生ものだから保存期間がさほど長くなくてもいいよね。ASIN（書評）関連のデータは別テーブルなんで無問題のはず。ダイエットしたURL関連のデータも相変わらず巨大になるようだったら、そっちは定期的に削除するか。