[pgsql-jp: 36572] PostgreSQLの持続性 (was Re: PostgreSQL のデータ領域を NAS 上にした場合)

[SAKATA Testuo]

こんにちは。坂田＠PostgreSQLのしくみ分科会、です。

# NASの件とは、直接関係ないのでSubjectを修正しました。

Katsuhiko Okano wrote:
> 岡野と申します。
> 
> "Kouji Ito" wrote:
> 
>>PostgreSQLって１回のトランザクションを行うにあたって、必ずディスク
>>にデータを書き戻してるんでしょうか？

1回のトランザクションをコミットする毎に、そのトランザクションによって
為されたDBの更新情報を「ログファイル」(*)に書き出し、フラッシュします。

(*)岡野さんの説明も参照。

> チェックポイントのタイミングとコミットのタイミングは同じとは限らないので、
> １回のトランザクションを行うにあたって、必ずディスク
> にデータを書き戻してるとは言えないと思います。

上記の引用部は、

・ログに関しては、誤り(コミットした時点で、当該トランザクションによる
　変更情報は全て必ずログファイルに書き込まれる)
・DBファイル(バッファの内容)に関しては、正しい(チェックポイント、
　bachground write、buffer replacementなどがあるまで、バッファの内容は
　DBファイルには書き戻されない)

と言えます。

> また、トランザクションの途中でも(他のトランザクションから見えない形で)
> ディスクに書き込まれている状態もあると思います。
> 
> チェックポイント・・・メモリ上のデータを全てディスクに書き込む
> コミット・・・・・・・トランザクションを終え、他のトランザクションからも
> 　　　　　　　　　　　見えるようにする。
> と思っています。

コミット時の動作については、半分誤っています。
コミットが正常に終了しても、トランザクションの隔離水準が
serealizable であれば、(定義により)他のトランザクションからは見えません。

>>一旦、共有メモリ内で書き込みが完結（クライアントにトランザクション終了を
>>通知）して、非同期に共有メモリの内容をディスクにフラッシュしているんだと
>>すると、ローカルディスクであっても、マシンのクラッシュなどで、ＤＢの整合
>>性が保てなくなるケースがありそうな気がします。

知られている限り、

・クラッシュ後のリカバリについては、
　・ログファイル自体が破壊されることなく
　・DBファイル自体も破壊されていなければ
　正常に行われ、クラッシュ前にコミットしたトランザクションによる
　変更結果は、クラッシュ後にも全て正しくアクセス出来ます。

ということが言えます。逆に、上記の2つの条件を満たしつつ、
リカバリに失敗するケースがあれば、バグです。

> トランザクション終了の前にログとしてディスクに記録しておく
> という仕組み(Write Ahead Log)により、必要なファイルが残っていれば
> 整合性は保てるんじゃないかと思います。
> (データとログは別な意味で使ってます)
> #この辺はPostgreSQLの実装に詳しい方のフォローが欲しいところですね。

詳しくはないのですが、フォローがないようなので出てきました。
上記の「バグ」の件では、実際には(マイナーなケースで)障害が
生じることがあるかも知れません。識者のフォローをお待ちしています。

PostgreSQLのリカバリに関する話題は、
PostgreSQLのしくみ分科会でも取り上げられたので、
以下の資料もご覧ください。

・Logのしくみ
  http://www.postgresql.jp/wg/shikumi/doc/20040721105406.shikumi_040726_logging1.pdf
・PostgreSQLにおけるリカバリ処理
  http://www.postgresql.jp/wg/shikumi/doc/20040721163403.recovery_20040726.pdf

そのほか、PostgreSQLのしくみ分科会では、これまでに発表してもらった資料を
以下のサイトで公開しています。併せてご参照ください。

http://www.postgresql.jp/wg/shikumi/archive.html

以上、ご参考まで。
-- 
坂田 哲夫＠NTT サイバースペース研究所
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.