[hackers-jp: 164] Re: [HACKERS] PITR Recovery

2004年 6月 16日 (水) 09:31:11 JST

Hackers のみなさま；

坂田@富士山が見える横須賀です。

PITRでの、リカバリ時の指定方法について、Riggsさんから提案が出ていますね。
軽く訳してみました。

-----------------------------------------------------------------------
Simon Riggs wrote:

> ...on the assumption we now have archived xlogs, how do we do recovery?
> 
> Default is to put all xlogs back into pg_xlog and then let recovery do
> its work...though clearly we all want finer specification than that.

xlogが全てアーカイブされていると仮定して、どのようにリカバリしたら良いだろうか?

デフォルト時の動作は、全てのxlog(ファイル)を pg_xlog に戻して、
(通常の)リカバリを実行することだが...明らかに、コレよりはもっと
細かい指定ができることが望ましい。

> Based upon all our discussions to date...I propose to:
> 1. put more verbose instrumentation around recovery, so we can see how
> recovery progresses and calculate an estimated recovery time
> 2. put in a recovery control command
> 3. put in a validation step that will check to see whether there are any
> missing transaction log files in the sequence of xlogs available

これまでの議論に基づいて、以下のように提案する。
1. リカバリでの操作に関して、多数の情報を出させ、それを見て
　　リカバリの進捗を知ると同時に、所要時間を見積もれるようにする。
2. リカバリの制御コマンドを入れられるようにする。
3. 利用できる一連のxlogの中で、トランザクションログファイルの欠落がないか
　　確認するステップを入れる。

> The recovery control command would:
> - read the file DataDir/recovery.conf (placed there by DBA)
> - parse out an SQL-like command string
> ROLLWARD object target finalaction;

リカバリ制御コマンドは
　－(DB管理者が設定する)DataDir/recovery.confを読み込み、
　－以下のようなSQL風のコマンドを解釈する。
　　　ROLLWARD object target finalaction;
	(ROLLWORDはROLLFOWARDのミスだと思われる)
> e.g. 
> ROLLFORWARD DATABASE TO END OF LOGS;
> (is the current, and would be default, behaviour if file absent)
> 
> ROLLFORWARD DATABASE TO TIMESTAMP '2004-06-11-23:58:02.123' EXCLUSIVE;
> 
> ROLLFORWARD DATABASE TO END OF LOGS THEN PAUSE

例：

ROLLFORWARD DATABASE TO END OF LOGS;
(現状は、この振る舞いであり、デフォルト時の動作および、
　(設定)ファイルがないときの動作)

ROLLFORWARD DATABASE TO TIMESTAMP '2004-06-11-23:58:02.123' EXCLUSIVE;

ROLLFORWARD DATABASE TO END OF LOGS THEN PAUSE

> SYNTAX
> object = DATABASE (default) | TABLESPACE
> target = END OF LOGS (default)
> 	| TO TIMESTAMP 'yyyy-mm-dd-hh:mm:ss.sss' edge
> edge = INCLUSIVE (default) | EXCLUSIVE
> finalaction = THEN START (default)| THEN PAUSE
> 
> -object refers to the part of the database (or whole) that is to be
> recovered
> -target specifies whether to stop, and what test we will use
> -edge refers to whether we use <= or < on the test for target
> -finalaction refers to what to do when target is reached - the purpose
> of this is to allow recovery of a database to occur when we don't have
> enough space for all of the xlogs at once, so we need to do recovery in
> batches.

構文規則

object = DATABASE (default) | TABLESPACE
target = END OF LOGS (default)
 	| TO TIMESTAMP 'yyyy-mm-dd-hh:mm:ss.sss' edge
edge = INCLUSIVE (default) | EXCLUSIVE
finalaction = THEN START (default)| THEN PAUSE

　－objectはリカバリすべきデータベースの一部(もしくは全体)を指す
　－targetはどこで(リカバリを)停止すべきか、(そのために)どのような
　　テストを使うかを指定する
　－edgeはtargetに対して適用するテストが <= であるか < であるかを
　　示す
　－finalactionはターゲットに到達したら何をすべきかを指定する。
　　その狙いは、一時的にxlogのためのスペースが不足しているときに
　　バッチによるリカバリが必要となるときでも、リカバリを可能にする
　　ことである。

> When recovery is complete, recovery.conf would be renamed to
> recovery.done, so it would not be reactivated if we restart.

リカバリが完了すると、recovery.conf は recovery.done に名前が
変わり、仮にこの後でリスタートしてもリカバリが再実行されないようにする。

> In time for beta freeze, I think it is possible to do a limited subset
> of the above:
> - implement DATABASE only (whole instance, not specific database)
> - implement END OF LOGS and TO TIMESTAMP
> - implement THEN START only
> - implement using simple C, rather than bison

βフリーズまでの間に、上記の機能のうち、以下に挙げる限られたサブセットを
組み込むまでしかできないだろうと思う。
　－ DATABASE だけが有効。(DBインスタンス全て、個々のデータベースは指定できない)
　－ END OF LOGS と TO TIMESTAMP
  － THEN START のみ。
　－ bisonは使わず、単なるCでインプリメントする。

> Reading the command is probably the hardest part of this, so agreeing
> what we're working towards is crucial. We're out of time to redesign
> this once its coded.

コマンドを読み込む部分が、もっとも大変だと思う。だから、何を作るかについて
合意しておくことが重要になる。一度コーディングしてしまったら、再設計する
時間がないからだ。

> If the hooks are there, we can always code up more should it be required
> for a particular recovery...

一旦フックを組み込めば、特定のパターンのリカバリのために、コードを追加する
ことはいつでもできるだろう。

> The syntax is very like DB2, but is designed to be reminiscent of other
> systems that give you control over rollforward recovery (e.g. Oracle
> etc), allowing those with experience to migrate easily to PostgreSQL.

提案した構文規則は、DB2に良く似ているが、(Oracleのような)ロールフォワードが
可能な別のシステムを髣髴とさせる箇所もあり、そうしたシステムの経験者の
PostgreSQLへの移行をようにするだろう。
(原文のbutは文法ミスかも)

> Implementation wise, I would expect all of this code to go in xlog.c,
> with the recovery target code living in ReadRecord(). This would delve
> inside each record to check record type, then if it is a COMMIT record
> to look further at the timestamp then either implement this COMMIT or
> not according to INCLUSIVE/EXCLUSIVE.
> Only the txn boundary records have time stamps... 

実装面に関しては、このコードはリカバリの改造の対象になるコードである
ReadRecordを含む、xlog.c収めることとしたい。この(ReadRecord)は個々の
(ログ)レコードを見て、レコードのタイプをチェックし、それがCOMMITレコードで
あれば、そのタイプスタンプを読み取って、INCLUSIVE/EXCLUSIVE(ディレクション)に
したがって、それをCOMMITする(しないこともある)。
トランザクションの境界となるレコードだけが、タイムスタンプを持っているからである。

> As Tom points out, we can't accept normal SQL at this point, nor can we
> easily achieve this with command line switches or postgresql.conf
> entries. My solution is to just use another .conf file (call it what you
> like...)
> 
> Comments?

既に、Tom (Lane)が指摘しているように、この時点では通常のSQLを受け付ける
ことも、コマンドラインやpostgresql.confのエントリで動作を切り替えることも
できない。わたしの提案は、別に.confファイル(あなたのお好みで呼べばよい)を
使ったものである。

コメントがあれば。
> Best Regards, Simon Riggs
敬具。

-- 
坂田 哲夫＠NTT サイバースペース研究所
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.