[hackers-jp: 75] Re: Fw: Proposals for PITR
井久保 寛明
ikuboh ＠ nttdata.co.jp
2004年 2月 13日 (金) 20:43:52 JST
井久保です。
あれ？ このメール、まだ来てないですね。
取りこぼしたかな？
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+
> ===========================
>
> どのように PostgreSQL で PITR を実装していくかというプランと考えを投稿します。
> はじめに、方向性についてアイディアを練った後、個人やチームの仕事で取り組む
> 仕事に分割した方が良いと思います。
>
> リーダーシップ、絶対確実であること、現実性を要求していません。PITR に
> 対するここに示したものや他のアイディアを通して、一緒に作業ができれば
> 良いと思っています。どれかまたは全部に対するまたは、全く違った視点の
> コメントも歓迎します。
>
>
> このデザインやプランは、PGDG コミュニティのメンバーから出される
> より最近のデザインや考えと良く似ています。
> 全てのアイディアや訂正、部分的なコードは喜んで受け入れます。
> ここには、競争するものはありません。もし、あなたが先にやって
> それがうまく動けば、ビールをおごりましょう。
>
> 情報が送られてきたり、方向性が変更されたら、これをアップデートします。
>
>
> OVERVIEW
> PITR は、Point-in-Time-Recovery を意味します。そして、これは、現行の
> PostgreSQLの機能の拡張です。PITR を達成するためには、OS の特徴とdbms
> の特徴を合わせて考える必要があります。私が最も優先度が高いものとして
> 提案するのは、後者を整理して、OSが提供しているものを今さらやり直さな
> くていいようにすることです。
>
>
> OVERALL PITR REQUIREMENTS
> - データベースのフルバックアップ
> - 時系列に並べられる変更のバックアップは、フルバックアップを取った
> 時点からのロールフォワードを使うことで、目的の時間に戻すことがで
> きます。
> - 最良の方法は、多分、バックアップのタイプをプランを使ったものと構造
> を使ったアプローチの両方を実装した、バックアップ管理ソフトによって
> 提供されます。
>
>
> SUGGESTED IMPLEMENTATION GOALS
> 1. 正確なデータベースのPITR の実装
> 2. コードの堅牢性
> 3. 通常の(バックアップ)システムに対して、性能上の影響をゼロに近づける
> 4. 故障停止時間を最小にするために、リカバリ手段全体のパフォーマンスを
> 改善しておく。
> 5. 他の通常のPostgreSQL のコードに準拠する: Berkeley licence, ANSI C
> への準拠
>
> GENERAL PITR RECOVERY SCENARIO
> 一般的は PITR のリカバリシナリオは、次のようになる:
> A - データベースのフルバックアップをとる
> B - 通常のログファイルのログファイルのバックアップを取る
> C - フルバックアップをリストアする。
> もしこれができなければ、恥ずかしいですよ。もし失敗したら、うまく
> いくまで繰り返します。もし決してうまくいかなければ、運がなかった
> ということでしょう。
> これで成功して、DBの一部が壊れていたとしても、それがDBMSの重要な
> 場所(例えばシステムテーブル)でなければ、処理を続けることができる。
>
> D - ログレコードを全てリストアする。
> もしこれができなければ、データロストすることになります。
> うまくいかない場合は、動くようになるまで繰り返して下さい。
> いくらやってもうまくいかない場合、最新の状態ではないですが、
> すくなくともフルバックアップのところまでは、復旧できます。
> E - フルバックアップが取られた状態に、ログファイルを戻す。
> もし、こうならなかったり、エラーになったら、フルバックアップ
> を取ったときのログファイルの状態と一致していないということだろう
> その場合、フルバックアップを取った時点までしか復旧できないという
> ことになる。
> F - どの時点までリカバリを行うかを決定する
> G - リカバリを行いたいと決めた時点を指示する
> H - 戻したい時間まで、バックアップの時点からロールフォワードする
> もしログ壊れていて失敗したとしたら、入力を求められる
> - 壊れているところまで戻す
> - 諦めてできたところまでにする
>
>
> SUGGESTED FEATURES TO BE IMPLEMENTED
> PostgreSQL PITR チームが行うべきことは、B,E,F,G,H を提供する機能を
> 実装することである。
> 次の部分的な機能は、アーカイブの中にすでにある:
> A - pg_dump を行うか、DBをシャットダウンした状態で OS のファイルコピーを
> 使うことができる
> G - WAL の ロールフォワードは既に実行できる。しかし、ある時点で停止する
> ロジックが必要である
>
> ファイル操作を実装するのは、我々の役目ではない: バックアップとりストアは
> あとからいくらでも作りようがある。それなので、ユーザは要望を満たせる
> 好きな方法で データボリュームなどを取ればよい。
>
> 我々は、リストアの行われるシステムは、バックアップが行われてたシステムと
> 完全に異なると仮定すべきである。リストアされたデータベースを起動する前に、
> コンフィグファイルを書き換える必要があるかもしれない
> ほかにも、必要条件はありますか？
>
>
> COMPARISON WITH EXISTING TODO ENTRIES
> - フルバックアップのあとにリカバリに必要な情報を、WAL ファイルに追加
> するようにする
> これは、終わっていると仮定する。[pg_clog が このなかでどのような働きを
> するか分からないので、この仮定は崩れているかもしれない]
> 何かコメントありませんか？
>
> - WAL ファイルをテープやディスク、ネットワークにアーカイブする機能を書く
> たぶん、最初に行う必要がある。しかしテープにコピーするのは議論したくない
>
> - アーカイブ書込みのとき、チェックポイントの処理やWAL リサイクルの割込み
> をどうするか決めなければならない
>
> 要求事項は前述
>
> - pg_dump や tar のバックアップからリカバリを行い、WALファイルを特定の
> 時間にするユーティティを作成する必要がある
>
> 可能だと思うけど、最初に行わなくても良い。他から手をつけた方がよい
>
>
> SUGGESTED PHASING OF IMPLEMENTATION
> PITRを完全に動かすことに向けた、仕事の段階をここに示す。もちろん、
> 他の方法も可能ですが....
>
>
> Phase 0: 計画と議論。テストプランの詳細化も含む
>
> Thread 1
> Phase 1.1: OSイメージからのバックアップとフルリストアを実装する
> Phase 1.2: PITR の実装 (G の追加と H のための変更)
> Phase 1.3: WALの検査機能の実装(Fの改善)
>
> Thread 2
> Phase 2.1: pg_dump を使ったAとCの実装
>
> これを行うためには、多くの調査と議論が必要である。最も重要なのは、
> かなりの量の詳細でかなり立ち入ったテストを含むことである。
> 例えば、完全なDBを一掃してリストアを行うなど。
>
> これを読んで、私が大量のコードを削ろうとしていると思わないで下さい。
> 多くのいろいろな人の協力が必要です。とくに ベテランのPostgreSQL 開発
> 者の協力が必要です。
>
> 時間に対する計画はありません。正しく行うための時間が必要です。
>
>
> FEATURE OVERVIEWS & INVESTIGATIONS/IMPLEMENTATIONS REQUIRED
> B - Backing up WAL log files
> - 通常、古いログセグメントが必要なくなったら、それらは再利用される。
> (次の連番のセグメントになるように名前が変更される)
> これは、それらのログに入っているデータを別の場所に移さなければ
> ならないことを意味している。
> postgres が ファイルを閉じた後で
> 名前が変えられて再利用される前
> 正確に実行する機会の範囲に焦点を当てることが重要である。ファイルが
> コピーできることを識別できるしくみが必要で、それからファイルをロック
> してコピーする
> 考えるべきことは
> - コピー中にPostgreSQLが再利用しようとしたら何が起こるのか。
> コピーが完了するのを待つあいだ、postgres はハングする
> (これは、もしディスクフルでコピーがハングしたら、長い時間かかる
> かもしれない)
> これはすでにコードに入っているかもしれない。再利用のロジックは
> まで再利用できない条件を扱えるので。
> - この場合、read-only のクエリは実行できるのか？
> - コピーに失敗したらどうするのか？
> - 誰かコピーを行うのか？postmaster のサブプロセスを起動してコピーするか
> 別のプログラムを作るべきだろうか？
> - もしそのプロセスがスローダウンしたらどうなるだろうか？失敗したら
> どうすれば良いだろうか？
> - どのようにして、WALがコピー可能になったことを知らせれば良いだろうか？
> どのようにして別のアーカイブプロセスと通信したら良いだろうか？
> - マニュアルによると、現行のWAL フォーマットはかさばるのでなんらかの
> 圧縮フォーマットを実装すべきらしい。 最初は、これは無視して、
> OS やハードウェア、テープなどの圧縮にたよることにすることを提案したい
>
>
> E - ログファイルをバックアップ状態に準備する
> 正しくシャットダウンされたOSファイルのバックアップを使うなら、かなり
> 直接的にできる。
> - 何か問題がないか知るために、WAL ファイル名の使い方を調べる必要がある
>
> G - ある時間にリカバリするように、コマンドを実行する
> DBが正しくシャットダウンされていて、完全なOSファイルのフルバックアップが
> あるなら、DBに次のことを知らせる方法が必要である。「そのDBは最新の状態で
> あるが、実はそうではないと。 - あとからいくつかのWALファイルをディレク
> トリに追加した。従ってロールフォワードを実行し手ください」
> - いつ、そして、どうやってコマンドを実行するか決める
> - コマンドの構文はどうする？
> もし SQL 分にするならこんな感じになる
> RECOVER DATABASE TO TIME <TIME>
> リカバリが必要ない状態でも、リカバリモードにする新しいスイッチを
> postmaster につけることもできる？
>
> H - WAL のロールフォワードの修正
> ある時間までのロールフォワードは、かなり直接的に実装できる。
> 現行の実装では、１度開始したら、適用するファイルがなくなるまで実行し続ける。
> それで、単純に終了条件を変更すればよい。
> どこに時間の情報を保存すればよい？グローバル変数？ロールフォワードの
> コマンドが実行されたときのパラメータで渡す？
>
> A/C - pg_dump の使用
> pg_dump からのリストアの場合、pg_control は バックアップが取られた
> ときと同じ場所になっていない。
> 結果として、E のステップは フォールフォワードの開始場所を間違って認識
> してしまう。その結果、"cannot find correct log" というエラーメッセージ
> が出るか、不適切なWAL データを使ってロールフォワードしようとする。
> これについては、調査すべきであると言われるだろう。
> アイディアは：pg_dump を修正して、pg_dump 開始時点のトランザクションIDを保存
> する。そして、バックアップにその状態を反映するために、ダンプの最後のSQL 文と
> して、システムテーブルを変更する文を生成させる。
> 多分; 調査は必要である。このルーチンは国際言語の問題によって、複雑になるかも
> しれない、など。なので、フルバックアップの方法は、少なくともそれらを全て無視する。
>
> 他に我々が行うべきことはあるだろうか？
>
> どんな複雑な問題があるだろうか？
>
> = = = = = = =
>
>
>
> --- End of forwarded message
>
>
> --
> NAGAYASU Satoshi <snaga ＠ snaga.org>
---
井久保 寛明 (Hiroaki Ikubo)
ＮＴＴデータ先端技術 (株) オープンソース技術部
E-mail: ikubo ＠ intellilink.co.jp (E-mail: ikuboh ＠ nttdata.co.jp)
hackers-jp メーリングリストの案内