制作記……MovableTypeのログの「ゴミ」を取り除く

2009/03/09 05:00

今回の制作記はメインサイトがライブドアブログに移ったため、当方自身にとってはあまり実用的ではないかもしれないが、記録保全の意味も兼ねてのお話。具体的にはブログシステムのMovableTypeを使用している時に陥りがちな、「肥大化したログを削除する」方法。




●気がつけば ログのボリューム しこたまで エラーが出てきて さあどうしよう?
MovableTypeには「Movable Type のログの確認」という、システムの状態やログイン履歴の確認ができる機能がある。


Movable Type のログの確認
トラックバックの状況やシステム上のエラーを確認するのには便利な機能なのだが、一つ問題が。蓄積されるログは管理者が自主的に削除しない限り、「ずっと」「分割・圧縮されずに」保存されたまま溜め込まれてしまう。「テキストベースだから大した量は無いだろう」とタカをくくっていると、えらいことになる。

実はこのログ、システムの管理・チェック上必要ではあるが、それ以上のものではない。「ログの消去」というボタンが下にあることからも分かるように、削除してもMovableTypeの運用そのものにはまったく問題が無い。これに気がつかないと「大した投稿数でもないし画像も少ないのに、どうしてこんなに容量を食うのだろうか」と日に日に増大してサーバー容量を圧迫するログに頭を痛めることになる(【サイトの履歴】を見ればお分かりの通り、2006年後半に何度か容量を増大させているが、この「ログ問題」によるものだった)。

●消せばいい だけどボタンが 出てこない
肥大したログは、MovableTypeの機能にある「ログの消去」で消せばいい。具体的には「ログの確認」をした上で、そのログの最下層に表示される「ログの消去」のボタンを押すだけ。これで、ログの肥大によるサーバー領域の圧迫や、処理の遅延化(ログがあまりにも大きくなると、処理も多少もたつくようになる)ともおさらば。

……のはずなのだが。メンテナンスを怠り、「ログの消去」をせずに溜め込んでいると、「ログの確認」そのものが出来なくなる。つまり、表示させるログがあまりにも大きくなりすぎて、システムがオーバーフローを起こしてしまうのだ。具体的にはInternal Server Error (500エラー)などのエラーが出てしまう。「エラーの原因となるログを消したいのに、そのログ自身を消すボタンが表示できない」という八方ふさがりな状態に陥るわけだ。

この場合は、ログの表示をさせずに直接「ログの消去」をMovableType自身に実行させれば良い。具体的には「ログが大きすぎて表示できません」などのエラーが出てから


を直接URLに入力して実行。これで削除が出来る、はず。

●それすらできない……場合は直接削除
上記の「直接URL入力方式」で行うと、場合によっては「パスワードを変更したようです。一度ログアウトし、再びログインしてから行ってください」などのエラーメッセージが出る場合がある。この時はお手上げ(たいていの場合、再ログインしても同じメッセージが出る)。同様に、この機能を使ってもやはりInternal Server Errorが出る場合もお手上げ。要は「消すべきログが大きすぎてMovableTypeの機能では消せません」という状態だ。

この場合は物理的に該当データを削除するしかない。具体的にはデータベースに「Berkeley DB」を使っている場合、「log.created_on.idx」「log.db」の二つが該当する。あらかじめ内容が空の同名ファイルを作っておき、データベースの領域にアクセス。念のために現状の「log.created_on.idx」「log.db」をダウンロードして保全した上で、先に作った「空の同名ファイル」を上書き保存。これでログファイルは空になるはず。

データベースにMySQLやSQ_Liteを使っている場合には、【MT Database Converter】などのコンバーターを使って一度Berkeley DBにデータの形を変換させて、上記の2ファイルを空にし、またMySQLやSQ_Liteに戻せば良い。もちろんそれぞれの工程でファイルのバックアップをとっておくことを忘れないように。

●コンバーターすら利用できない……ツールで内部的に削除!
上記の方法で一件落着、のはずだったのだが、当サイトの姉妹ドメイン【http://www.jgnn.com/】で使用しているMovableTypeではそうもいかなかった。データベースにSQ_Liteを使っていたのだが、あまりにもログが肥大化したためにコンバーターそのものが途中で止まってしまい、Berkeley DBへの変換すら出来ない事態に陥ったのだ。

ただ、コンバーターでBerkeley DBとMySQLやSQ_Liteとのデータの置換が出来るということは、元々内部的にはデータの互換性があるはず(大本のシステムMovableTypeは同じなのだから)。そこで色々調べたところ、【ロリポップサーバーの案内で、SQ_Liteのデータ最適化】に関する説明が行われていたのを見つけた。説明そのものはデータ内部のゴミをお掃除する「VACUUM」コマンドの実施についてだったが、大いに参考になった。

まずはSQ_Liteを最適化するためのアプリケーション【TkSQLite】をダウンロードして解凍。そして対象となるSQ_Liteのデータをダウンロードし、「別々の場所に」「あわせて2つ保存する」。一つはコンバート用、もう一つはバックアップ用。そしてTkSQLiteを実行する。

左上のメニューから「File」を選び、「Open」を選択して、先にダウンロードしたSQ_Liteの該当ファイルのうち、コンバート用のを選択する。

するとファイル内部のテーブル構造が左上にツリー上で表示されるのが分かる。そこから「mt_log」をダブルクリックすると右側画面にログの一覧が表示されるのが確認できる。これが「邪魔なログ」だ。


TkSQLiteを使い、ログ部分を表示
当方の場合、実に9万行(!)近いログが収容されていた。これではオーバーフローを起こすのも無理はない。

ともあれ、ログの表示が出来たら、すべてを選択(一番左上を選択し、色が変わったらそのまま横のタスクバーを使って一番下を表示させ、シフトキーを押したまま一番右下をクリックすれば良い)。色が変わった部分にカーソルを合わせて右クリックを押してメニューを表示させ、一番下の「Delete Row」を選択すればOK。これで該当するデータが全部消える(最初にOpenしたファイル自身が書き変わる)。

その上で、書き換わったファイルをデータベースの領域に戻せば作業は終了。多少無茶な気もするが、今のところ使用上のトラブルは生じていない。

MySQLについては当方が利用していないので方法が分からなかったが、TkSQLiteのように内部をいじれるツールなどがあれば、同じような方法が使えるものと思われる。

---

留意して欲しいことをいくつか。まず、データベース用のファイルを直接操作するのは非常に大きなリスクを伴う。各場面でバックアップをとり、少しでもミス・トラブルがあればすぐに現状復帰をするよう手立てを講じておくこと。

そして、ファイルの操作はあくまでも自己責任で行うこと。当方の行った手段が最良のものであるかという保障は無いし、これで100％うまく行くという確約もない。同じ手法を用いて何かトラブルが起きたとしても、当方は一切関知できないことをここに書き記す。あくまでも「このようにやったらうまく行きましたよ」という備忘録以上のものではない。

またそれと同時に、MovableTypeを使っている場合には、こまめなメンテナンスが欠かせないことをあらためて確認しておく。言われてみれば当然のことなのだが、定期的な作業はついついおざなりになりがち。ログの肥大化一つをとっても、放置しておくと大変な手間と苦労がかかることになる。くれぐれもお忘れなく。

スポンサードリンク