立った！mysql が立ったよ！

まぁ、クララなんですけどね。

今回のエラーのキーワードは何と言っても

081111  1:56:26  InnoDB: Error: the OS said file flush did not succeed
081111  1:56:27  InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.

の部分なのでとりあえず perror をしてみる。

[travail@mina]/home/travail% perror 5
OS error code   5:  Input/output error

うん、あまり意味ないですね。
でも、flush はキーワードだと思うので google さんに聞いてみると。
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.4 InnoDB 起動オプションとシステム変数

ここの、「innodb_flush_method」がとっても怪しいですよね。

もし fdatasync  (デフォルト)に設定すると、InnoDB  はデータとログ ファイルの両方
をフラッシュする為に fsync() を利用します。
なんたらかんたら・・・

「データとログファイルの両方を」なんてよくわからない言葉を使っていますが、データとはバッファのことではないかと。innodb_log_buffer_size で指定している、あのバッファ。
ログファイルはログファイルですよね。innodb_log_file_size で指定しているやつかな。
で、僕は innodb_flush_method を /etc/my.cnf で指定していなかったのでデフォルトの fdatasync で動いていたみたいなんですね。
なので、「innodb_flush_method = O_DIRECT」 とかに適当に設定したら立っちゃったんですよねぇ、mysql。
なんでかは知らない。知らないけどこれは忘れないように書いておきたいと思います。

innodb_flush_method には下記のものが設定できる。

• fdatasync
• バッファとログファイルを flush するのに fsync(2) を使用する。（fdatasync って言ってんのに fdatasync(2) を使っていない）
• fsync(2) はファイル更新の際にメタ情報（stat）を更新する。fdatasync(2) は更新しない。
• そもそも、どのフラグ立ててファイルをオープンして fsync(2) してるのか不明。
• O_DSYNC
• バッファとログファイルを flush するのに fsync(2) を使用するのは fdatasync を指定した場合と一緒。ただ、バッファ、ログファイルを O_SYNC でオープンする。
• O_DSYNC と言っているものの、O_DSYNC フラグを立ててファイルをオープンするわけでなない。
• O_SYNC フラグでファイルをオープンすると、書き込み（write(2)）が終わるまで必ず呼び出しもとのプロセスをブロックする。
• O_DIRECT
• バッファとログファイルを fsync(2) で flush。O_DIRECT フラグを立ててオープン。
• ファイルに対する I/O のキャッシュを最小化しようとする。
• このフラグを使用すると一般的に機能が低下する。
• 「O_DIRECT でいつも困るのは、インタフェース全部が本当にお馬鹿な点だ。たぶん危ないマインドコントロール剤で頭がおかしくなったサルが設計したんじゃないかな」 -- Linus

innodb_flush_method を O_DIRECT にして何でクララが立ち上がったかはわからないけれど、O_DIRECT はやめて fdatasync か O_DSYNC にしようかと思います。
クララが立ったのはいいのですが5,000万レコードのレプリケーションは見事にずれていたので週末にでも復旧作業しないといけません。やれやれです。

あ、それと記事を書いている途中に「公開状態」がいつの間にか「公開」になっているんですけど誰ですか？