TRASH-NEWS MovableTypeにサインインできない不具合はテーブルの破損が原因だった

このTRASH-NEWSはMovableTypeというブログ管理ツールを利用しているのですが、その管理ページにおいてときおり“ページを移動するたびにログインを求められる”という不具合に出会うことがあります。

通常、管理ページのインデックスにアクセスする際1回ログインしてしまえば、以降そのログイン情報が保持され一定期間ログイン用ページに飛ぶことなく管理ページを行き来できます。つまりログインは数ヶ月に1ぺんくらい求められるだけで、あとは直接管理ページの中にアクセスできる、というわけです。

しかしこれが僕の場合ダメで、何故か毎回毎回ログイン用ページに飛ばされます。はっきりいって、超面倒であり超不便。もう1ヶ月くらいこの状態が続いてるし……なんとかしないと！

MovableTypeにおけるログインの処理(適当解釈)

まずはログインという行為がプログラム的にどう処理されているかをご紹介します(MovableTypeのバージョンはMT4.1、データベースとしてMySQLを使用している場合を想定)。なお僕は具体的な仕様書などを読んだことはなく、“こういう風にできているんだろうな”という憶測の元書いていますので正確さは著しく欠きますが、処理の流れについてはこの記事においてはさして重要ではと考えているためご容赦ください(この記事は対処法をお知らせするために書いています)。ちなみにMovableTypeではログインのことを『サインイン』と呼んでいますので適宜読み替えてください。

ログイン用ページで入力・送信した管理者名とパスワードのデータは、オンラインにあるMovableType用データベース(内のテーブル)のひとつ『mt_author』の『author_password』というフィールドに記録されているデータと照合されます。ここで正しいと判定されれば(管理者名の'author_password'と一致すれば)『mt_session』というデータベースに正しくログインしたという証拠としてログイン情報(『session_name』:管理者名、ほか)が書き込まれます。ここでログインが成功した場合の処理は終了、管理ページへのアクセスが許可されます。以降管理ページの各ページを移動するたびに『mt_session』にログイン情報が書き込まれているかがチェックされ、書き込まれていれば(ログイン状態が保持されていれば)該当ページが読み込まれ、書き込まれていなければログイン用ページへと強制変遷されます。

MovableTypeのログインの有無の判定について(憶測)

ここでログイン用ページへと強制変遷されるのはおもに3パターンの状況においてありえます。1つはサインアウト(ログアウト)していた場合。2つめはブラウザがCookieを受け入れない設定になっている場合。そして3つめはデータベースへのアクセスができなかった場合。

1つめについてはログアウトした時点で『mt_session』の該当部分が“ログアウトした”という風に書き換えられるため、ログイン状態とみなされないのは当然です。2つめについて、プログラム的にログイン状態を判定しているのはセッションという機能なのですが、これはCookieを利用しているためCookieを拒否しているブラウザではログインの有無が判定できません(参考記事)。よってムリ。そして3つめ。これがガンです。なぜならデータベースにアクセスできないというのはさまざまな要因が考えられるからです。データベースが過負荷で倒れた、データベースが壊れた、データベースへのアクセスが制限された、などなど……。ただでさえMovableTypeはデータベースを多用しているプログラムなので、データベースにまつわるバグや不具合は山のようにありますし、ありえます。

諸悪の根源はテーブルの破損だった(確信)

今回僕が1ヶ月近く“ページを移動するたびにログインを求められる”という不具合に見舞われていたのは、まさに3つめ、『データベースへのアクセスができなかった』ことが原因でした。

今日ふとこの原因に思い当たり、phpMyAdminというデータベース管理ソフトでMovableTypeの利用しているデータベース群にアクセスしてみたところ……『mt_session』テーブルが破損していることがわかりました。

phpMyAdmin標準の機能『テーブルを分析する』の結果

実行した SQL: SHOW INDEX FROM `mt_session` ;

MySQLのメッセージ: #145 - Table './(DBの名前)/mt_session' is marked as crashed and should be repaired

これか……これがいけなかったのか……!! てっきりデータベースへのアクセス不良(遅延とか)が原因だと思っていたのですが、テーブルが壊れていたのが原因だったのか……!! そりゃ壊れてたらログイン状態が判定できるわけがありません。

原因が分かればあとは対処するだけ。phpMyAdmin標準の機能として『テーブルを修復する』というすんばらしくわかりやすいものがあるのでそれを利用します(もちろん修復用のSQLで打ち込んでもOK)。

phpMyAdmin標準の機能『テーブルを分析する』の結果

SQL の結果

ホスト: (ナイショ) データベース: (DBの名前) 生成時間: 2008 年 5 月 10 日 23:38 生成環境: phpMyAdmin 2.10.1 / MySQL 5.1.20-beta 実行した SQL: ANALYZE TABLE `mt_session`; 行: 3 Table Op Msg_type Msg_text (DBの名前).mt_session analyze Error Table './(DBの名前)/mt_session' is marked as crashed and should be repaired (DBの名前).mt_session analyze Error Table 'mt_session' is marked as crashed and should be repaired (DBの名前).mt_session analyze error Corrupt

実行した SQL: REPAIR TABLE `mt_session`; 行: 1 Table Op Msg_type Msg_text (DBの名前).mt_session repair status OK

status OK

心強い……心強くわかりやすいメッセージ！

確認してみると無事テーブルの内容を参照できました。これできっと大丈夫。MovableTypeの管理者用画面にアクセスし、ログイン。適当なページへアクセスします。これまではまたログイン用ページへ飛ばされていましたが……

アクセスできたァァ！

再ログインを求められることなく無事アクセスすることができました。地味な感動を覚えました。これで画像のアップもできる……(画像などのファイルアップロードにはURLの打ち込みで対応できるGETではなくPOSTを利用しているためログインが保持され続けていないとダメ)。

MTの自動保存機能はまさに“使えない味方が最大の敵”の体現

何故『mt_session』が壊れたかについて思い当たるフシがひとつあります。それは……

自動保存機能……ッッッ!! (これまでのTRASH-NEWSにおける自動保存機能との死闘)

記事やテンプレートなどを勝手に自動保存してくれる自動保存機能の保存先はずばり『mt_session』。つまり重いデータが数秒おきに自動保存されるような設定(=比較的デフォルト)にしておくとデータベースへの負荷がとんでもないことになりかねないということに。まぁ普通のサーバーならばその程度でテーブルが壊れることもないかとは思いますが、何せこのTRASH-NEWSが利用しているのは貧弱サーバーなので……考えられなくも、ない……ッッ！

またいつこのような不具合に遭遇するかわかりませんが、なんにせよ原因と対処策がわかったのでひと安心です。あーすっきりした。お悩みの方がいましたらまずはお近くのphpMyAdminへ。これが今回体得した一番の知恵。