MySQL: 2009年11月アーカイブ

いや、まあ、MySQL に限ったことじゃないけどな。

PostgreSQL にしても、バックアップしてリストアしたデータが化けちゃうってのは良くあることで、まあ、最初の原型作ったヤツらにとっては英語が全てなわけで、その後多言語化のために色々な仕組みが継ぎ足されたわけだから、問題が起こって当たり前って感じもしますが。
日本語だけでも、何個のコード体系があるんだよ、実際。(^^;

今回の MovableType の移行でもハマったぁ！

mysqldump によるバックアップ時と、mysql によるリストア時の、default-character-set の指定だけで何とかならんかいなと色々やったんだけど、結局、

mysqldump --default-character-set=binary -u hoge -phoge mtos > mtos_20091106.dump

で、文字コード変えずにバックアップして、mtos_20091106.dump を一旦ローカル PC にダウンロード。
で、秀丸エディタを使って中身を修正。

修正箇所は、

DROP TABLE IF EXISTS `mt_ts_job`;
SET @saved_cs_client     = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE `mt_ts_job` (
  `ts_job_jobid` int(11) NOT NULL AUTO_INCREMENT,
＜略＞
  KEY `mt_ts_job_funccoal` (`ts_job_funcid`,`ts_job_coalesce`),
  KEY `mt_ts_job_funcrun` (`ts_job_funcid`,`ts_job_run_after`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

この、「ENGINE=MyISAM DEFAULT CHARSET=latin1;」の部分。
ここが、latin1 になってるので、utf8 に修正する（テーブルの数だけ。40箇所くらいかな）。
「ENGINE=MyISAM DEFAULT CHARSET=utf8;」という具合に。

で、これを新サーバにアップして、

mysql --default-character-set=utf8 -u hogehoge -p mtos < mtos_20091106.dump

とリストアする。

この方法以外ではどうすることも出来なかった。

ああ・・・面倒臭い、面倒臭い。元の MySQL の設定にも依存しちゃうし、なかなかすっきりいかないもんですなあ。

次に遭遇した問題が、mt.cgi の実行で、

Connection error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)

というエラーが発生しちゃう件。

いや、確かに、旧サーバでは Socket ファイルを /var/lib/mysql 以下に作成していたけど、新サーバでは /tmp の下に作成してる。だから、'/var/lib/mysql/mysql.sock' を使ってソケット通信しようとすれば、そりゃあエラーになるよ。

・・・が、決め打ちなの？(^^;

どこかで指定してるのかと思い、grep しまくったけど結局 '/var/lib/mysql/mysql.sock' を固定的にセットしている部分は見つからず。
でも、まあ、どっかに記述があるんだろうな・・・

別に、/tmp 以下にこだわっているわけではないので、ディレクトリを /var/lib/mysql に変えてもいいのだが（/etc/my.cnf の socket = /tmp/mysql.sock の記述を修正するだけだし）、何となく悔しいので MovableType 側で対応することに。

結局、mt-config.cgi に環境変数として path を記述するのが一番スマートな気がしたので、

DBSocket /tmp/mysql.sock

という記述を追加。
これで、件のエラーは発生せず、正常に管理画面を使うことが出来るようになったのである。

・・・が、そんな俺に、新たな敵が。
あ、いや、新たな問題が・・・