同様の事例をぐぐってみると、結構報告されている事例らしい。が、今回のケースはこれらのいずれにも該当しないものであった。
検索でヒットする事例は、いずれもMYSQLのテーブルのひとつ、mt_sessionが破損して、セッションを維持できなくなっているというもので、私のほうでもまずphpmyadminでMTのテーブルを確認してみた。以前テーブルが破損したケースを自分でも経験しているので、「ああ、またか」と思ったのですが、結果は異常なし。仕方が無いので、次はとりあえずサーバー本体をバックアップイメージからリカバリーしてみることにした。が、結果は同じ。
なんでだ？いよいよわからなくなって頭を抱えていると、以前SSDに交換する前のHDが残っていることに気がついた。このHDはサーバーの障害が多発することから交換したものだが、実は原因は外付けのHDだったという、間抜けな話で交換したHDだったので、もしかしたらこれで回復するかもしれないと思い、交換してみることにした。
するとなんと、これでMTが正常に動作するようになったのです。ここまでの経緯から、今回の障害はMYSQLの障害が原因ではないことと、昨年の１２月にSSDに交換したあとの何らかのカスタムが原因ということはがわかった。しかし、その何かが特定できないので、とりあえず、一つ一つまたカスタムを加えてみて、様子をみることにした。
その後様々な検証を加えた結果、特定された原因は、apacheに導入したSSLが原因らしいと言うことになった。SSLを導入しても、特に制限を加えなければ、フォルダーへのアクセスはhttp、httpsいずれでもアクセスができる。そこでこれまでMTのフォルダーのアクセスはSSLを使わないでアクセスを行っていたのですが、どうやらこれはダメらしい。ふとした思い付きからhttpsでアクセスを行ってみたところ、なんと問題なくセッションの維持が出来ているではないですか。な、なんでだ？。(；・∀・) いつもブログ投稿ソフトを使っていたので、ほとんどブラウザーでMTにアクセスすることがなかったのも、障害に気がつくのを遅らせる原因になった。まあ、そんなわけで、偶然今回の障害は回復し、MTの設定ファイルにSSLを使う設定を改めて行い、問題なくセッションの維持ができることを確認した。
ところが、今回はこれで終わりではなかったのです。動作確認のため、コメントを自分で入力してみたところ、「連続投稿しすぎ」と言う趣旨のエラーが出るのです。改めてぐぐってみると、MTはスパム対策を強化しており、連続投稿を弾く設定がなされているとのこと。「ThrottleSeconds 0」という記述を設定ファイルに記入すると、この機能を無効に出来るらしい。しかし、エラーは相変わらず出る。さらにぐぐってみると、某小粋空間に「この設定を施しても治らないケースがたくさんあり、このような場合MTの再セットアップを行って治しているようです」という趣旨の記事がある。かたや、自分でインストールしたプラグインが原因となっているケースもあり、それを特定することにより修復に成功したという事例もあった。そこで、まず自分でインストールしたプラグインをすべてフォルダーから削除した上で、テンプレートを初期化して再構築を行ったところ、なんと回復！ヽ(ﾟ∀ﾟ)ﾉ どのプラグインかはわからないけど、こういうこともあるんだと認識。うまく動かなくなったら、まずは初期化ということか。
こうやって書いてくると、簡単に回復したように思われるかもしれませんが、今回の障害対応は５日もかかってしまった。むやみやたらなカスタムは厳に戒めるべきだが、カスタムを行った場合、すべての機能が正常に機能していることを確認する作業も重要だと改めて認識した。
原因の検証まで行ったわけではないですが、自分のための備忘録と、同じような事例で悩んでいる、どこかの誰かの役にたてばと、今回のトラブル対策を書いてみました。
コメント