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

18.5. ログ先行書き込み(WAL)

これらの設定をチューニングする追加情報は 項29.4 を参照してください。

18.5.1. 諸設定

wal_level ( enum )

wal_level はどれだけの情報がWALに書かれるかを決定します。 デフォルト値は minimal で、クラッシュまたは即時停止から回復するのに必要な情報のみ書き出します。 archive はWALアーカイビングに必要なロギングを追加し、 hot_standby は更にスタンバイサーバ上の読み取り専用問い合わせの情報を追加します。 このパラメータはサーバ起動時のみ設定可能です。

minimal 水準では、何らかの巨大な操作でのWALロギングは安全を期して省略されます。そうすることで、一連の操作をより高速にさせます( 項14.4.7 を参照してください)。 この最適化が適用される操作には以下のものがあげられます。

CREATE TABLE AS
CREATE INDEX
CLUSTER
同一トランザクション内で作成されたか、もしくは切り詰められたテーブルに対する COPY

しかしminimal WALはベースバックアップとWALログからデータを再構築するための充分な情報を持ち合わせていません。したがい、WALアーカイビング( archive_mode )とストリーミングレプリケーションを有効にするには archive または hot_standby 水準を使用しなければなりません。

hot_standby 水準においては、 archive と同じ情報がログ取得されるのに加え、WALから実行中のトランザクション状態を再構築するのに必要な情報が得られます。 スタンバイサーバ上で読み取り専用問い合わせを有効にするには、 hot_standby がプライマリサーバで設定され、 hot_standby がスタンバイサーバで有効になっていなければなりません。 hot_standby 水準と archive 水準を使用した場合にちょっとした計測可能な性能上の差異がありますので、実際に運用して問題が見つかった場合はご意見を聞かせてください。

fsync ( boolean )

このパラメータがオンの場合、 PostgreSQL サーバは fsync() システム・コールを発行したり、もしくはこれに相当する方法で( wal_sync_method を参照)更新が物理的にディスクに書き込まれたかの確証を得ようと試みます。 これは、オペレーティングシステムもしくはハードウェアがクラッシュした後、確実にデータベースクラスタを一貫した状態に復旧させることを保証します。

fsync を停止することはしばしば性能上の利益になるとは言っても、予期せぬシステム停止やクラッシュの際に回復不可能なデータ破壊になることがあります。 従って外部データから全てのデータベースを簡単に再構築できる場合のみ fsync を停止してください。

fsync を停止しても安全な状況の例としては、以下があげられます。 データベースが削除され、そして再構築されたデータの一群の処理のため、または頻繁に再構築され、かつフェイルオーバには使用されない読み取り専用のデータベースクローンに対し、バックアップファイルから新規データベースクラスタの初回読みを行う場合です。 高性能なハードウェアであるからと言って、 fsync を停止することは正当性を主張する十分な理由とはなりません。

fsync を無効(off)から有効(on)に変更したときの確実なリカバリに対しては、カーネル内の全ての変更されたバッファを恒久的ストレージに強制移動させることが必要です。 クラスタがシャットダウンしている間、または fsyncが initdb--sync-only の稼働しているか、 sync が稼働しているか、ファイルシステムをにアンマウントしているか、またはサーバを再起動しているかにより成し得られます。

多くの場合、致命的ではないトランザクションにおいて synchronous_commit を無効にすることにより、データ破壊の付随的危険性を伴うことなく、 fsync を無効にした場合に潜在する性能上のメリットの多くを得ることができます。

fsync postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。 このパラメータを無効にする場合、 full_page_writes も同時に無効にすることを検討してください。

synchronous_commit ( enum )

トランザクションのコミットがクライアントに "success" の表示を返す前に、WALレコードがディスク上に書き込まれるまで待つかどうかの指定をします。 有効な値は on remote_write local 、および off です。 デフォルトかつ安全な設定は on です。 off の場合、クライアントに成功を報告する時点とトランザクションが本当にサーバクラッシュに対して安全になるまでの間に遅延が発生します。 (最大の遅延は、 wal_writer_delay の3倍です。) fsync と異なり、このパラメータを off に設定することによって、データベースの一貫性が損なわれる可能性はありません。 オペレーティングシステムやデータベースのクラッシュにより最近コミットされたということになっているトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。 ですので、 synchronous_commit を無効にすることは、トランザクションの信頼性が確実であることよりも性能が重要である場合に有効な方法です。 詳細は 項29.3 を参照してください。

synchronous_standby_names が設定されていると、このパラメータもやはり、トランザクションのWALレコードが、スタンバイサーバに複製されるまでトランザクションコミットを待機するか否かを制御します。 on に設定された場合、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、記憶装置に既に書き込まれたことを確実視するまでコミットは待機は待機されます。 このことにより、プライマリおよびスタンバイがそれぞれのデータベース記憶装置の故障を被った場合を除いて、トランザクションが失われることはありません。 remote_write に設定された場合、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、スタンバイのオペレーティングシステムに書き出されたことを確実視するまでコミットは待機は待機されます。しかし、データがスタンバイの記憶装置に安定して書き込まれたか否かは必須ではありません。 この設定は PostgreSQL のスタンバイインスタンスがクラッシュしたとしても、データ保護を保証するのに充分です。しかし、スタンバイがオペレーティングシステムのレベルでクラッシュした場合はこの限りではありません。

同期レプリケーションが使用されている場合、通常、ディスクに対してのローカルな書き込みとWALレコードのレプリケーションのいずれかを待つか、トランザクションに非同期でコミットさせるかどちらかの選択を行うよう実用的になっています。しかし、トランザクションに対し特別の値である local が使用でき、同期レプリケーションではなく、ディスクへのローカルフラッシュの待機を要請することが可能です。 もし synchronous_standby_names が設定されていなければ、 on remote_write および local の設定は全て同一の同期レベルを提供します。トランザクションのコミットはローカルディスクへの書き込みのみ待機します。

このパラメータはいつでも変更可能です。 この設定により任意の1つのトランザクションのコミット時の動作が決まります。 したがって、一部のトランザクションのコミットを同期的に、その他を非同期的にすることが可能で、かつ、有用です。 例えば、デフォルトが同期コミットの場合に単一の複数文トランザクションを非同期にコミットさせるためには、トランザクション内で SET LOCAL synchronous_commit TO OFF を発行します。

wal_sync_method ( enum )

WALの更新をディスクへ強制するのに使用される方法です。 fsync がオフの場合この設定は役に立ちません。と言うのはWALファイルの更新が全く強制されないからです。取り得る値は以下のものです。

  • open_datasync open() オプション O_DSYNC でWALファイルの書き込み)

  • fdatasync (コミット毎に fdatasync() を呼び出し)

  • fsync (コミット毎に fsync() を呼び出し)

  • fsync_writethrough (いかなるディスク書き込みキャッシュもライトスルーさせるため、コミット毎に fsync() を呼び出し)

  • open_sync open() オプション O_SYNC でWALファイルの書き込み)

もし可能なら open_ *オプションも O_DIRECT を使用します。 全てのプラットホームでこれら全ての選択肢が使えるわけではありません。 デフォルトは、上のリストのプラットフォームでサポートされるものの最初に列挙されているものです。ただしLinuxでは fdatasync がデフォルトです。 デフォルトは必ずしも理想的なものではありません。 この設定、あるいはクラッシュに適応した構成か、アーカイブの最適性能を導くために使用しているシステム構成の形態を変更することが必要かもしれません。これらの側面は 項29.1 で解説されます。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。

full_page_writes ( boolean )

このパラメータが有効の場合、 PostgreSQL サーバは、チェックポイントの後にそのページが最初に変更された過程で、ディスクページの全ての内容をWALに書き込みます。 オペレーティングシステムがクラッシュした時に進行中のページ書き込みは途中までしか終わっていない可能性があるため、これが必要です。 この場合、ディスク上のページは古いデータと新しいデータが混在する状態になります。 通常WAL内に保存される行レベルの変更データは、クラッシュ後のリカバリ時にこうしたページを完全に復旧させるには不十分です。 完全なページイメージが、ページを正確に復旧できることを保証します。 しかし、WALに書き込まなければならないデータ量が増加する代償と引きかえになります。 (WAL再生は常にチェックポイントから始まるため、チェックポイント後のそれぞれのページの最初の変更時にこれを行うことで差し支えありません。 従って、完全ページ書き出しのコストを低減する方法の1つは、チェックポイント間隔パラメータを増やすことです。)

このパラメータを無効にすると、通常の操作速度が上がりますが、システム障害後に、回復不能なデータ破損、あるいは警告なしのデータ損壊をもたらすかもしれません。 このリスクは小さいながら fsync を無効にした場合と似ています。そしてその fsync に対して推奨されている同一の状況に基づく限りにおいて停止されなければなりません。

このパラメータを無効にしてもポイントインタイムリカバリ(PITR)用のWALアーカイブの使用に影響ありません( 項24.3 を参照してください)。

このパラメータは postgresql.conf ファイル内、または、サーバのコマンドラインでのみ設定可能です。 デフォルトは on です。

wal_buffers ( integer )

未だディスクに書き込まれていないWALデータに対して使用される共有メモリ容量です。 デフォルトの設定である-1は、 shared_buffers の1/32(約3%)の容量に等しい大きさを選択します。 しかし、 64kB 未満ではなく、かつ典型的に 16MB であるWALセグメントの大きさを越えることはありません。 もし、自動設定による選択が大きすぎたり、小さすぎる場合この値は手作業で設定可能です。 しかし、 32kB 未満のどんな正の値であっても、 32kB として取り扱われます。 このパラメータはサーバ起動時のみ設定可能です。

WALバッファの内容はトランザクションのコミット毎にディスクに書き込まれます。 したがって、極端に大きな値は有意な効果を期待できません。 しかし、この値を数メガバイトに設定することにより、多くのクライアントが同時にコミットするトラフィック量の多いサーバでは書き込み性能が向上します。 デフォルト設定の-1で選択される自動チューニングによると、ほとんどの場合妥当な結果が得られます。

wal_writer_delay ( integer )

WALライタの活動周期の間隔を指定します。 ライタのこの各周期でWALをディスクに吐き出します。 そして wal_writer_delay ミリ秒待機し、それを繰り返します。 デフォルト値は200ミリ秒( 200ms )です。 多くのシステムでは、待機間隔の実質的な分解能は10ミリ秒です。 10の倍数以外の値を wal_writer_delay に設定しても、その次に大きい10の倍数を設定した場合と同じ結果となります。 このパラメータは postgresql.conf ファイル内またはサーバのコマンドラインでのみ設定可能です。

commit_delay ( integer )

WALバッファをディスクにフラッシュ開始する前のマイクロ秒単位で設定される時間遅延を commit_delay は追加します。このことにより、もしシステム負荷が 与えられた時間間隔内でコミットが可能になる追加のトランザクションが準備可能になるほど充分な許容度がある場合、一回のWALフラッシュでコミットする大量のトランザク ションを許容することによって、コミット群の処理量を改善できます。 とは言っても、それぞれのWALフラッシュにたいし最大 commit_delay マイクロ秒の待ち時間の増加をきたします。 なぜなら、他にコミットの準備が完了したトランザクションが他に存在しない場合、遅延は無駄になります。 遅延は少なくとも commit_siblings だけのフラッシュが開始されようとしている時点で他のトランザクションが活動している場合機能します。 同様 fsync が無効の場合も機能しません。デフォルトの commit_delay はゼロ(遅延無し)です。この設定はスーパユーザのみ変更可能です。

9.3以前の PostgreSQL リリースに於いて、 commit_delay は異なった振る舞いを行っており、またより効果が下回っていました。 全てのWALフラッシュ、そしてWALフラッシュが早めに完了しても設定された遅延全体を待機するのではなく、コミットだけに影響しました。 PostgreSQL 9.3の開始で、フラッシュの準備が整う最初の工程においては設定された間隔で待機を行い、それに引き続く工程では唯一先導部がフラッシュ操作を完了するまで待機をします。

commit_siblings ( integer )

commit_delay 遅延を実行する前に必要とされる同時に開いているトランザクションの最小数です。 より大きい値は、遅延周期の間に、少なくとも1つの他のトランザクションがコミットの準備を整わせることを確実にします。 デフォルトは5トランザクションです。

18.5.2. チェックポイント

checkpoint_segments ( integer )

自動WALチェックポイント間の最大ログファイル数です。(それぞれのセグメントは通常16メガバイト) デフォルトは3セグメントです。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。

checkpoint_timeout ( integer )

自動的WALチェックポイント間の最大間隔を秒単位で指定します。 デフォルトは5分( 5min )です。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。

checkpoint_completion_target ( floating point )

チェックポイントの完了目標をチェックポイント間の総時間の割合として指定します。 デフォルトは0.5です。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。

checkpoint_warning ( integer )

チェックポイントセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した秒数よりも頻繁に発生する場合、サーバログにメッセージを書き出します (これは、 checkpoint_segments を増やす必要があることを示唆しています)。 デフォルトは30秒( 30s )です。 零の場合は警告を出しません。 checkpoint_timeout checkpoint_warning より小さい場合警告を出しません。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。

18.5.3. アーカイビング

archive_mode ( boolean )

archive_mode が有効な時、 archive_command を設定して、完了したWALセグメントをアーカイブ格納領域に送信されます。 アーカイブモードを抜けることなく archive_command を変更できるように、 archive_mode archive_command は分離されました。 このパラメータはサーバ起動時のみ設定可能です。 wal_level minimal に設定されている場合、 archive_mode は有効になりません。

archive_command ( string )

完了したWALファイルセグメントのアーカイブを実行するシェルコマンドです。 文字列内のいかなる %p は、格納されるファイルの絶対パスで置き換えられ、そして、 %f はファイル名のみ置換します。 (このパス名はサーバの作業用ディレクトリ、つまり、クラスタのデータディレクトリからの相対パスです。) コマンド内で実際の % 文字を埋め込むには %% を使用します。 コマンドが成功した場合に限って終了ステータスゼロを返すことが重要です。 より詳しくは 項24.3.1 を参照ください。

このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみ設定可能です。 サーバ起動時に archive_mode が有効でなければ、これは無視されます。 archive_command が空文字列(デフォルト)、かつ、 archive_mode が有効な場合、WALアーカイブ処理は一時的に無効になりますが、コマンドが後で提供されることを見越して、サーバはWALセグメントの蓄積を続けます。 例えば、 /bin/true (Windowsでは REM )のように、コマンドに対し archive_command を真を返すだけで何もしないように設定すると効果的にアーカイブ処理を無効にしますが、アーカイブからの復帰に必要なWALファイルの連鎖を同時に断ち切ります。従って、特別な場合のみ使用するようにしなければなりません。

archive_timeout ( integer )

archive_command は完了したWALセグメントに対してのみ呼び出されます。従って、サーバのWAL転送量が少ししかない(処理を行わないなぎの期間がある)場合、トランザクションの完了とアーカイブ格納領域への安全な記録との間に長期にわたる遅延があることになります。 古い未アーカイブのデータをどうするかについて制限を付けるために、 archive_timeout を設定して、強制的にサーバを新しいWALセグメントに定期的に切り替えるようにすることができます。 このパラメータが0より大きければ、サーバは前回のセグメントファイル切り替えから指定秒数経過した場合、および単一のチェックポイントを含む何らかのデータベース操作が行われた場合、新しいセグメントファイルに切り替えます。( checkpoint_timeout を大きくすると待機状態のシステム上のなくてもいいチェックポイントを削減します。) 強制切り替えにより早期に閉ざされたアーカイブ済みファイルは完全に完了したファイルと同じ大きさを持つことに注意してください。 そのため、非常に小さな archive_timeout を使用することは思慮を欠いています。 格納領域を膨張させてしまいます。 通常1分程度の archive_timeout 設定が妥当です。 もしそれより高速にデータをマスターサーバにコピーをしてしまいたいのであれば、アーカイブするよりストリーミングレプリケーションの選択を検討すべきです。 このパラメータは postgresql.conf ファイル、または、サーバのコマンドラインでのみで設定可能です。


powered by SEO.CUG.NET