[hackers-jp: 100] Re: [HACKERS] PITR Functional Design v2 for 7.5
SAKATA Tetsuo
sakata.tetsuo ＠ lab.ntt.co.jp
2004年 3月 11日 (木) 08:08:29 JST
こんにちは。坂田＠横須賀です。
先日、井久保さんから投稿があった、Point Intime Recovery に関する
Simon Riggsさんの基本設計書の訳を見直して、多少手を入れたものを投稿します。
修正箇所は、欄外に ** をつけてあります。
また、<>でくくった箇所は坂田がつけた注釈です。
------------------------------------------------------------------------
現在、PostgreSQLは完全なPITRではない障害回復機能を提供している。
このドキュメントで、PITRに含まれる現状のrobustな形を拡張する設計を示す。
以前のPITRで実在するもの一つはrobustなものなのであり、今回の設計は、最終
的なコーディングが実行される前に、このような形態や挙動が[HACKERS]の厳格さ
に従うパッチとしてあらかじめ提供される。実際のところ、この作業を行うことは
現状からかけ離れたものではない。それゆえ、以前の設計に注意を向ける。
皆様のコメントに感謝します。よろしくお願いします。Simon Riggs 第2版。
Review of current Crash Recovery
現在の障害回復機能の確認
障害回復は、WALのロギングあるいはxlogを使うことによって提供されている。
xlogはトランザクションがコミットとして認識される前にすぐにディスクに書き
出される。xlogは、既知のスタート地点からのいかなる更新もロールフォワード
するのに十分なREDO情報を含んでいる。
既知のスタート地点はまた、clogとして知られているファイル構造の中に、その
トランザクションが完了したトラックを保持することによって記録されている。
また、clogはトランザクションのコミット時にディスクに書き出される。
更新されたデータのページはディスクにすぐには書き戻されない。障害から回復
ために取得されたxlogとclogの中にエントリーがあるために、その必要がない。
頻繁に発生する完全な各チェックポイントプロセスが生成され、そこで、ディス
クに戻されるべき更新された（もしくは「ダーティな」）データページとの完全
な同期がみたされる。
チェックポイントが完了すると、最後のトランザクションidがマスタとしてxlog
に書き出され、clogファイルを最後のトランザクションidにします。
チェックポイントの頻度はコントロール可能である。更新されたデータ **
ページは、bg_writer(もしくは"lazy writer")と呼ばれるバックグラウンドプロ
セスによってディスクに書き戻され、それによりチェックポイントの大きな負荷
を軽減する。
障害回復において、データベースファイルは完全であることが求められるが、
最新である必要はない。postmasterが再起動するとき、postmasterは、最新のチェ
ックポイントを通過したトランザクションidが何がであったかを見つけるために、
clogをチェックする。これを使うことで、postmasterは、その時点でチェックポ
イントによって書き出されたマーカまで利用可能なxlogファイルをスキャンする。
システムが最適な時点へと進める間じゅう、REDOエントリ実行が、できる限りの
データページに再適用される。
もし適切なxlogが利用不可能な場合、リカバリは全く不可能である。
initdbに続いて実行することで、少なくとも一つのxlogが存在する。xlogに新た **
なデータが書き込まれると、要求に応じて新しいファイルが再び割り当てられる。
チェックポイント実行の結果として、障害回復のためxlogがいつ必要でなくなるか
の時刻も存在する。各チェックポイントで、必要とされないxlogが存在すると、
最後のxlogはリサイクルされるか削除される。xlogは「キューの先頭」に戻って
リサイクルさると、ファイルを定常的に削除したり生成したりする必要がなくなる。
ファイル数の上限は事前に割り当てられるログ<の数>として保持される。 **
すなわち、この上限値は設定可能である。上限に達したとき、xlogは再利用さ **
れず削除される。結果として、xlogの数は時間経過の中でかなり変化する。しかし、
大部分は、xlogの大体の定常状態の数を維持す。それゆえ、予想されるような定常
的な空間の利用状況も保持する。
もし、利用可能な空間が一杯でxlogが書き出されなければ、xlogの書き込みに依存
したトランザクションは、コミットすることができないし、空間の利用状況が軽減
される間、後に続くトランザクションもまたコミットできない。現在、これは
pg_xlogディクショナリの中にある利用可能なディスクスペースにもとづいて、各ト
ランザクションのサイズに上限を課している。
xlogは比較的大容量で、clogは比較的小容量である。clogにおける空間条件の超過は
典型的には起こりにくいものである。
障害分析:
- トランザクションが失敗するなら、xlogへコミットされる変更はなく、clogエン
トリはトランザクションが失敗したことを示すだろう。
- トランザクションが成功するなら、変更はxlogへコミットされ、clogエントリは
トランザクションが成功したことを示すだろう。
- もしxlogディレクトリがいっぱいになるか、他の理由で書き込みできない場合、
PANICが発生する。
- もしclogディレクトリがいっぱいになるか、他の理由で書き込みできない場合、
PANICが発生する。
Point in Time Recovery (PITR)
PITR機能は、障害復旧が不可能であるような状況であっても可能になるように、既存
の障害復旧機能を拡張する形で設計される。そのような状況とは:
- データベースオブジェクトが削除された
- ロールフォワードリカバリが可能なほど十分なxlogがない
- データベースファイルが不完全で、ロールフォワードを行う前に完全に置き換える
必要がある
これらを行うためには、リカバリのためにシステムの完全な物理的バックアップが
必要である。
テーブルスペースが有効になっているなら、個々のテーブルスペースの復元と修正も
できなければならない。さらに、xlogは通常のxlogファイルシステムの外部のアーカ
イブ先に移動することも必要になるだろう。
PITR 提案する解決策
提案する解決策は、プログラムコードの変更と追加を最小限に抑えながらPITRを
行うために、既存の障害復旧検知機能とロールフォワードロジックを直接利用す
る。これを可能とするために、フルバックアップはデータベースが開いているか
あるいは運用中に実行される必要がある。このバックアップにはすべてのデータ
とclogsを（そしてどんなテーブルスペースや利用されている論理的なリンクも）
含んでいなければならない。
xlogsは、バックアップを開始する前の最後のチェックポイントから指定された
「リカバリポイント」あるいはxlogsの終端までが、連続的に利用可能である必
要がある。
完全なPITR解決方は多くのコンポーネントから成り立つ:
1. xlogの保管
2. 指定時間へのリカバリ（RPIT）
1. xlogの保管
市場には、完全な物理的バックアップと個別ファイルの保管機能を提供する広範
囲のバックアップとリカバリ（BAR）製品が、オープンソースと商用ライセンスの
プログラムの両方で存在する。PostgreSQLの広範な採用を促進する最もよい方法は、
これらの製品のいずれかと組み合わせてでもこれを可能にすることである。これを
目指して、PostgreSQLと外部の保管プログラムとが調和した方法でxlogsのバック
アップを可能とするためのPostgreSQL保管APIが定義される。
保管APIはPostgreSQLサーバ内に直接実装される必要があるだろうし、コピーでき、
よりいっそう広く利用されされることを可能にするAPIのリファレンス実装も必要
だろう。リファレンスAPIはそのリリースを主流のPostgreSQLコードに入れるため
に、APIの働きが十分にテストされることを可能にしなければならない。
1.1 XLogArchive API
1.2 pg_arch: 簡単なxlog保管ツール
1.1 XLogArchive API
1.1.1 XLogArchive Initiation
このAPI は、PostgreSQL の提供する全ての xlog がアーカイブされている
必要があることを仮定している。xlog のシーケンスに切れ目があると、
アーカイブ全体を与えても、最後のバックアップから後方に向けてリストア
するためのものとしては、使い物にならないということになる。
PostgreSQLサーバが開始したとき、wal_archive_policyパラメータの値をチェック
し、それに応じてアーカイビングを有効／無効にするだろう。
このパラメータはサーバの開始時のみ変更することができる。（これが要求される
のは、各xlogアーカイビングの初期ステップはバックエンドによって実行されるか
らである；もしこれがブート後に変更可能だと、個々のバックエンドが
wal_archive_policyをオーバーライドし、アーカイブしないように選択することが
可能になるかもしれない。その変更は、その選択をしたユーザだけでなく、システム
全体とすべてのユーザに波及する。）
コンパイラ指示語を利用することはあまり魅力的と取られていない。なぜなら、
アーカイブポリシーは、個々のデータベースの操作上／業務上の判断であり、DBMSを
実行可能にする開発者の活動によって決まるものではないからである。
外部アーカイバがPostgreSQLより前に起動するか、その後すぐに起動するかは
定義されていない。２つはアドミニストレータの命令によって一緒に動作すべき
であることは明らかに意図されている。 **
このちょっとした明快さの欠落は、スタートアップが自動ブートシーケンスで起動
する場面に際して、サブシステムのスタートアップ順序がOSによって保障されない
かもしれないことを許容することを意図している。
また、PostgreSQLとアーカイバ間の起動時間の多様性を許容する；アーカイバは、
即時で立ち上がるかもしれないし、新しいテープのロードのようなマニュアル処理が
間に入るかもしれない。
アーカイバは、PostgreSQLがシャットダウンしたとしてもhaltする必要はなく、 **
そうすることも、そうしないことも出来る。 **
例えば、１つのアーカイバが複数のpostmasterを同時に処理するのが望ましい **
かもしれない。というのも、アーカイバはデータディレクトリを含むPostgreSQLに**
関する多くの情報を保持しているので、PIDファイルを簡単に読むことができ、 **
もしそう選択するならpostmasterをモニタすることができるからである。 **
<だから、アーカイバはシャットダウンすべきではない> **
この領域ではAPIの追加の必要はない。
その結果、PostgreSQLとアーカイバの間には、他のクライアント／サーバAPI
（libpq, tcp/ip, JDBCなど）にあるような「接続」に関するコンセプトが何もない。
なので、接続もなければ切断もない。
同様に、この段階では設定／解除の環境もない。
1.1.1 XLogArchive API 仕様
(PostgreSQL ->) XLogArchiveNotify(xlog)
(<- Archiver) XLogArchiveXlogs()
(<- Archiver) XLogArchiveComplete(xlog)
(PostgreSQL ->) XLogArchiveBusy(xlog) returns ARCHIVE_OK or BUSY
xlogへの書き込みが次のファイルへと移るとき、古いファイルはクローズされる。
この時、xlogファイルを移行するきっかけとなったPostgreSQLバックエンドは次の
関数を呼ぶ。
XLogArchiveNotify(xlog) は TRUE もしくは FALSE を返す。
TRUE は、アーカイバがその通知を受け取る必要はないけれども、処理の成功を
知らせるものである。FALSE は、この局面が起こるべきものではなく、それでも
なおアドミニストレータが要求したアーカイブプロセスが起こしたものなので、
PANIC状態だとして処理の失敗を通知するものである。（この訳怪しい）
呼び出しは個々のユーザのバックエンドによって起こされるので、この呼び出しが
最小限度の時間で起こされ、また外部アーカイバに依存しない形で起こされることが
できるようにすることが重要である。例えば、呼び出しは非同期となる。
１つの呼び出しが他の呼び出しの実行の前に完了しないことが可能にもかかわらず、
２つのバックエンドがまったく同時にこれを呼び出すことはない。
同時に処理中の複数の呼び出しが、別々のxlogがアーカイブの準備ができたと知ら
せるはずなので、論理ロックを用意する理由がない。（この訳怪しい）
通知呼び出しは複数呼び出しを同時実行できるように書かれるべきである。
例えば、クリティカルセクションやシングルスレッドがあってはならない。
最初アーカイバはwaitループ内で起動され、XLogArchiveXlogs()を発行して **
XLOGの一つのファイル名あるいはNULLを取得するように定期的に起動<wake> **
される。 **
もし、xlogファイルがアーカイブされるのを待っているならば、アーカイバは
このAPIコールを使うことによって、xlogの名前に気づくだろう。もし、一つ以上
のファイルがアーカイブ可能であるなら、それは無視されるだろう。もし、アーカイバ
がマルチスレッドであるなら、XLogArchiveXlogを再び実行する前に
XLogArchiveCompliteが実行されるのを待つ必要はない。
アーカイバはpg_xlogディレクトリを訪れるために取得したxlogの名前を使うこと
ができる。そして、安全と考える場所へxlogをコピーする。これはその要求を満足
させるために実行し、アーカイバは以下の関数をコールする。
XLogArchiveComplete(xlog) はSUCCESS,ALREADY_NOTIFIEDとSEVERE_FAILUREを返却する。
SUCCESSは成功の通知を示しており、必ずしもアーカイバ自身はこれを受け取る **
必要はない。 **
ALREADY_NOTIFIED はXLogArchiveCompleteがすでにこのxlogのためにコールされ **
ていることをあらわす、エラーを示している。これは複数のアーカイバが **
アクティブであるか、このアーカイバがすでにArchiveCompleteを実行して、
二度目の実行すべきでないxlogに対して、実行をかけようとしているかである。
SEVERE_ERROR は失敗を示している。アーカイバは状態を確実にするため複数回この
操作をリトライするようにリクエストされる。そして、状況を正すために人的な
アラートをあげる。処置はあとに続く対処のため、再びこのコールをリトライ
しなければならない。
これは、非同期コールであり、postgresqlがこの通知をすぐに受け取るという
期待はできない。アーカイブコピーの処理がシングルスレッドであるに違いないとか
アーカイバがファイルを利用可能にするためにファイルをコピーしなくてはなら
ないといった仮定はない。アーカイバはアドミンストレータによてリードオンリー
アクセスを与えられた仮定される。というのは、直接的なセキュリティ権限の結果
として以外、xlogはコピーのために利用可能であるべきでない。xlogは任意の方法
でアーカイバによて削除や変更がされるものではない。アーカイブする時間は
固定された時間であるという仮定はないが、アーカイバが常に可能な限り高速に
ArchiveCompleteをコールし、ファイルのコピーを最善の努力をして作ることが
強く望まれる。テープやネットワーク越しのコピーは時間的に相当のバラツキを **
生じることは認識している。物理的なテープメディアの交換が生じたり、 **
バンド幅の優先順位などが発生するためである。
もし、各種の予定された遅延、あるいはこのプロセスにおけるいくつかの **
一般的な遅延の発生があるなら、アーカイバはtwo-stageプロセスの実装を強く促す。
これは外部のアーカイブの発生の前に同じシステム上の他のディレクトリとして、
コピーファイルを一貫して配置することである。
標準的にxlogは削除を考慮されている。たとえば、チェックポイントの後、
postgresqlチェックポイントプロセスはXLogArchiveBusy(xlog)をコールし、
ARCHIVE_OK, BUSY もしくはSEVERE ERRORを返却する。
ARCHIVE_OKは成功を示し、アーカイブの完了と今、xlogがpostgresqlにより削除
できることを示す。
BUSYはアーカイバがarchivercomplete<というメッセージ>を通知しておらず、
従って、xlogファイルはまだ削除できないことを示している。
この関数を特定のxlogに対して何度も呼び出すと、連続してFALSEを受け取ることも
ありうる。どのxlogに対してであっても、一度、TRUEを受け取れば、それ以上
同じxlogに対して呼び出しても新しい情報は増えない：この時点では
TRUE/FALSEの意味は定義されていない。
SEVERE_ERRORはBusyであるとも何とも情報がなかったことを示す。
これは非同期呼び出しなので、PostgreSQLはxlogがアーカイブを完了するのを
待つわけではない。これは、今のところ、同時に<複数>呼び出されそうもない。
なぜなら、チェックポイントプロセスが呼び出すからである。
XLogArchiveFreeそれ自体は、pg_xlogディレクトリからxlogを削除してはならない。
既存のxlogの削除・再利用の仕組みは、PITRが既存のクラッシュリカバリ
ルーチンの動作に干渉しないように利用されるだろう。
このアーカイブAPIはPostmasterごとに1つのアーカイバだけが動作できる設計である。
もし、2つ以上のアーカイバが互いに独立に動作すると、特定のxlog<のアーカイブ
に関して>最初にXLogArchiveCompleteを呼び出したアーカイバが、PostgreSQLに
対して、そのファイルの削除・再利用を許可することになる。
xlogファイルに対して複数のアーカイブコピーが必要なら、1つのアーカイバが
複数のコピーを扱えるようにするべきである。
1.1.2 XLogArchival API Failure analsys
障害が起こる条件についてはおおむね説明したので、 **
(それらの)振る舞いについて注意すべき点を書いておくのは有益だろう。
アーカイブを作成するには、通常、xlogをスイッチするよりは時間がかかる、
というのも(アーカイブには)xlogのデータが含まれているからだ。
これらの時間的関係を分析してみよう。
Tcは、PostgreSQLが「xlogがアーカイブ可能である」と通知してから
そのxlogを再利用しようとするまでの時間とする。
(XLogArchiveNotifyからXLogArchiveFreeがきちんと動作するまでの時間)
Taは、アーカイバが通知を受け取ってからアーカイブを完了するまでの
時間である(XLogArchiveNotifyからXLogArchiveCompleteまでの時間)
Nxは、xlogの数。
Ncは、xlogファイルシステムの容量をxlogファイルの数で表したもの。
Ta>Tcが成り立つなら、ファイル数Nは増加していく。
だが、xlogへの書き込み率が一定であるとすれば（大雑把に言って、
トランザクションの頻度が一定であれば)、Nxが増えるにつれて
Tcも増加していくと見込んでいる。
Tcが増加するにつれて、Ta=Tcが成り立ち、Nxが増加して定常的あるいは
決まった限界となるNcに達するような点<Ta, Tc, Nxの組み合わせに>が
あるはずである。
Nc<Nfが成り立つなら、すべては順調であるが、Nc>Nfならばスペースを
使い切る条件が成り立ってしまう(別の言い方をすれば、スペースを使い切る前に
到達できるような定常状態はないということである)。
# Nf は未定義ですが、文脈からは「xlogが格納されているファイルシステムの **
# 容量を見るのが妥当だと思います。 **
スペースを使い切る条件は、以下のような2つのケースで生じうる。
1. xlogファイルシステムが一杯になる際に遅延がある。
2. xlogファイルシステムが一杯にするような、システム上の遅延がある。
(1)はアーカイブプログラムで予防するしかない。あるいは、アーカイブプログラムを
制御するプロセスによって。
(2)は以下のいずれかで防止できる。
(i)すべての遅延を監視して報告する
(ii)いずれかのxlogに関して一定回数以上XLogArchiveFreeがBUSY状態を返すか、
または、一連のxlogの呼び出しの最初の呼び出しでBUSYが返ったら、
警告"WARNING"を発行する。
PostgreSQLのチェックポイントプロセスは、チェックポイントを発行するごとに
起動されるため、ケース(2)を解消するのは厄介である。というのも、複数の
チェックポイントプロセスの間で状態に関する情報を維持できないからである。
一連のチェックポイントプロセスから参照できるように、共有メモリや
ディスクファイルを利用するようにやり方を変えることも可能であろう。
PITRが、xlogディレクトリのスペース不足を来たした場合には、Crash recoveryと
まったく同様に振舞う。なぜなら、同一のコードになっているからだ。
この振る舞いは、"Fail Safeモード"として運用するためのものである。
<システム>管理者は、PostgreSQLが最終的にクラッシュすることなく、
動作を維持し、logファイルを削除することを選択できることを望むだろう。
この選択肢が選ばれ、「かつ」完全な物理的バックアップが利用できない
ならば、コミット済みのトランザクションが復元できないという破滅的な
危機に直面している。<それゆえ>管理者以外の人が、このような選択をし、
「ログを削除する」という最後の手段に訴えることは適切ではないと考える。
ここまでの所、複数のチェックポイントにまたがるようなバックアップ
<の生成>がうまくいくかどうかは定かではない。もし、個々のテーブルスペースが
異なるチェックポイントに対して同期しているのであれば、うまくいくと
期待できるかもしれない。
1.1.3 XLogArchival API の実装
このAPIの定義は実装とは分離している。こうすることで、将来より良い
実装が出てきたときに対応しやすくなるし、また、特定の移植先や
アーキテクチャ向けのカスタマイズもしやすくなる。
この最初の提案では、ファイルの有無とファイルの拡張とを利用して、
PostgreSQLからアーカイバへ情報を伝達するという単純な方式である。
これは、pg_xlogやpg_clogの同レベルであるpg_rlogという名前を
つけたディレクトの中に置くだろう(r は英語のarchiveを発音するときの
最初の強音節の音である)。
別のディレクトリを使用することで、セキュリティのコントロールとアーカイバの
振る舞いをコントロールできる: もし、セキュリティの設定が正しくできて
いかなったとしても、アーカイバは、PostgreSQL の重要なディレクトリに、
ファイルを作ったり消したりすることはない。いつも、PostgreSQL だけが、
recycling や removal によってxlog のデータを削除する。
XLogArchiveNotify(xlog) 関数は、TRUE か FALSE を返す。
そして、<XLOG>.fullと呼ばれるファイルをpg_rlog ディレクトリに書き出す。
ここで、<XLOG> は、現在PostgreSQL がxlog に使用しているパターンの
ファイル名である。
ファイルは、<XLOG> と Date/Time の情報を含んでいる。正しく書き出されたら、
TRUE を返し、そうでなければ、FALSE を返す。
アーカイバは、pg_rlog ディレクトリをスキャンする。もし、.full と表示
された rlog が見つけたら、rlog のエントリを <XLOG>.busy にリネームし、
そして、アーカイブの場所に移すために xlog を pg_xlog ディレクトリに、
rlog のエントリ名と同じ名前でコピーする。
XLogArchiveComplete(xlog) は、SUCCESS, ALREADY_NOTIFIED, SEVERE_FAILURE を
返す。これが完了したとき、rlog のエントリを <XLOG>.done に変更する。
すべてOK なら SUCCESS を返す。もし、rlog のエントリがすでに <XLOG>.done
になっていたら、アーカイバは ALREADY_NOTIFIED を受け取る。
XLogArchiveBusy(xlog) は、ARCHIVE_OK, BUSY, SEVERE_FAILURE を返す。
<XLOG>.done が存在したらARCHIVE_OK を返す。この状態なら <XLOG> は、
再利用や削除が可能である。
もし、まだ <XLOG>.busy が存在したら BUSY を返す。また、<XLOG>.full
が利用可能でなければ、SEVERE_FAILURE を返す。
# <XLOG>.full が見つかったときはどうする？？？
Src/backend/utils/guc.c コンフィグパラメータを追加するために編集する。
Src/backend/access/transam/Xlog.c は、PostgreSQL 側の関数を実装するために
編集する: XLogArchiveNotify(xlog) と XLogArchiveBusy(xlog)
libpgarch.c
アーカイバ側のAPI関数のCの実装を行う:
XLogArchiveXlogs() と XLogArchiveComplete()
1.2 pg_arch: 簡単なxlog アーカイブツール
Src/tools/ will に次のものを追加する:
pg_arch.c
これまでに定義したAPI を使うために、libpgarch.c を使った、シングル
スレッドプログラムである。そして、pg_xlog から別ディレクトリへ
コピーを作る簡単な機能を提供する。このプログラムは、アーカイブされた
ファイルを監視しながら待ち続ける: つまり、これはファイルフィルタの
ようなプログラムではない。
これは、テストなどの目的で foreground のプロセスとして動くこともできる。
しかし、background プロセスとしても動くように設計されていなければなら
ない。主に、(システムブートに続いて、サービスの自動スタートのような
メカニズムを通して) postmaster の起動と同時に実行される。
pg_arch は２つのパラメータを持つ:
-D <data-file> は、個々のPostgreSQLのインスタンスのルート
-A <archive directory>
2. 特定時刻へのリカバリ [Recovery to Point-in-Time (RPIT)]
リカバリのターゲットは、これらのオプションがある
2.1 ログの最後までリカバリを行う (つまり最後の時間)
2.2 利用可能なオンラインログの最後までリカバリする
2.3 チェックポイントが実行された時間か、指定された時間より前の最後の
チェックポイントの時間へリカバリを行う
管理者は、pg_xlog のディレクトリに 責任をもって xlog のアーカイブを置く
必要がある。これは、手動または自動で起動される外部のアーカイバによって
提供される機能かもしれない。もし、この時点で何らかの誤りがあったら、
管理者は、再度適切なxlogを選択しなおして、再実行すればよい。
リカバリを試みることができる回数が制限されてはならない。
2.1 ログの最後までのリカバリ
デフォルトのオプションであり、現在の PostgreSQL に何の変更も加える必要はない。
アーカイブ API は、このオプションを使ってテストしてよい。
2.2 利用可能なオンラインログの最後までリカバリする
これは、postmaster のコマンドラインのスイッチで利用可能になる。
これは、受け取った利用可能なログがなくなるまで xlog のロールフォワードを
実行し、postmaster はシャットダウンする。
これは２つの方法で利用できる:
- xlogアーカイブ が利用可能なディスクスペースを広げるとき:
このモードで実行することによって、管理者はバッチの中でPostgreSQL
をリカバリできる。
最後のバッチまできたら、コマンドラインのスイッチは必要ない。
# つまり、ディスクにアーカイブファイルがのりきれない場合など、
# このモードで、分割してリカバリを実行する
2.3 RPIT
リカバリパラメータを受け付けて、その時間までリカバリ進めたらリカバリを
中止する機能を追加する。
3. 将来の拡張について
先に1.1.3で述べた実装は改善しうるものであるし、アーカイブプログラムの
構成方法に合わせて異なる実装もありうるだろう。
一般的な通知(notification)のインタフェースが提案されるかもしれない。
もし、それが利用できれば、アーカイブAPIはそれを利用して、もっと直接的な
やり方で書き換えられるだろう。この問題は、本開発で考慮の外ではある。
このようなAPIがあれば、企業向けの先進的なストレージ管理システムにも
容易に組み込めるXBSAやNDMPといったクライアントアプリケーション
<を実現する際>の基盤として利用することもできるようになるだろう。 **
# XBSAは、X/Openの規格、"X/Open Preliminary Specification: **
# Systems Management: Backup Services API (XBSA)"のこと。現在は廃止? **
# NDMPは "Network Data Management Protocol"の略。 **
# IBMのTivoli Storage Manager にある機能で、NASを使って **
# ファイルのバックアップを取得する機能らしい。 **
<EOF>
------------------------------------------------------------------------
以上です。
--
坂田 哲夫＠NTT サイバースペース研究所
sakata.tetsuo _at_ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.
hackers-jp メーリングリストの案内