ます雑記

■ [diary] サーバメンテナンス

サーバを FreeBSD 6.3 に上げました。根っこから再インストールでしたので、ダウンタイムが長くなってしまいました。 ついでに Ruby のバージョンも上がっていることと思います。

日記の移行はディレクトリを丸コピしてきただけなので、本当にちゃんと動いているのか若干不安だったりはしますが……。

tdiary のコードも、本家のソースコード管理が SVN に移行したようなので、それに合わせて落とし直さないといけないはずなんですが、それはまた今度。

■ [diary] 解約×解約

入社当時ほどコンスタントに残業もしていませんし、無駄な月額支払いを辞めようと思い立ちまして、本日、余計な契約を解約しました。

まずは e2 by スカパー！、いわゆる110度CSデジタルです。正直、最近は地上波やBSで放送しているアニメですらほとんど見れていないので、コンテンツの量が too much。その上、最近アンテナの角度が悪いのか、妙な機器をアンテナ線に繋いでいる人が居るのか、CS の受信状況が非常に悪いため、契約していてもしょうがない状況だったのでした。

Web 上から解約できるかと思いきや、チャンネルの増減はできるものの、全て解約するには電話でオペレータにお願いする必要がありました。土曜の真っ昼間だからか、比較的すぐに電話は繋がりましたが、解約時には専門のスタッフが対応するようで、転送された上に電話を折り返されました。もしやすごい引き留め工作が行われるのかと緊張が走ったものの、理由を聞かれただけで、すんなりと解約には成功。解約の通知書が後日送付されますが、解約手続き自体は電話だけで完了です。ちなみに、1年以内の再契約ならば新規加入料は必要ないそうです。

続きまして、Willcom の PHS 契約の解約。来年春には Willcom CORE のサービスも始まるようではありますが、少なくとも会社に自転車で通っている限りは外でデータ通信を使用する機会は全くないんですよね……。さらに、最近は GMail で携帯電話からメールチェックもできますので、ますますデータ通信が不要となっていたのでした。

こちらは、Willcom の PHS から 116 番に電話するとサポートセンターに繋がりますので、そこでオペレータに解約の申し出をします。最初の自動応答での入力番号が 42 なのは意図的なものなんでしょうか……。解約理由は聞かれましたし、友人に譲ることもできますが……と言われましたがそんな心当たりもないので解約手続きを進めました。こちらは、解約手続き用の書類が送られてくるので捺印の上、返送が必要とのこと。

ともあれ、これで月6000円程度が削減できます。すっきりしました。

さて、この浮いた予算で、iPhone3G を……（違

■ [comp:mysql] mysql 3.23 -> 5.0 の泥沼

OS を FreeBSD 6.3 に上げたのは簡単だったので、この調子で結構簡単に全て上がるかと期待していたのですが、mysql で大はまりしました……。

FreeBSD 4.x 時代は mysql323-server を使っていたのですが、6.3 に上げると、php4-mysql が depend しているのが mysql50-server になってしまっており、特にビルドオプションで使用するバージョンを切り替えられる様子もありません。

いつまでも2世代前のバージョンを使っているわけにもいかないしなぁ、ということで 5.0 へ乗り換える気になった……のが運の尽きでした。

丸一日ハマっていたので、忘れないうちに正しい手順をメモしておきます。

問題の数々

基本的には、mysql のバージョン非互換が問題なわけですが、今回、Xoops 2.0.16a JP の DB を上げる際に引っかかった問題をまずは挙げましょう。

• 文字コード関連機能の追加
• マルチバイト文字に対する CHAR() の扱いの変更
• PASSWORD の形式の変更など、パスワードが保持されている mysql.user テーブルの変更

特に上記を含む 4.0 から 4.1 の段階で変わった大きな変更に関しては、このサイトが詳しく解説してくださっています。

あとは、下の解説と同じようなことをもっと丁寧に説明してくださっている こんなページ もあります。CHAR のサイズ変更にまじめに対応したい場合はこちらの情報も参考にしてください。

正しい手順

さんざん試行錯誤した訳ですが、最終的に行き着いた、最初からこうすればきっとよかったに違いない、という手順だけをメモしておきます。

1. 古い mysql で mysqldump でも使って sql 文で DB のバックアップを取っておきます。
   • このとき、DB で使っていた日本語文字コードが何だったかをチェックします。以下、euc だったと仮定して進めます。
2. 新しい mysql をクリーンにインストールします。
   • mysqld のビルド時のキャラクターセットに ujis などのサポートが含まれていることを確認してください。
   • FreeBSD での方法についての説明は こちらのサイト が丁寧でオススメです。
   • /usr/local/etc/pkgtools.conf の MAKE_ARGS に 'databases/mysql50-*' => ['WITH_CHARSET=ujis', 'WITH_XCHARSET=ujis,sjis'] を追加してから mysql50-* を portinstall するイメージです。
3. /usr/local/etc/my.cnf を /usr/local/share/mysql/my-*.cnf から適当に選んでコピーしてきます。
   • 古い環境の /var/db/mysql/my.cnf の内容も必要に応じて確認してください。
4. my.cnf の [mysqld] [mysqldump] [mysql] に以下のような設定を足します。
   • [mysqld] には old-passwords と default-character-set = ujis と skip-character-set-client-handshake を追加します。
   • [mysqldump] には default-character-set = ujis と skip-character-set-client-handshake を追加します。
   • [mysql] には default-character-set = ujis を追加します。
5. /usr/local/etc/rc.d/mysql-server start
6. バックアップした古い sql データを ujis として新しいデータベースに import します。
   • mysql --default_character_set=ujis -u root < backup.sql
   • [mysql] に default-character-set=ujis の指定をしているからオプション指定は不要のはずではありますが……。
7. もしも 'Specified key was too long' と言って怒られることがあったら、CHAR の長さの扱いが変わったせいで MySQL の主キーの長さ制限 に引っかかっています。backup.sql を手でいじって、適当に長さを調節してください。
   • ujis は1文字で最大3バイト必要な文字コードとして認識されていますので、主キー制限の1000バイトを3バイトで割った333文字以下に主キーが収まるようにテーブルの定義を調節してください。
   • 適当に調節したら、インポートにもう一度挑戦です。
8. mysql データベースが古い形式だということもありますし、念のため一度 mysql_upgrade を叩いておきましょう。
   • mysql_upgrade --force --default-character-set=ujis -uroot
     • 権限情報のリロードのタイミングによっては、引数に -p'昔のDBから引き継いだDBのrootパスワード' も必要な場合も。
9. これでエラーが出なければ、万事問題なしです。念のため、一度、mysql-server restart をしておきましょう。

ハマりポイント

古い /var/db/mysql をそのまま持ってきて上げようとするとドツボにはまります。

その場合、default_character_set を binary にするか、ujis にするかという2択の選択肢があり、ネット上の他のサイトではそれぞれでうまく行ったという報告がありますが、使い込まれた Xoops の DB は両方でうまく行きません。

• default_character_set を ujis にした場合。
  • CHAR() のバイトサイズが変わった関係で、データ変換の際にデータが欠落する場合があります。
    • mysql_upgrade 時に Data truncated for column 'ASIN' at row 1 のような警告が出ます。
    • ちなみに、INSERT しようとしたデータとデータベースで文字コードがあっていない場合はこの際にまた別のエラーが出ます。文字コードの確認は念入りに。
    • mysql_upgrade 前に CHAR のサイズを調整する mysql_change_char_len.sh というシェルスクリプトが公開されていますので、これを使うという手はありますが……。

• default_character_set を binary にした場合。
  • 確かに、CHAR() のバイトサイズが変わって変換でエラーが起こることもないですし、文字コードが合わずに捨てられるという問題も起こりません。
  • しかし、Column '%s' cannot be part of FULLTEXT index のようなエラーが Xoops の story や bb 周りのテーブルで出ます。文字コードが binary なのが原因で、ujis などにすれば問題はでなくなります。

ということで、どちらを選択しても無事に DB はアップデートできません。

いったん sql 文として export してから import し直すのが一番柔軟だ、というお話でした。