いつしか10月も中盤・・・。今年はブログ更新をサボり続けていたのだけど、なんだかんだで一ヶ月半のご無沙汰になってしまった。実は、9月の上旬にブログのデータを管理しているmysqlデータベースがクラッシュ。データ不整合のため、サービスが起動出来なくなってしまった。Webサーバ自体は生きているが、Movable Typeの機能がすべて止まってしまったので、更新が一切できなくなってしまった。
あれこれ忙しかったこともあり、なかなか復旧作業に手がつけられなかったのだが、データベースが復旧出来ないとデータを戻せない。Movable Typeが生成したHTMLファイルは残っているので、最悪、すべて再構築して、過去の記事はそのままおいておこうかとも思ったのだが、とりあえず、mysqlの解説を読みつつ、リカバリーモードで起動して、データをダンプすることにした。ダンプできてしまえばこっちのもの・・・・と、新たなデータベースサーバを構築して、ダンプデータを投入。さて、復旧・・・とMovableTypeにログインしてみたら、文字がバケバケ・・・・orz。そこから苦難の日々が始まる。
MySQLのダンプ（mysqldumpコマンドで作成）は、早い話が、データベースを再構築してデータを投入するためのSQL文のかたまりで、テキストファイルである。開いてみたら、ファイル自体が文字化けしている。nkfに読ませるとUTF8だと言うのだが、UTF8で表示すると文字化けする。どのコードで開いても正常に表示できない。どうやら誤ったコード変換がかかってしまったらしい。
あれこれ調べて見たら、元のデータベースのデフォルトコードが latin1 になっており、どうやら、ダンプする際に、latin1 から UTF8 への変換が行われてしまったようである。MTのデフォルトコードはUTF8なので、そのままダンプされればいいのだが、変な変換がかかってしまったためにデータが壊れてしまったようである。
それならば・・・と、再度オリジナルからダンプを試みたが、今度はリカバリーモードでmysqldが立ち上がらなくなってしまった。あれこれ設定をいじったりしてみたが起動しないので、今度は、先のファイルの修復を試みる。Google様をたよりに、nkfとか、秀丸とか、iconvとかを使ってあれこれやってはみたが、UTF8から latin1 の逆変換を試みてもエラーが出て、完全には復元できない。さて・・・・困った。とりあえず、仕方が無いので、最後にもう一度オリジナルのサーバの起動を試みる。
エラーの原因らしき設定をいくつか削除して、リカバリーモードのレベルを一段階上げてみたら、どうにか起動。とりあえず再度ダンプを実行する。今度は、--default-character-set=binary を指定して無変換でダンプ。ダンプファイルの文字化けは解消された。
さて、再度、そのデータをインポートして、今度は・・・・とログインしたが、依然として文字化け状態が続いている。そこからがまた悪戦苦闘。新しいサーバはバージョン8.0でデフォルトがUTF8MB4、クライアントのデフォルトがlatin1になっていたので、これを変えたり、データベースのデフォルトを変更したりしてあれこれやってみるが、どうしても文字化けが解消できず、昨夜は結局そこまでで断念。
で、今日、再度気を取り直して、あれこれまた試行錯誤する。クライアント側もUTF8, データベースもUTF8で文字化けするのは合点がいかない。もしや・・・と思ってテーブルを調べて見たら、なんとデフォルトが latin1 になってしまっている。データベースのデフォルトがUTF8なのだから、これは、そう指定しない限り「あり得ない」。こうなれば、調べるところはただひとつ。ダンプファイルである。これは、SQL文の塊だから、テーブル作成の create table文も当然含まれている。開いてみたら、案の定、create table .... default character set latin1 ... になっている。「これかっ！」である。とりあえず、latin1 を utf8 に書き換えて、再度実行したら、すんなりと文字化けが解消。目出度く復旧と相成った次第である。
そんな顛末をとりあえず書いて、ここから気を取り直してブログを再開するつもりだ。オリジナルがクラッシュした原因は不明・・・。仮想箱のHDDに問題がある可能性もあるから楽観できない。時々バックアップを取っておいた方が良さそうである。
コメントする