まずは、本家のマニュアルに従って、DBのバックアップを作成したが、これは全く簡単で、圧縮・非圧縮の両方でバックアップを作成しローカルPCにダウンロードするのに20分もかからない。
この後、レンタルサーバー上でMySQLのDBを作成し、mt-config.cgiの記述を変更した後、管理者モードでログインする。最初にMovabletypeをインストールした時と同じ画面が表示されるので、ブログのURLやサイトパス、ユーザー名やパスワードを入力してログインする。これでMySQLに必要なテーブルが生成されるので、作成しておいたバックアップファイルからデータを復元すれば良いはずだったのだが．．．。
マニュアル通りに作業を進めたが、復元が開始された後、待てど暮らせど終了しない。一晩かけてもAssetの復元中で処理が止まったままで全く先に進まないのである。
さすがにこれはおかしいと思い、Webで情報を収集すると、他にもこの問題で四苦八苦している人が大勢いることが判明した。状況は様々のようだが、復元が終了しないということは共通している。色々な解決策が公開されていたので、先人の知恵に従って、試してみることにする。
まずは、バックアップファイルを一括ではなく細かく分割するという方法を採用してみた。レンタルサーバーの処理能力の問題で、一気に復元すると途中で処理が止まることがあるとのことだ。
一つの復元ファイルを300KBに制限して、何度かに分けて復元するという方法なのであるが、どうした訳か、最初の*.manifestファイルの読み込みからして失敗してしまう。これが読み込めないと先に進めないのでどうしようもない。
次に、バックアップファイルを用いるのではなく、ブログごとにエクスポートファイルを作成し、これを元に復元を試みたのだが、データベース自体は復元できるのだが、カスタマイズしたCSSなどが全く反映されず、これもNGであった。
どうやらMovabletype 4.2のバックアップと復元機能には、色々と問題があるようだ。試行錯誤の末、諦めてしまっている人も多いようなので、一時は匙を投げそうになったのだが、ふと思い立ってSQL文を用いてDBからDBへ直接データを渡すことを試みることにした。サーバーを引っ越す訳ではないので、コンテンツに含まれるイメージデータなどの配置に変更はない。各種の設定とブログ記事だけが復元できれば良いはずだ。
そこで、まずFTPを用いてSQLiteのDB（mt.db）をローカルにダウンロードした。これをSQLiteのGUIエディタである「tksqlite.exe」で開いて、*.sql形式でエクスポートする。この際、できるだけDBを軽くしておいた方が良いので、ログやトラックバックや余計なコメントは予め削除しておいた方が良い。
こうして作成したSQL文をレンタルサーバー上のphpMyAdminで実行すればデータの移行が可能となるはずだ。
ここで注意すべきは、既にサーバー上のMySQLにはMovabletype用のテーブルが生成していることだ。様々な試行錯誤に失敗しているので、テーブル構造だけではなく、部分的にデータも格納されている。そのため、総てのテーブルを空にしておく必要があるが、これはphpMyAdminを用いればほんの数クリックで行うことができる。
さて、ここでもう一つ注意すべきことは、既にテーブル等が生成されているので、tksqlite.exeで作成したSQL文から、「CREATE TABLE」と「CREATE INDEX」で始まるコマンドを削除しておくことである。要するに、テーブルとインデックスの生成をMovabletypeに任せて、データだけを流し込むということだ。従って、「INSERT INTO」コマンドだけを残すことになる。
ところが、phpMyAdminのSQLウィンドウにコマンドを貼り付けて実行してみると、ものの見事にエラーとなり、データは一つも取り込まれない。これは、tksqlite.exeが生成したSQL文が、phpMyAdminが受け付ける形式となっていないためである。
具体的には、tksqlite.exeでは、
INSERT INTO "mt_placement" VALUES(2, 2, 1, 7, 1);
という風にテーブル名をダブルクオートで囲んでいるが、phpMyAdminに食わせるには、
INSERT INTO mt_placement VALUES(2, 2, 1, 7, 1);
というようにダブルクオートを取り除く必要があるのだ。これは、適当なテキストエディタで置換をすれば簡単に行うことができる。
だが、これを行っても、一部のテーブルでエラーが発生する。あれこれと調べたところ、MySQLの「mt_asset」と「mt_blog」のDB構造が、SQLiteのそれと異なっていることが判明した。
具体的には、Movabletypeが生成したそれぞれのテーブルに、「asset_meta」、「blog_meta」というフィールドが欠落しているのだ。これは実に摩訶不思議なことだが、異なるDB間でデータの受け渡しを行う際には致命的だ。
そこで、phpMyAdminを用いて受け側のMySQLのテーブルに上記のフィールドを追加してやる。場所は、以下の通りである。
asset_label
asset_meta ←ここ
asset_mime_type
blog_manual_approve_commenters
blog_meta ←ここ
blog_moderate_pings
なお、型はとりあえずvarchar(256)で大丈夫だった。
これでSQLiteの各テーブルのデータをMySQLに格納して、改めてMovabletypeの管理者画面にログインすると、総てのデータが移行されていた。かなりアクロバティックな方法なので、お勧めはしないし、たまたま私の場合はそれでうまく行ったというだけのことかもしれない。試してみる場合はあくまで自己責任で行ってほしいが、最後の手段としてこんな方法もあるということを記しておく。
なお、この試行錯誤に比較すると、Movabletypeのバージョンアップは、ほとんど何の問題もなく、小一時間で終わってしまった。カスタマイズしたスタイルシートを少しだけ修正したのと、プラグインの一部を最新のものに入れ替えただけである。
コメントする