_ PHPが4.2.3に

あら、知らないうちにこのサーバーのPHPは4.2.3になって、しかも主だったオプションはすべてインストールされている状態なのね。これだったらたいていのプログラムは家サーバーで書いたそのまま動かせそうだな。それにこのバージョンアップのペースならば、4.3.0になるのもすぐかも。そうなってくると、家サーバーと分散させる処理の配分を根本的に考え直した方が効率が良くなりそうだ。そろそろこのサーバーでもサブドメインを使おうかと思っていたところだし、公開サーバーの構成を根本的に考え直してみようかな。このサーバーは回線は細そうだけれども、容量とCPUパワーにはまだ余裕がありそうだしな。あ、よく見たらZend Optimizerもインストールされている。

_ サーバートラブル中 (13:51)

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関連のデータも相変わらず巨大になるようだったら、そっちは定期的に削除するか。