Kazuho@Cybozu Labs

開発側の注意すべき点

• 同一OSの場合でも環境によって最適な同期手法は異なる
• したがって、同期手法はハードコードすべきではなく、設定値として取り扱うべき
• Windows 向けのプログラムにおいては、(UPS を使っている場合に高速な同期が不可能な) 非同期モードによる CreateFile を使うべきではない^注4

運用側の注意すべき点

• データベース等の同期手法を正しく設定すべき
• UPS つきなのに F_FULLFSYNC しちゃってるとか
• また、使用するソフトウェアでどのような同期手法が選択可能かを確認した上で、運用環境を構築すべき
• たとえば、FlushFileBuffers を呼び出しているミドルウェアを使う場合は UPS よりもバッテリバックアップキャッシュつき RAID の方が、速度向上の度合いが大きくなる可能性が高い

　ところで、HDD の内蔵キャッシュと UPS による永続性の確保と、RAID のバッテリバックアップキャッシュによる永続性の確保を、同列に扱うことに問題があったりするんでしょうか？　自分の理解の範囲外に何かそのような要素がひょっとしたらあるのかも、と、上の表に色を塗りながら、そこが一番気になりました。

H2 Database の作者さんによると、
http://www.h2database.com/html/advanced.html#durability_problems
fsync() は（まちがいなく、fdatasyncを含むと思いますが）ディスクの回転数分しか fsync() を発行できないくせに、実際に、電源コードを引き抜いてテストしてみると、多くのハードディスクは実際には書き込みが完了していない、と主張していますが、実際どうなのでしょう？

具体的にどこの部分の表現でしょうか。自分にはそのような記載のある箇所は見つけられませんでした。

http://www.h2database.com/html/advanced_ja.html#durability_problems
面倒なので、日本語訳の方です。

> 完全な永続性とは、全てのコミットされたトランザクションは電源異常に耐えられる、ということを意味します。いくつかのデータベースは、永続性を保証すると主張していますが、このような主張は誤っています。永続性テストはH2、HSQLDB、PostgreSQL、Derbyに対して実行されました。これらの全てのデータベースは、時々コミットされたトランザクションを失います。

と

> デフォルトでは、MySQLはそれぞれのコミットごとに fsync を呼びます。それらのメソッドのうちひとつを使用している時、毎秒およそ60件だけが実行され、使用されているハードドライブのRPM速度と一貫性があります。残念ながら、FileDescriptor.sync() または FileChannel.force() を呼んだ時でさえもデータは常にハードドライブに存続するとは限りません。なぜなら、多くのハードドライブは fsync() に従わないからです: http://hardware.slashdot.org/article.pl?sid=05/05/13/0529252 内の"Your Hard Drive Lies to You" をご覧下さい。Mac OS X では、fsync はハードドライブバッファーをフラッシュしません: http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html そのため状況は混乱していて、 問題があることをテストは証明しています。

あたりです。

少なくとも、H2 Database さんの文章を誤読していないつもりですが、主張していることが本当かどうかは、実際に実験してないので、よくわかりません。

あと、okuさんの、

> データベース等のソフトウェアは一般に、停電やOSのクラッシュ時にデータが破壊されないよう HDD へデータ保存が完了したか確認しながら処理を行うようになっています。

ですが、UPSを使っていても、サーバー本体の電源が故障したら「停電」になりますし、UPS使っていても「OSのクラッシュ」対策になりませんし、UPSを使っている場合に、青にしてしまうのは、まずいと思います。まぁ、そもそも、ハードディスクに書き込み命令を送っても、実際に読んでみないと（ベリファイやコンペアしないと）、本当に書き込まれたかなんてわからないわけですし、こんなの程度問題ですけどね。

あと、これまた、さらにちゃんと確認していないんですが、複数のスレッドがから並列で書き込んでいる時、どうも、MySQL はディスクの回転数以上のトランザクションを裁けるような気がします。ディスク1回転あたりに、2つ以上の書き込みをまとめて行うことをしていると思います。本当に未確認ですいません。

> 面倒なので、日本語訳の方です。

ありがとうございます。確かにそのように読めますね。にわかには信じがたい話ですし、仕様としてプラッタに同期する方法を使っているのにデータロスが発生するとしたら、それは (OSかHDDかRDMSの) バグなんじゃないかと思いますけど。
自分が知っている範囲だけでも、Windows 2000 の特定バージョンでの FluhWriteBuffers の誤動作 (本文のリンク参照) や、SQLite のジャーナルが消失する問題 (ディレクトリエントリを fsync してなかった) といったものもありましたし、実際に試してみて適切な手法を取るしかないんでしょうね。

次に、UPS がある場合に、ディスク内のキャッシュへの書き出しを青色にしている件ですが、

> UPSを使っていても、サーバー本体の電源が故障したら「停電」になりますし、

これは例えば RAID のバッテリが故障した場合にも同じ議論が成り立ちますよね。永続性の確保の有無という意味では、系内の故障は考えず、系外からの電源断に対処できているかだけを検討すればいいと思っています。一方で、故障率や SPOF をどうするかといった、高可用性の議論は別に必要だとは思います。

> UPS使っていても「OSのクラッシュ」対策になりませんし

OS がクラッシュしても HDD のライトキャッシュは消えず、順次プラッターに書き込まれると理解しているのですが、違うのでしょうか？　実はここが一番自信のないところなのですが...

> 複数のスレッドがから並列で書き込んでいる時、どうも、MySQL はディスクの回転数以上のトランザクションを裁ける

はい。InnoDB はそのような機能 (Group Commit と言ったはず) を実装しています。また、OS と HDD 間の通信のレベルで見ても、同期書き込みが複数回できることもあります。