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

[井久保 寛明]

井久保です。

このプロポーザルに Tom Lane 氏からレスがついていますね。

チェックポイントを流したあと、tar をとれば、オンラインバック
アップ可能だということですね。[hackers-jp: 19] に書いた方法の
基本的な考え方はあっていたということみたいで。


On Fri, 13 Feb 2004 13:06:28 +0900
Satoshi Nagayasu <snaga ＠ snaga.org> wrote:

> PITRの新しいプロポーザル出ましたね。
> 
> --- Begin of forwarded message
> Date: Thu, 12 Feb 2004 23:59:43 -0000
> From: "Simon Riggs" <simon ＠ 2ndquadrant.com>
> To: "'Fred Moyer'" <fred ＠ redhotpenguin.com>, "'Bruce Momjian'" <pgman ＠ candle.pha.pa.us>, "'Marc G. Fournier'" <scrappy ＠ postgresql.org>, "'Tatsuo Ishii'" <t-ishii ＠ sra.co.jp>, <snaga ＠ snaga.org>, <austin ＠ coremetrics.com>, <pgsql-hackers-pitr ＠ postgresql.org>
> Subject: Proposals for PITR
> 
> 
> PITR for PostgreSQL 7.5+
> ===========================
> 
> I'm posting a few thoughts and plans on how to progress PITR. Initially,
> I'd suggest chewing through some ideas to get some direction and then
> split out some tasks to pursue individually or in teams.

<snip>

> --- End of forwarded message
> 
> 
> -- 
> NAGAYASU Satoshi <snaga ＠ snaga.org>



---------------------------------------------------------------------
Subject: Re: [pgsql-hackers-pitr] Proposals for PITR 
Date: Sun, 15 Feb 2004 13:13:04 -0500
Message-ID: <9293.1076868784 ＠ sss.pgh.pa.us>
From: Tom Lane <tgl ＠ sss.pgh.pa.us>

"Simon Riggs" <simon ＠ 2ndquadrant.com> writes:
> The general PITR recovery scenario requires:
> A - Take a full database backup
> B - Take regular log file backups
> C - Restore a full backup of a database.

pg_dump について、PITRに対してやることはない。PITR リカバリのシナリオ
は、物理ダンプに対して行うべきもので、論理ダンプについて行うべきです。
そうでないと、WAL での再実行はうまく動かないでしょう。

以前の議論での結論は、物理ダンプは単純に tar (または、同等のツール)で
$PGDATA を取りましょうということです --- pg_xlog は外すこともできますが、
ほかは全て必須です。
tar を実行する前に完了しているチェックポイントからの一連のログがあれば、
DBが生きている間に実行しても OK です。これを行うと tar アーカイブは
一貫性のとれてないスナップショットになってしまうので、直接使うことはできま
せん。しかし、tar アーカイブをロードして、tar を実行する前のチェックポイント
からWAL を再実行すれば、一貫性のあるDB に戻せます。
# tar が完了した後のチェックポイントからと書いてあったけど、それは間違い
# でしょう

それなので、A での問題は、tar の開始と終了を時間、およびそれに関連するWAL
の最初の時間を管理するソフトと tar があればいいことになります。
dumpの話をするより先に、B の解決方法 (不要になったWALを開放する) を考える
のは、良いと思います。

テーブルスペースの実装を考え始めると、より複雑になります。なぜなら、
アーカイブするテーブルスペースのツリーは、$PGDATA だけでないからです。
しかし、詳細の話をしているわけではないので、今は無視して良いと思います。


> We should assume that the system onto which the restore takes place is
> completely different from the system on which the backup was taken.
> 我々は、リストアの行われるシステムは、バックアップが行われてたシステムと
> 完全に異なると仮定すべきである。

バイナリ互換のあるサーバを使うので、そんなに違うことはない；
この方法では、マシンのアーキテクチャを越えることはできない


> - Add entries to WAL files so it contains enough information for
> recovery after a full backup
> This is assumed to be complete. [I'm not sure where the role of pg_clog
> is in all of this, so this may be a broken assumption.] Comments?

これは、大きな問題だと思っています。(ファイルの作成と削除の機能がありません)
これは、先週、私が適用したJ.R. Nield のパッチで解決されます。

> - Write application to archive WAL files to tape, disk, or network 
> Probably need to do first part, but I'm arguing not to do the copy to
> tape..

ユーザの提供するプログラムかスクリプトで何とか扱えないかと思っています。
最も必要なのは、アーカイバプログラムがいつどのWALセグメントファイルを
アーカイブするか判断させる、いいAPIを定義することです。

> B - Backing up WAL log files
> -Ordinarily, when old log segment files are no longer needed, they are
> recycled (renamed to become the next segments in the numbered sequence).
> This means that the data within them must be copied from there to
> another location
> 	AFTER postgres has closed that file
> 	BEFORE it is renamed and recycled

私の好みでは、WALセグメントが一杯になったらすぐに行うようにバックエンドを
変更し、テープなどにダンプする準備ができたとフラグを立てるのが良いと思う。
多分、これを実現する最も簡単な方法はセグメントファイル名を変更するだと思い
ます。"nnn" というセグメントファイルなら "nnn.full" にします。そして、
アーカイブプロセスがファイルのダンプを完了したら、ダンプしたことを
知らせます(多分、"nnn.done" のようにファイル名を変えれば良いでしょう)。
明らかに、フラグを立てる方法はいくつもあり、OS ファイル名の変更機能が最良の
方法とは限りません。

(a) 最新のチェックポイントより古くて、かつ、 (b) ダンプ済みになっているとき、
セグメントは再利用できるようになります。このアプローチでは、再利用
可能になるよりも前に、ファイルのダンプを始めることができます。
フラグを立てるメカニズムは、クラッシュしてリスタートしたとき、WALの再実行
中に、フラグの立てられたセグメントを見つけることができるものでなければなら
ない。


> Think about
> -what will happen if postgres tries to reuse file while we are still
> copying.

これは、問題ない；セグメントはリサイクル可能にならないと、再利用のター
ゲットにならない。


> -what will happen if copy fails?

これは、アーカイバの扱う問題です。WALセグメントファイルのためのディスク
領域を使い切ったら、重大な問題を引き起こします。それで、多くの場合は、
手動で問題を解決して、アーカイバを再起動することになります。


> -Manual indicates that current WAL format is bulky and would require
> some compressed format to be implemented. Initially, I suggest ignoring
> this and simply relying of OS or hardware/tape compression methods.

これは、完全にあとまわしにしていい話です。


> With full OS file backup, if the database is shutdown correctly, then we
> will need a way to tell the database "you think you're up to date, but
> you're not - I've added some more WAL files into the directories, so
> roll forward on those now please".

私の考えでは、シャットダウンしたデータベースのバックアップは含まれない
ので、これも問題ではないと思っています。バックアップされるのは、オンラ
インのDBです。それなので、postmaster は、必ず WAL のリプレイが必要だと
言うことを知ることができます。必要なのは、ログファイルが全て利用可能か
どうかということを知る方法です。ログがディスクスペースを上回った場合も、
完全に復元可能です。WAL の再実行を段階的に行う必要はあります。古いログ
セグメントを消したあとに、追加のログセグメントをロードして、再実行を
行えばいいだけです。

多分、postmaster のコマンドラインスイッチで実現できます。J. R. Nieldの
パッチは、"interactive recovery" バックエンドモード も実現いています。
私は、詳細までは好きでなかったのですが、基本的は考え方は、あながち間違
いではありません。

			regards, tom lane


---------------------------------------------------------------------

例によって、いい加減な和訳です。


前のメール([hackers-jp: 75])で、永安さんのメールを引用したときに、
プロポーザル部分を和訳に差し替えると言ういたずらしてたら、気付いて
いない人がいたみたいですね。

くだらないことして、ごめんなさい。


---
井久保 寛明 (Hiroaki Ikubo)
ＮＴＴデータ先端技術 (株) オープンソース技術部
E-mail: ikubo ＠ intellilink.co.jp (E-mail: ikuboh ＠ nttdata.co.jp)