■2-10■ WALの詳細日本PostgreSQLユーザ会の仕組み分科会で発表したWALとPITRの資料とpgpool-IIのオンラインリカバリに関する資料がありますので、こちらも参照してください。 【2-09】ではWALの概略を解説しました。ここでは、より詳細な部分を解説します。 WALに関わるログWALが機能するには、WALログ以外にコントロールファイルとコミットログが必要です。 WALログ同様、コントロールファイルとコミットログもデータベースクラスタ下にあり、コントロールファイルの実体はglobalディレクトリ下にあるpg_control、コミットログの実体はpg_clogディレクトリ下のファイルです。 コントロールファイルコントロールファイル“pg_control”は、CHECKPOINTの情報を保持します。具体的には、最後にCHECKPOINTが実行された時刻、次のトランザクションID(XID)やオブジェクトID(OID)などです。バージョン7.3 から、コントロールファイルの内容を表示するコマンド“pg_controldata” が標準でインストールされています。次に、pg_controldataの実行結果を示します。 postgres> pg_controldata /usr/local/pgsql/data/ pg_control version number: 72 Catalog version number: 200211021 Database cluster state: in production pg_control last modified: 2003年03月17日 01時22分11秒 Current log file ID: 0 Next log file segment: 39 Latest checkpoint location: 0/26F73B98 Prior checkpoint location: 0/26EE0FEC Latest checkpoint's REDO location: 0/26F73B98 Latest checkpoint's UNDO location: 0/0 Latest checkpoint's StartUpID: 59 Latest checkpoint's NextXID: 375829 Latest checkpoint's NextOID: 427686 Time of latest checkpoint: 2003年03月17日 01時22分02秒 Database block size: 8192 Blocks per segment of large relation: 131072 Maximum length of identifiers: 64 Maximum number of function arguments: 32 Date/time type storage: Floating point Maximum length of locale name: 128 LC_COLLATE: ja_JP.eucJP LC_CTYPE: ja_JP.eucJP コミットログCHECKPOINT実行時に処理中のトランザクションについて、各トランザクションの状態(IN_PROGRESS, COMMITTED, ABORTED)をコミットログに保持します。例えば、SQL 文を実行するなどしてトランザクションを開始すると、共有バッファ内のCLOGにトランザクションIDと状態の組(XID, 状態)が記録されます。 トランザクションの状態は、処理中は“ IN_PROGRES ”、COMMITされると“COMMITED”、ABORTされると“ABORTED”となります。 CHECKPOINTの実行により、共有バッファ上のトランザクションIDとその状態をコミットログに書き込みます(【図.2-18】参照)。このデータは復旧時の再実行(Redo)を行うか否かを決定する際に利用されます。 図.2-18 トランザクションの状態をコミットログに書き込む 詳細なWALの動作データの更新と、CHECKPOINTの動作を詳細に観察しましょう。詳細な更新のシーケンスは次のようになります(【図.2-19】参照)。(1)トランザクションが開始されると、トランザクションID と状態“IN_PREGRES” を共有バッファ内のCLOGに記録します。 (2)次に、トランザクションログの書き込みと共有バッファ内のデータの更新を行います。1行更新するごとに「トランザクションログをWALバッファに書き込んで共有バッファ上のデータ更新」という処理を行います。 例えばテーブル中のデータを100行更新すると、この処理が計100回繰り返されることになります。 ここで、共有バッファがすでにデータで占められ、かつ共有バッファに存在しないデータを更新する場合は、近々に使用しないであろうデータをハードディスクに(非同期で)書き込み、空いた部分にデータを読み込んで更新します。 (3)WALバッファが溢れるか、トランザクションがコミットされた時点で、WALバッファの内容をWALログに書き込みます。 (4)CLOG内のトランザクションの状態を“COMMITED”に変更します(ABORTした場合は“ABORTED”です)。 (5)CHECKPOINT が実行されると、CLOGの内容をハードディスク上のコミットログに書き込み、 (6)共有バッファ内のデータをハードディスクのデータ領域に書き込みます。 (7)次いで、コントロールファイルを更新し、 (8)WALログを新規作成します(データの更新がハードディスクに反映されたので、今まで使っていたWALログが不要になったため)。 図.2-19 WALの動作
【2-09】で説明したとおり、WALログに記録されたSQL文を順次再実行(Redo)することで復旧を行いますが、その際、コミットログを参照しつつコミットされたものだけを再実行します。 [PREVIOUS][UP] |