2008-02-20

Movable TypeにおいてSQLiteからMySQLへ手動でデータ移行する

うちの Blog で利用している Movable Type は SQLite でデータ保存を行っていたのですが、どうもその SQLite データファイルが、利用しているホスティングであるさくらサーバの容量に対して到底無視できない割合(1/4)を利用しているということが判明。事実、容量の空きが非常に苦しいものとなってきていました。
その一方、さくらでは別途 MySQL も用意されており、ユーザは www 用サーバとは別に準備されたいくつかの MySQL サーバのうちの1つを選択し利用できるというサービス体系になっています。

そんな利用状況なさくらサービス、ひょっとすると使用可能なホスティングデータ量ってば、利用可能なサーバ容量の範囲とは別でないかという甘い考えが思いついたことはさておき、そもそも SQLite よりも MySQL サーバを利用するほうが保持するデータ容量は少なくなるであろうという考えの元、SQLite から MySQL へデータ移行することにしました。

その際、当方の SQLite におけるデータ構造や SQL 内容の理解がないので、1つ1つ確認しながら出来るよう、大よそを手動で事を進めていきました。今回のケースは Movable Type におけるお話ですが、他のものにもある程度流用できるのではないでしょうか。なおデータベース、および SQL についての若干ながらの知識が必要になるかもしれません。(SQL エラーが発生した場合に対応できるとか。)


0. 環境

参考までに、今回の環境は以下のとおり。
なお作業はオーソドックスにすべて CLI ベースのクライアントで進めました。
  • MySQL 4.0.27
  • SQLite 3.3.17
  • Movable Type 4.0


1. Movable Typeのデータスキーマを MySQL 側に作成

まず MySQL 上に Movable Type のデータが格納できるよう、スキーマを作成します。
MT の設定ファイル(mt-config.cgi)内に記述されたデータベース接続設定を SQLite から MySQL のものへ変更し保存します。MT はかつて SQLite 環境で動いていたもので問題ありません。むしろこのまま MySQL へ移行しようとするので、へたに新しい MT の管理ページを作成する必要はありません。

続けて MT の管理ページへアクセスします。すると MT は MySQL 上に MT 用データが存在しないため、新規作成を行おうとしますので、これを進めていきます。MTユーザ登録などもあわせて行う流れとなりますが、内容を覚えておく必要はありません。

作成が完了した後、MySQL クライアントを使って、MT 用テーブルのデータを全て消去します。MT 用テーブルは、テーブル名の先頭すべてに「mt_」という接頭辞がついているものです。
テーブルの削除ではなく、データの削除であることに注意しましょう。データ削除コマンドは「truncate テーブル名」です。またその他のテーブルデータも消えぬことのないように…。

これで MySQL 側の受け口ができました。


2. SQLite のデータダンプ

続いて SQLite データをダンプします。

SQLite データは1つのファイルにまとめられている状態となっています。sqlite のコマンドツールはこのデータファイルを指定して実行する仕組みとなっています。またデータダンプは、sqlite の「.dump」コマンドで行います。たとえば SQLite データファイル example.db に対してのデータダンプは、CLI より以下のように実行します。

$ echo '.dump' | sqlite example.db > sqlite.dump.sql

SQLite データファイルの指定、および sqlite コマンドの違いに気をつけましょう。(さくらの場合、「sqlite3」コマンドでした。)

このコマンドの実行で、sqlite.dump.sql というテキストベースの SQL データが出来ました。


3. SQL データを MySQL 向けに編集

SQLite のダンプデータは、SQL 文によるデータベースの情報や操作が記載されています。
SQL は色々なデータベースで利用されているものですが、今回ダンプした直後の内容では一部 MySQL で利用できないものが含まれているので、これを編集します。
  • 一行目の「BEGIN TRANSACTION;」を削除
  • 最終行の「COMMIT;」を削除
  • その直前の「CREATE INDEX~」行をすべて削除

まず以上のことを行うことで、データ内は「CREATE TABLE~」と「INSERT INTO~」のみのものとなります。

本来ならば、ここから「CREATE TABLE~」のSQLもすべて削除し「INSERT INTO~」のみにすることで MySQL への投入準備が整うのですが、私の場合はここから「INSERT INTO~」文を編集する必要がありました。このままデータを INSERT してしまうと、MySQL 上では目的のデータ構造とは異なるものになろうとしていたからです。

例えば、ダンプデータ内の CREATE TABLE 文が
CREATE TABLE mt_placement (
  placement_id integer not null primary key,
  placement_blog_id integer not null,
  placement_category_id integer not null,
  placement_entry_id integer not null,
  placement_is_primary boolean not null
);

というものに対し、実際のこのテーブルへの INSERT 文は

INSERT INTO "mt_placement" VALUES (4,2,2,4,1);

となっていたとします。データベースに対して CREATE TABLE を行った後にこの INSERT を実行すると、以下のようなレコードができます。

mt_placement テーブル
---------------------
placement_id = 4
placement_blog_id = 2
placement_category_id = 2
placement_entry_id = 4
placement_is_primary = 1

一方、既に MySQL 上で準備されている mt_placement テーブルは、先ほどの CREATE TABLE のものと同じとは限りません。同じテーブル内容なものの、カラム順が異なるケースが実際にありました。(以下は一例)

CREATE TABLE mt_placement (
  placement_id int(11) not null auto_increment,
  placement_entry_id int(11) not null,
  placement_blog_id int(11) not null,
  placement_category_id int(11) not null,
  placement_is_primary tinyint(4) not null,
  PRIMARY KEY(id)
)
type = MYISAM;

この場合、同じ INSERT 文を行った mt_placement テーブルはこうなります。

mt_placement テーブル
---------------------
placement_id = 4
placement_entry_id = 2
placement_blog_id = 2
placement_category_id = 4
placement_is_primary = 1

カラム名を指定した INSERT 文ではないため、テーブル定義を行った順に INSERT が行われてしまい、結果違うレコードに仕上がってしまいます。

これを回避すべく、ダンプデータ内に記述されている CREATE TABLE 文のカラム順序どおりに、INSERT 文を編集していくのです。(説明長い!)


先ほどの、

INSERT INTO "mt_placement" VALUES (4,2,2,4,1);

これは、こうします。

INSERT INTO mt_placement
(placement_id, placement_blog_id, placement_category_id, placement_entry_id, placement_is_primary)
VALUES (4,2,2,4,1);

ついでにテーブル名のダブルクオートも排除。なお複数行でなくても一行でOK。

全ての INSERT 文において、対応するテーブルの CREATE TABLE 文で示されているカラム順に従った形で INSERT 文を書き換えていきます。

INSERT 文のすべてを書き換え終わった後に、CREATE TABLE 文をすべて削除します。
 


4. MySQL へデータを投入

編集後のファイルを MySQL へ投入します。
例えば MySQL のデータベース「my_database」に対して投入する状況において、3. のセクションで sqlite.dump.sql ファイルを編集後 mysql.import.sql として保存したのであれば、以下のようなコマンドを実行します。

$ mysql my_database < mysql.import.sql
必要に応じて -u, -p などのオプションをつけて、SQL が正しく実行できるようにしましょう。 またエラーが発生した場合は原因を良く確かめて import ファイルを編集し、truncate でもう一度リセットした上で再投入しましょう。 5. Movable Type 管理へアクセス
投入後再び Web で MT 管理ページへアクセスします。SQLite 環境で稼動していたものと同じものが参照、利用できるはずです。

2008-02-07

大乱闘スマッシュブラザーズX

1/31の発売からおよそ一週間たったWii用ゲーム「大乱闘スマッシュブラザーズX」、スマブラX。恥ずかしながら発売後ずっと遊んでます。

どんなゲームかというと、かつて「マリオブラザーズ」とか「アイスクライマー」とか「バルーンファイト」の2P協力プレイのモードを使って対戦をしていた人に直撃する、ポコポコと4人まで同時に遊べる大乱闘アクションゲームなのです。
また任天堂ゲームのいろんなキャラクターたちが集まって操作できるというのも1つのポイント。

ゲームの中で動くキャラクターやフィールドこそ3Dモデルなものの、昔ながらの2Dゲームのように左右キーで移動して上キー(もしくはボタン)でジャンプしてボタンで攻撃というシンプルな操作はもはやお馴染みなものだからすぐ慣れる。

「面白いよ!」といって初めての人にコントローラを渡してしばらく触っていると、すぐに大よその基本的な操作ができるようになるのは良いですねえ。そのまま4人でワーワープレイできて面白いです。
 
 
このスマブラXは今回で3作目なんですが、今回は「これまでの任天堂ゲーム」を匂わすギミックがこれでもかというほど多数盛り込まれていて、かつて任天堂のゲームで遊んだ数が多ければ多いほど、より楽しめるという仕組みになってます。なつかしい演出やフィールド、キャラクタそして音楽が、記憶の奥に沈みきっていた子供のころのゲームの思い出を呼び起こしてきます。

特に音楽は新旧あわせて約250もの曲が準備されているらしく凄いボリューム。任天堂ゲームの名作のなかの名曲がアレンジされて流れてきます。あまりに懐かしすぎ+出来が良すぎて涙腺が危なかったのはいよいよ歳ということかなあ。しかしファミコン、スーパーファミコン、ニンテンドー64くらいまでは分かるんだけども、最近のポケモンとかのゲームがよー分からんのが悔しい。
 
 
また今回はネットワークを通じて対戦できるというモードもあって、知ってる人とも知らない人とも遊べます。やってみた感じ、発売直後は(恐らくアクセスが殺到しすぎて)全然遊べなかったのですが、今週になってボチボチと乱闘できるようになりました。アクションゲームのネットワーク対戦って大抵の場合キャラクターがワープしたりとかいきなり攻撃を受けたりとかあるんですが、このスマブラはネットワークを介して遊んでいるとは思えないほどの滑らかさで遊べてしまうのがまた凄い。(なぜ今までの通信対戦ゲームと違うのかが知りたい。)

Wii持ってる知り合いは買ってないのかなあ。フレンド対戦やりたいなあ。集まった結果「じゃあ今日は2グループに分かれて遊ぼうぜ!」とかやりたいなあ。

2008-02-05

HTML_Template_Flexy 1.3.xx

1/31 に開催された勉強会in大阪でも一部の人には話をしていたんですが、その後少しだけ動きがあったので。

勉強会の前日である 1/30 に HTML_Template_Flexy のバージョン 1.3.0 がリリースされ、いくつかの小さな新機能が実装されたということになってます。
このパッケージ、実は DB_DataObject と同じ作者が開発、管理しておりまして。(実際、同日に DB_DataObject のバグフィックスとしてマイナーバージョンがリリース)
で、去年の9月東京で開催されたPHPカンファレンスで私の「ネタ」をご覧になった方はお分かりかと思いますが、この方のパッケージをリリースする際に「ちょっとした落とし穴」みたいなミスをすることがたまにあったりして、あるバージョンのリリース後にも細かなFixバージョンUPを短時間で積み重ねてしまうということがあります。

さて今回の Flexy 1.3.0 にて、少し魅力的な機能を試してみたく Ver.UP して動かしてみたのですが、何やらエラーが発生。どういうことだとメッセージをチェックしたりファイル構成や中身を確認してみると、なんと新機能を利用するため新規に追加された(であろう)クラスファイルが存在しないため require に失敗し、結果 new class できず Fatal が発生している。

「AKまたやらかしやがった!」(rsky へ送ったメールより)

どうやら CVS には新クラスファイルが存在しているものの、PEAR パッケージを作成するための package.xml 内にそのクラスファイルを記述していなかったため、結果 1.3.0 パッケージ内にファイルが含まれない状況になっていたのです。

多分、CVS にコミット済みのものやらローカルに存在しているソースやら何やらが分散したり、時間が経ったことで混在しているオープン・クローズなソースの状況を忘れてしまっていたりしてるんじゃないかと思います。(今回ファイルを忘れていた分に関しても、機能的な部分の実装は数ヶ月前でした。それでも一部ミスがあったようですが。)

なお、現在出ている 1.3.2 では、1.3.0 リリース時に提示した機能の一部をカットしているようです。現在リリース分のものと CVS 上のソースの内容が異なっているのを見る限り、恐らく再実装しなおして次バージョンがリリースするのではないかと思います。
いまのところ 1.3.2 では問題は特に出ていません。(PHP5 で動かすと「is_a 使うのやめろ」という要求が出るものの、エラーではないです。) flexy:include 内の src 指定に変数が使えるのは地味に便利だし(ちょうど目前の案件で必要そうなシチュエーションだったのでワロタ)、あと radio エレメント内で id 要素を指定しないと怒られてしまうというのもこのバージョンからなくなります。ただし、いくつかの radio で同 name 要素を持つエレメントに対し 同 id 要素を持たせるというのは相変わらず NG。なので今後も変わらずマークアップ担当者には別 id を使うか class を使ってもらうようにしよう!

そしてがんばれ AK!!