◆ ftp-recordings:returns?

MTではRDBとしてPostgreSQL、MySQL、SQLiteをサポートしており、XREAでは3つとも使用可能なのだが、今回はMTでの運用実績も多く、自分自身ロリポップで使っていたMySQLと、軽量さがウリのSQLiteを検討候補にしてみた。

始めにBerkeleyDBのファイルのバックアップを取ってから、まずはmt-db2sql.cgiでMySQLにコンバート・・・できない。変換処理が重過ぎるのか途中でプロセスがkillされる。最初は処理時間が長すぎてCGIがタイムアウトしてるのかとも思ったが、途中までは結果が表示されるし、後日SSHでログインしてシェルから直接コマンド叩いたら途中でKillされてた。ただしこれはmt-config.cgiファイルでSQLSetNamesディレクティブに1を設定してやると途端に速くなりコンバートに成功した。

で、コンバートが出来たら次はMTにログインして動作確認しようとすると、今度はログイン出来ない。SQLSetNamesディレクティブをコメントアウトするとログインは出来るが、今度はエントリーデータとかが文字化けしまくり。これはDBの文字コードがアヤシイと睨んでphpMyAdminで見てみると、案の定接続照会順序がujis_japanese_ciになっていた。これを全テーブルともutf8_generic_ciに変えて、SQLSetNamesディレクティブの設定を有効にすると無事ログイン出来るようになった。とりあえず全エントリーともデータが入ってるのを確認し、「すべてを再構築」が出来るのを確認、コメントを付けれるのを確認して、次はSQLiteのテストへ。

SQLiteへのコンバートは、再度BerkeleyDBからmt-db2sql.cgiを使って行ってもいいのだが、今回はmt-db-convert.cgiを使ってみた(って作者さまは大学の研究室でお世話になった助手様ではないか)。ちなみにmt-db2sql.cgiだとやはり途中で処理が切られた。コンバートも無事済んで、動作確認で「すべてを再構築」・・・おー速い速い。MySQLの時はそれほど速さを感じなかったんだが、これはいい感じだ。ロリポップでMySQLを使ってた時もDBサーバに負荷がかかり過ぎなのか深夜帯では接続エラーで更新できない事が頻発してたし、今回はSQLiteを採用で決定。これで全て解決・・・と思ったのだが実はそうではなかった・・・。

1日置いて、てきとーに自サイト内を見回してたら変な所があった。トラックバックが来てたはずのエントリーの中に、トラックバックが表示されないものがある。管理画面のトラックバックの項目にはちゃんとデータが入っているのに、どうもエントリー側からトラックバックに対してちゃんと関連付いてないっぽい。取っておいたBerkeleyDBのバックアップに戻してみると正常になることから、DBのコンバートが上手くいってないようだ。再度mt-db2sql.cgiやmt-db-convert.cgiを使ってBerkeleyDB→MySQLやBerkeleyDB→SQLiteを試してみたが、どの組み合わせでも上手くいかない。これはもうどうしようもないので、DBのコンバートは諦めてテキストデータでインポート・エクスポートすることにした。

MTにはエントリー・コメント・トラックバック情報をテキストデータで読み込み/書き出しする機能があるので、これを利用してBerkeleyDBからSQLiteへ移行することにした。

1. 「読み込み/書き出し→エントリーの書き出し」でデータをテキストファイルとしてダウンロード
2. 全エントリー・コメント・トラックバックを削除
3. mt-db2sql.cgiでBerkeleyDBからSQLiteへコンバート
4. 個別アーカイブファイルを削除(画像とポップアップ用HTMLは残す)
5. ダウンロードしたテキストファイルを「<MTインストールパス>/import」ディレクトリにアップロード
6. 「読み込み/書き出し→読み込み/書き出し」でデータをインポート
7. 「すべてを再構築」

まっさらなところにインポートするのではなく、エントリーのないDBをコンバートしているのは、カテゴリーやテンプレートのデータは持ち越したいから。これでエントリーとトラックバックの関連付けも復元出来たし、万事解決ー・・・と思いきや、まだまだ問題が残っていた。

MTのデフォルトでは、個別エントリーのファイル名は基本的に保存時のエントリーのタイトルは決定され、タイトルに英数字を含まない場合は連番が振られるのだが、これがインポート前とインポート後で一致する保証がないという問題がある。例えばあるエントリーを保存した後にタイトルを変更し、これをエクスポート→インポートすると、インポート前は変更前のタイトルでファイル名を決めたのにインポート後は変更後のタイトルでファイル名を決定する。また、8、9、10と連番の振られたエントリーが存在し、8のエントリーを削除してからエクスポート→インポートすると、インポート前に9、10が振られていたエントリーは、インポート後にはそれぞれ8、9が振られることになる。意図的に過去の時刻のエントリーを作ってたりするとさらにとんでもないことになるだろう。そのため外部から個別エントリーにリンクがされていたりすると、正しくリンクされない可能性がある。

このblogでもこの問題にぶち当たり、日本語タイトルのエントリーの連番が途中から1ずれてしまった。そこで連番がずれる原因になったエントリーを探し出し、問題が出ないようにタイトルを変更してから再度エクスポート→インポートを行うことでずれを修正した。

といった具合に、MTのDB変更はそう簡単にいかない場合もあるので、運用開始時にちゃんと考えてDBを選びましょう。