無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

29.5. WALの内部

WAL は自動的に有効になります。 WAL ログが必要とするディスク容量を確保すること、そして必要ならばチューニングすることを除いては( 項29.4 を参照)、管理者は何もする必要はありません。

WAL ログは、データディレクトリ以下の pg_xlog ディレクトリに、通常16メガバイトのサイズを持つセグメントファイルの集合として格納されています(ただし、このサイズはサーバ構築時の --with-wal-segsize というconfigureオプションで変更できます)。各セグメントは通常8キロバイトのページに分割されます(このサイズは --with-wal-blocksize というconfigureオプションで変更できます)。 ログレコード用のヘッダは access/xlog.h に記述されています。 レコードの内容は、ログの対象となる事象の種類によって異なります。 セグメントファイルは名前として 000000010000000000000000 から始まる、常に増加する数が与えられています。 数字は巡回しませんが、利用可能な数字を使い尽くすには非常に長い時間がかかるはずです。

主要なデータベースファイルが置いてあるディスクとは別のディスクにログを置くと利点があります。 これは pg_xlog ディレクトリを別の場所に(もちろんサーバを終了しておいてから)移動し、主データディレクトリ以下の元々の場所から新しい場所へのシンボリックリンクを張ることによって可能となります。

WAL の目的である、確実にデータベースレコードが変更される前にログが書き出されることは、実際にはキャッシュにしかデータがなく、ディスクには格納されていない時にが格納に成功したとカーネルに虚偽の報告を行うことによって失われる可能性があります。 そのような状況では、電源が落ちた際に、復旧不可能なデータの破壊が起こることがあります。 管理者は、 PostgreSQL WAL ログを保持しているディスク装置がそのような嘘の報告をしないように保証するべきです。( 項29.1 を参照して下さい。)

チェックポイントが実行され、ログが吐き出された後、チェックポイントの位置は pg_control に保存されます。 したがって、リカバリの開始の際は、サーバはまず pg_control を読み、次にチェックポイントレコードを読みます。 そして、チェックポイントレコード内で示されたログの位置から前方をスキャンすることでREDO処理を行います。 データページの内容全体は、チェックポイント後の最初のページ変更時にログ内に保存されますので( full_page_writes パラメータが無効にされていないという前提です)、そのチェックポイント以降に変更された全てのページは一貫した状態に復旧されます。

pg_control が壊れた場合に備え、ログセグメントを逆順に読み(すなわち新しいものから古いものへと)、最終チェックポイントを見つける方法を実際には実装した方が良いと思われます。 まだこれはできていません。 pg_control はかなり小さなもの(1ディスクページ未満)ですので、一部のみ書き込みされるという問題は起こりません。 またこの書き込みの時点では、 pg_control 自体の読み込みができないことによるデータベースエラーという報告はありません。 このため、 pg_control は理屈では弱点ですが、実質問題になりません。


powered by SEO.CUG.NET