最近は猫も杓子も「Key/Value形式のデータ格納形式で全てはバラ色に」「RDBは駆逐される」という論調ですよね。

K/VストアがRDB、スケールアウトかスケールアップ、どちらかというものではなく、個々の事情に応じて、適材適所だと考えますが。

GoogleのBigTableやAmazonのDynamoを引き合いに出して、色々といわれていますが、これらの事例は、彼らが彼らのサービス(使い方)を熟知したうえで、彼らなりの最適な技術を選んでこう組み立てた、という話であって(技術的には新しい話題ではない)、その事例が全ての事例に適用できるというものではないはずでしょう。
データバックアップにあたっての静止点の作成やリカバリの手法など、運用管理の部分まで全体をみながらきちんと議論されているのでしょうか。

元の記事(@IT内)にはこのようなことが書かれていますが、

「ビジネスモデル」?
うーん、、、

ただ、それまで問題なく読み書きできていたRAID 5ディスクアレイであれば、そういった「発見されないエラー」が発見されたとしても、データ保全は可能じゃないでしょうかね。だって、その部分はそれまで読み書きしてなかったんでしょうから。
もし、それまでにその部分を読み書きしていれば、何らかのエラーになったはずで、そういうエラーは、普通に監視していれば検出できます。

それまで当該セクタに読み書きできていても、突然読めなくなる(書き込みは成功する)のが、メディアエラーの怖さです。
リビルド中にメディアエラーを検出したセクタに、上位レイヤ(たとえばFS)から見て「有効」なデータが載っていないとは限りません。

RAID5ボリュームが縮退状態で運転していて、復帰動作(リビルド)中にメディアエラーを検出したときには、当該セクタのデータは復元できません。
予防保全はこれを防ぐための機能で、縮退状態で気づく(当該セクタを復元できなくなる)前にメディアエラーを潰しておくというものです。

RAID5って定期的に表面検査しないと「発見されないエラー」がトラブル時の再構築中に「発見」されちゃう。

この「発見されないエラー」というのは、メディアエラーのことでしょうか。

今回の件に関しては、縮退状態で稼働させていたRAID5ボリュームでHDD交換前に2点同時故障(切り離し)が発生し閉塞してしまったのか、それとも、HDDを交換し再同期中にメディアエラーを検出して「何か」がおきてしまったのか(閉塞やデータ不整合・破壊など、これはコントローラ次第)、そこまで具体的には発表されていないので、「何とも言えない」かと考えます。

一般論としてはメディアエラーの扱いによる問題というのは考えられると思います。
特に、ショボいRAIDコントローラ/ソフトウェアだと、何がおきても不思議ではないかと、、、

1日1回のバックアップのみってバックアップポリシーって実は最も脆弱で
障害やデータに問題が発生したことにその日のうちに気づかないと、バックアップ側にも障害時のデータが上書きされちゃうから無意味だったりするんだよね

バックアップウィンドウ(RPO)の話と世代管理の話が混ざっていませんか。

どこで・どういう障害ケースから・何を守りたいのかにより、それぞれに最適な組み合わせ・バックアップポリシーがあるはずです。

この製品(?)、(たとえばAmazonEC2のような)所謂クラウド側への/での deploy というところを強調(差別化)していらっしゃるようです。
http://www.venturenow.jp/news/2009/04/20/2040_006391.html

ただし本質的には、Server provisioning や、Autonomic Computing(IBM) といった分野のものであって、その視点で見れば、この分野の歴史は長く、先行している堅いプロダクトや技術(権利化された特許含む)が既に多数あると考えます。
(それをもってこの製品がダメと言うつもりはないのですが、ただこれを事業化するつもりであれば、パテントレビューなりきちんとしているのかなと、ちょっと気になります)

このDISKというのが、どのレベルのモノをさして言っているか/どの切り口から見ているのかにもよりますよね。:D

fsync()はOS内のライトバッファからOS外のデバイスに対する書き出し指示をおこなうものであって、デバイスへ書き込む(書き込み指示を出して完了応答を待ち合わせること)は保証されています。
(これがきちんとできていないのであれば、それは問題です)

ただし、デバイス内でのバッファードライトまで直接禁止するものではないので、仮にデバイス(たとえばHDD)内で揮発性のライトバックキャッシュが構成されていれば、突然の電源断でどうなるかはユーザにはわかりません。
(ドライバレベルでは、これをきちんと指示する仕組みはあります)

なので、エンタプライズ系のシステムでは、HDDのライトバックキャッシュ(WBC)をOFFにして使ったり、UPSをつけてWBC-ONでつかったり、ディスクアレイ装置側にNVRAMを搭載したりして、OS側に「書き込み完了」を返したときには、Stableであることを保証するようにしています。

元のACさんのコメントは、後者(デバイス内でStableなところにきちんと書かれることまで保証されるモノではない)、ということをおっしゃっているのだとおもいますが、ファイルシステムのレイヤの話(ここでのext4のコミットの話)と、デバイスの中の話は、どのレイヤの話を言っているのか、分けて説明しないと、周りの人が、びっくりしちゃいますよー。 :D

抜粋解説ありがとうございます、参考になりました。

> 一応、直後に書いたたように、
> >> Ext3においては、コミット間隔が短かったのでクラッシュした際のデータロスとかが比較的少かった。
> >> だけど、Ext4では、そのコミット間隔の長さに由来して、今迄存在したけど顕在化しなかったこの問題が浮上したと。
>
> なので、この問題自体は重要視されていなかっただけでずっと存在していたんでしょう。

おっしゃるとおりですね。
# これを「問題」ととらえるかどうかは、その人の立場/見方によりかわると思いますが、笑。

ここで話題になっている ext3やext4の「コミット間隔」は、ファイルシステム内でデータをバッファから書き出す定期実行間隔のことなので、仮にext4の60秒が5秒になっても、最後のコミットから事故までの間で2次記憶にはデステージされていないデータがある(かもしれない)ことにはかわらないです。

本質的に、ユーザが意図するようにバッファから書き出してもうらうには、a)ユーザが書き出しを指示するか(=fsync/syncなどを発行するか)、a)ユーザがバッファードライトの禁止を指示するか、しかありません。

アプリケーション側でデータ破壊の問題を何も考えず安直にやりたいのであれば、ライトスルーで書く(前述bの方法)のでしょうが、
でもそんなことをしていたら、IO性能は出ないので、「データの意味・整合性を知っている(自ら作り出している)」アプリケーション側で、意識的に整合性のポイントをつくって、使い分ける必要があります(前述aの方法)。
DBなど、性能と信頼性を要求するものは、こういうところまできちんと考えて設計しています(が、現実には、怪しいモノもありますが)。

なお、ext4でコミット間隔を長くした理由には、ext4がエクステント方式を採用していることも関係しています。
ext3などはブロック方式ですが、特に(DBなどの)巨大なファイルを作ったときなどはそのファイルを構成するブロックの間接参照が深くなりIO性能が低下する傾向にあります。

そこでext4はエクステント方式(連続するブロックを開始オフセット/長さで表現するデータ構造)としたことで、これを解決することを目指しています。
(エクステント方式はext4が初めてではありません)。
エクステント方式で性能を出すためには、できるだけ連続したブロックを割り当てることが大切ですが(フラグメンテーションの回避が課題になりますが)、そのためには、できるだけライトデータをバッファして、連続して一気に書き込むことが重要になり(これだけではないですが)、そのため、「意図的に」コミット間隔を長くとっています。

言い換えれば、コミットを(FS内で)乱発するのは、そもそもの設計の狙いに反しているので、そのあたりは慎重に考える必要があるでしょうね。
(ここの設計者の見極めが、今回のTruncate指定でのコミットのパッチにうまく現れていると考えます)

ちなみに、
ファイルを更新中にプロセス終了や電源断でデータ破壊というのは、(バッファが全く関係ないわけではないですが)本質的には別の話ですね。
これはバッファードライトでなくても起きうる話で。
(データの整合性がとれるポイントまでは)データを上書きしないように気をつけよう(CopyOnWriteしよう)、と。