[hackers-jp: 84] Re: Fw: Proposals for PITR

[Y.Shimada]

島田@storgate です。

　睡眠不足はつらい。若さにはかてな〜い・。

本件、以下の2点についてですよね。。
　(1) DB インスタンスが受け取った SQL をリストとしてロギングする。
　(2) DB インスタンス内で処理された結果（アボートしても）ロギングする。

一般的な「ログ」とは(2) の事で、永安さんの「広い意味解釈」でのロギング
は(1),(2) を含んでいるといえます。

　ここでリカバリの話なのですが、(1)で、特定Checkpoint から障害でダウン
した時点まで（または、任意時点まで）保存されたSQL を再実行することで、
ロールフォワード（もどき）をおこなうと、石井さんが指摘(#81)された点など
により、データベース内部は、別のものになってしまう可能性が多々あります。

　Oracle（DataGuard ?）はログをレプリケーション DB に転送し、そのログ
から、SQL を生成、再適用などという事ができますが、本来のレプリケーション
ではログを再適用が必須で、ログから回答されたsqlの再適用は、厳密に一致
しなくてもよいデータベースの複製で使用すると。。
（タイムマシンで過去に戻り、人生をやり直す。。。なんてケースか？）

　この機能は、現実では、渡辺さんの例のような事例があり（便利な点も
多々あります。、、できれば、私も欲しいと思う）。

　しかしながら、PITR を厳密にデータベースのリカバリとしてとらえ、
SQLの実行結果（物理データベース内部を更新するために生成されたデータ）を
整合性をもって、確実に保存する。。通常のログ（Archive log/REDO log)
そにて、そのログから、ディスクメディア障害があっても、確実にインスタンス
停止時点まで、処理結果をもどす。とするべきと思います。

(1) の方式のリカバリは、PITR とは、別の hegehoge プロジェクトとして、
実装したほうが良いように思います。

On 2004年 2月 14日 , at 09:03, Hideyuki Kawashima wrote:

> snaga> イメージとしては、Parserを通った後にWALバッファに突っ込んで、
> snaga> COMMIT時にDISKに書き込み、という形になるかと思います。
>
> Parser通る前じゃない？ Parser通ったら、executorが食べやすいように表現
> が変換されてしまうのではないでしょうか。外してたらすみません。
> するとpostgres.c:2017 pg_exec_query_stringあたりかと思うのですが、
> どうでしょう。(はじめてこの辺読んでるので自信ないですが...)
> ＃7.3.1です
>
> てことはSQLをXLogInsertに渡すってことですね。
> そうすると、XLogRecordのRmgrid変えるくらいでいけますかね...
> リカバリ時の動作も少し変える必要ありますね。どうでしょうか...
>
───────────────────────────────────────
　　    Y.Simada    Storgate Co., LTD.   +81-3-3718-4330
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣