coreserverのマイグレーションに対応

先日、value-domain(GMO)のレンタルサーバー「coreserver」が新しい環境に移行しました。
これに伴い、パッケージのバージョンが変更になりましたが、特に大きな問題は発生しませんでした。

ただひとつ、MySQLのバージョンが5.1から5.7に上がったため、5.6から実装されたコマンドにパスワードを入力するとアラートが表示される問題。
cronでデータベースをダンプしているので、毎日毎日アラートがメールで飛んで来るように。

根本から断つために、シェルを若干調整しました。

#!/bin/sh

# cron shell for coreserver
cd /virtual/user_name/public_html/domain_name/admin
/usr/local/mysql/bin/mysqldump database_name --user=user --password=password > mysql/mysqldump

exit

となっていたところを、

#!/bin/sh

cd /virtual/user_name/public_html/domain_name/admin
/usr/local/mysql/bin/mysqldump --defaults-extra-file=./.mysql.user database_name > mysql/mysqldump

exit

と変更します。

「.mysql.user」というファイルを参照していますが、この内容は

[client]
user     = user
password = password

となります。

これでcronが走る毎にメールが飛んでこなくなりました。
でめたしでめたし。

データベースの正規化に悩む

色々入り組んだデータベースになりますと、正規化の基準となるカラムを間違えるととんでもないことになったりします。
今回はさほど問題ではないのではなく、設定を基準にデータベースを正規化したものの、やはり後で色々と問題になりそうなので、データベースを基準に作り直すことにしました。
更新時にはサービスをとめないといけないのですが、リスクを抱えたまま運営を続けるよりはよいでしょう。
で、そのサービスとは印刷受注サイトプリントライのことです。

Windows7にもてあそばれる

一通り入れた後に、MySQLを入れ忘れたのに気がついて入れてみたところ、PHPからアクセスできない。実際にはphpMyAdmin3からアクセスできない。エラーメッセージも表示されず、1分ぐらい待たされて方真っ白な画面になってしまう。
コマンドからは問題なくアクセスできるものの、mod_phpからアクセスできない。
このときのPHPは5.3.3、MySQLは5.1.50(64bit)でした。
httpd.confやphp.iniやmy.iniをいじっては見たものの改善せず。
ここで不貞寝しました。

そして翌日。
まず最初にMySQLをノーマルからエッセンシャルに入れ替えたり、32bitにしたりバージョンを入れ替えたりしたけれどうまくいかない。PHPを入れる際にVCのライブラリを更新したのでそれに問題があるのではと考え、仕方がなくWindows7を入れなおすことに。

とりあえずWindows7を上書きでインストールしなおしてみたところ、前のシステムが複製されて残っていて、とっても気持ちが悪い状態に。仕方がないので改めてパーティションをフォーマットしなおしてから、改めて入れなおすことに。

まず最初にMySQL5.1.50(64bit)を入れて、次にApache2.2.16、そしてVCを更新せずにPHP5.3.3を入れなおしてみたところ、やはり現象は同じ。
ここでふとPHPのインストーラーにVCの対象を選択する新しい項目があったのを思い出して、前のバージョンで試してみようと思い立ちました。
PHP5.2.14を入れなおしたところ、zlib.dllがないといわれるのでネットから拾ってきて放り込んだところ、難なく起動。

問題だったのはPHP5.3.3.
データベースとの連携が高いはずのPHPで、このような障害が発生しました。
何でもかんでも組み込み関数にしてしまったPHPの成れの果てを垣間見た気がしました。

結局それ以外では、ActivePerlを64bitにするとMinGWと連携できないようなので、32bitで入れなおしたぐらいで、特に大きな問題もなく開発環境は整いました。
あとはデータを移していくだけです。これもかなり面倒なのですが。

MySQLで特定のデータベースをダンプする

MySQL Ver14.12 Distrib 5.0.45, for redhat-linux-gnu (i686)での話です。
データベースをコピーしようともって、cronで保存してあったDUMPファイルをインポートしようと思ったらファイル形式が違うといわれてショック。
これじゃバックアップの意味ないじゃん?
原因は・・・なんだろ?
とりあえず目先の問題を解決することにして、mysqlをダンプします。

mysql -u root database > dump.sql


データベースがでかいほど時間がかかるのはお約束です。

さて、お次はインポート。
正確にはインポートとは言わないらしいけど。

mysql -u root database < dump.sql


これもデータベースが大きいとそこそこ時間がかかります。
つまり、<と>を切り替えるだけでok。

これで、めでたしめでたし。

mod_perlでライブラリが見つけられない

通常のCGIでは問題なく動くスクリプトを、いざmod_perl環境下に置いたとたんに動かなくなるのはよくある話。
変数や配列などの初期化がいい加減で、どんどん肥大化してしまうのは、日ごろから心がければ何とか回避できるものの、いまだに良くわからないエラーが次のもの。
「Undefined subroutine &ModPerl::ROOT::ModPerl::Registry::」
Registryの後には実行されるスクリプトのパスが入る。
つまり、mod_perl環境下で実行ファイルはモジュールとして扱われる。
このため、ライブラリやモジュールの読み込みまわりで順番がおかしくなり、ファイルが見つからないといわれることになるのだ。

この文字を検索すると以下のようなサンプルが表示される。

LoadModule perl_module modules/mod_perl.so

PerlRequire "/path/to/startup.pl"


SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI


# in startup.pl, i have this:
use lib "/path/to/webObjects";
use Apache2 ( );
use ModPerl::Registry ( );

use Carp;
use CGI;

use lib_webObjects;
1; 


startup.plを読めばいいらしいのだが、そのとおりにやってもサーバーエラーになる。Apacheのエラーログを見ても同じメッセージか載ってないので、構文エラーという前に効果がないのかもしれない。
日本語のサイトがひとつも見つからないときは、英語が苦手でなければと常に思う。
しかし、このエラーも.htaccessと、httpd.confにディレクトリで指定したときでは挙動が違うような気がする。
Apache起動時に読み込ませた環境では、実行時に読む.htaccessと違うのはもちろん当たりまえなのだが、解決方法が見つからなければいくら原因がわかっていてもしょうがないのである・・・

さてはて、いったいどうしたものか。
最悪の場合、ライブラリをやめて1つのファイルに全部詰め込む荒業に出るか?

今日買った本

久しぶりにジュンク堂池袋店へ行きました。
レジの応対が不気味なほど丁寧で、しかも対応してくれた娘がちょっと好み入っていたのでドキドキ・・・ってオヤジですな。

さて、衝動買いした本はこれです。

奥付では「2009年1月25日 初版」となっている新刊です。
ポケリ(ポケットリファレンス)シリーズは、まれに外れがあるけども割とお買い得なシリーズです。
ずっと使い続けているMySQLへの理解を深めるために、この1冊を衝動買いしてしまったというわけです。
さて、活用できるかどうかは自分の腕次第・・・