PostgreSQL 9.0.0文書 | ||||
---|---|---|---|---|
前のページ | 巻戻し | 第 18章サーバの設定 | 早送り | 次のページ |
WALとチェックポイントの調整についての詳細は項29.4も参照してください。
wal_levelはどれだけの情報がWALに書かれるかを決定します。 デフォルト値はminimalで、クラッシュまたは即時停止から回復する情報のみを書き出します。 archiveはWALアーカイブに必要なログ取得を追加し、hot_standbyは更に待機サーバ上の読み取り専用問い合わせの情報を追加します。 このパラメータはサーバ起動時のみ設定可能です。
minimal水準では、同一のトランザクション内で作成された、または切り捨てられたテーブル上のCREATE INDEX、CLUSTERおよびCOPYのような何らかの巨大な操作のWALログ取得は安全に読み飛ばしされ、それらの操作をより高速にさせます(項14.4.7を参照してください)。 しかしminimal WALはベースバックアップとWALログからデータを再構築するための充分な情報を持ち合わせていませんので、WALアーカイビング(archive_mode)とストリーミングレプリケーションを有効にするにはarchiveまたはhot_standby水準を使用しなければなりません。
hot_standby水準においては、archiveと同じ情報がログ取得されるのに加え、WALから実行中のトランザクション状態を再構築するのに必要な情報が得られます。 待機サーバ上で読み取り専用問い合わせを有効にするには、hot_standbyが主サーバ、そしてhot_standbyが待機サーバで有効になっていなければなりません。 hot_standby水準とarchive水準を使用した場合にちょっとした計測可能な性能上の差異がありますので、実際に運用して問題が見つかった場合はご意見を歓迎します。
このパラメータがオンであれば、PostgreSQLサーバはfsync()
システム・コールを発行したり、もしくは同等の方法で(wal_sync_methodを参照)更新が物理的にディスクに書き込まれたかの確証を得ようと試みます。
これはオペレーティングシステムもしくはハードウェアがクラッシュした後、確実にデータベースクラスタを一貫した状態に復旧させることができます。
fsyncを停止することはしばしば性能上の利益になるとは言っても、予期せぬシステム停止やクラッシュの際に回復不可能なデータ破壊になることがあります。 従って外部データから全てのデータベースを簡単に再構築できる場合のみfsyncを停止してください。
fsyncを停止しても安全な環境の例としてバックアップファイルから新規データベースクラスタを初期読み込むことが含まれます。 時間単位でデータベースクラスタを統計処理に使用し、それはまた再構築されます。 あるいは再構築が頻繁に行われ、フェイルオーバには使用されない読み取り専用のデータベースクローンに対して使用するなどです。 高性能なハードウェアのみでfsyncを停止するすることは充分な正当性がありません。
多くの場合において、致命的ではないトランザクションにおいてsynchronous_commitを無効にすることで、データ破壊の危険性を伴うことなくfsyncを無効にした場合に潜在する性能向上を得ることができます。
fsync はpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 このパラメータを無効にする場合、full_page_writesも同時に無効にすることを検討してください。
トランザクションのコミットがクライアントに"成功"を返す前にWAL記録のディスクへの書き出しを待機するかどうかを指定します。 デフォルトかつ安全な設定はonです。 offの場合、クライアントに成功を報告する時点とトランザクションが本当にサーバクラッシュに対して安全になるまでの間に遅延が発生します。 (遅延の最大は、wal_writer_delayの3倍です。) fsyncと異なり、このパラメータをoffに設定することによっても、データベースの一貫性が損なわれる可能性はありません。 オペレーティングシステムやデータベースのクラッシュにより最近コミットされたと言われたトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。 ですので、synchronous_commitを無効にすることは、トランザクションの信頼性が確実であることよりも性能が重要である場合に有効な方法です。 詳細は項29.3を参照してください。
このパラメータはいつでも変更可能です。 この設定により任意の1つのトランザクションのコミット時の動作が決まります。 したがって、一部のトランザクションのコミットを同期に、他を非同期にすることが可能で、かつ、有用です。 例えば、デフォルトで同期コミットの場合に単一の複数文トランザクションを非同期にコミットさせるためには、トランザクション内でSET LOCAL synchronous_commit TO OFFを発行します。
WALの更新をディスクへ強制するのに使用される方法です。fsyncがオフの場合この設定は役に立ちません。と言うのはWALファイルの更新が全く強制されないからです。取り得る値は以下のものです。
open_datasync(open()
オプションO_DSYNCでWALファイルの書き込み)
fdatasync(コミット毎にfdatasync()
を呼び出し)
fsync_writethrough(いかなるディスク書き込みキャッシュもライトスルーさせるため、コミット毎にfsync()
を呼び出し)
fsync(コミット毎にfsync()
を呼び出し)
open_sync(open()
オプションO_SYNCでWALファイルの書き込み)
全てのプラットホームでこれら全ての選択肢が使えるわけではありません。 デフォルトは、上のリストでプラットフォームでサポートされるものの中で先頭にあるものです。 また、open_*オプションは可能ならばO_DIRECTを使用します。 PostgreSQLソースツリーにあるsrc/tools/fsyncユーティリティは各種のfsyncメソッドの性能試験を行えます。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。
このパラメータが有効の場合、PostgreSQLサーバはディスクページの全ての内容を、チェックポイントの後、そのページの最初の変更過程でWALに書き込みます。 オペレーティングシステムがクラッシュした時に進行中のページ書き込みは途中までしか終わっていない可能性があるため、これが必要です。 この場合、ディスク上のページは古いデータと新しいデータが混在する状態になります。 通常WAL内に保存される行レベルの変更データは、クラッシュ後のリカバリ時にこうしたページを復旧させるには不十分です。 完全なページイメージが、ページを正確に復旧できることを保証します。 しかし、WALに書き込まなければならないデータ量が増加します。 (WAL再生は常にチェックポイントから始まるため、チェックポイント後の最初の変更時にこれを行うことが十分です。 従って、完全ページ書き出しのコストを低減する方法の1つは、チェックポイント間隔パラメータを増やすことです。)
このパラメータを無効にすると、通常の操作速度が上がります。 しかし、システム障害後回復不能なデータ破損、あるいは警告なしのデータ損壊をもたらすかもしれません。 このリスクは小さいながらfsyncを無効にした場合と似ています。そしてそのパラメータに対して推奨されている同一の状況に基づく限りにおいて停止されなければなりません。
このパラメータを無効にしてもポイントインタイムリカバリ(PITR)用のWALアーカイブの使用に影響ありません( 項24.3を参照してください)。
このパラメータはpostgresql.confファイル内、または、サーバのコマンドラインでのみ設定可能です。 デフォルトはonです。
WALデータ用に共有メモリ内で使用されるメモリ量です。 デフォルトは64キロバイト(64kB)です。 データはそれぞれのトランザクションコミット時にディスクに書き出されるため、設定としては、1つの典型的なトランザクションによって生成されるWALデータを保存できる充分な大きさであることのみが必要です。 このパラメータはサーバ起動時のみ設定可能です。
このパラメータを増加させると、使用しているオペレーティングシステムのデフォルト構成が許容するSystem V共有メモリの限界を越えた要求をPostgreSQLが行う原因となることがあります。必要であれば、どの様にしてこのパラメータを調整するかについて項17.4.1を参照ください。
WALライタの活動周期の間隔を指定します。 ライタのこの各周期でWALをディスクに吐き出します。 そしてwal_writer_delayミリ秒待機することを繰り返します。 デフォルト値は200ミリ秒()200msです。 多くのシステムでは、待機間隔の実質的な解像度は10ミリ秒です。 10の倍数以外の値をwal_writer_delayに設定しても、次に大きな10の倍数を設定した場合と同じ結果となります。 このパラメータはpostgresql.confファイル内またはサーバのコマンドラインでのみ設定可能です。
コミットレコードをWALバッファに書き込む時と、バッファをディスクに吐き出す時のミリ秒単位の時間差遅延です。
システム負荷が高く、指定期間内にコミット準備ができたトランザクションが複数存在した場合、ゼロ以外の遅延時間であれば複数のトランザクションを一度のfsync()
システムコールのみで、与えられた周期以内でコミットすることができます。
しかし、もし他のトランザクションがコミットできる状態にならなければ、この遅延は無駄になります。と言うことは、サーバプロセスがそのコミットレコードを書き込んだ瞬間に他のトランザクションが進行している commit_siblingsにだけ少なくとも実行されます。
デフォルトの値はゼロ(遅延無し)です。
commit_delay遅延を実行する前に必要とされる同時に開いているトランザクションの最小数です。 より大きい値は、遅延周期の間に、少なくとも1つの他のトランザクションがコミットの準備を整わせることを確実にします。 デフォルトは5トランザクションです。
自動WALチェックポイント間の最大ログファイル数です。(それぞれのセグメントは通常16メガバイト) デフォルトは3セグメントです。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。
自動的WALチェックポイント間の最大間隔を秒単位で指定します。 デフォルトは5分(5min)です。 このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。
チェックポイントの完了目標をチェックポイント間の総時間の割合として指定します。 デフォルトは0.5です。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。
チェックポイントセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した秒数よりも頻繁に発生する場合、サーバログにメッセージを書き出します (これは、checkpoint_segmentsを呼び出す必要があることを示唆しています)。 デフォルトは30秒(30s)です。 零の場合は警告を出しません。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。
archive_modeが有効な時、archive_commandを設定して、完了したWALセグメントをアーカイブ格納領域に送信されます。 アーカイブモードを抜けることなくarchive_commandを変更できるように、archive_modeとarchive_commandは分離されました。 このパラメータはサーバ起動時のみ設定可能です。archive_modeを有効にするには、wal_levelをarchiveまたはhot_standbyに設定しなければなりません。
完了したWALファイルセグメントのアーカイブを実行するシェルコマンドです。 文字列内のいかなる%pは、格納されるファイルの絶対パスで置き換えられ、そして、%fはファイル名のみ置換します。 (このパス名はサーバの作業用ディレクトリ、つまり、クラスタのデータディレクトリからの相対パスです。) コマンド内で実際の%文字を埋め込むには%%を使用します。 コマンドが成功した場合に限って終了ステータスゼロを返すことが重要です。 より詳しくは項24.3.1を参照ください。
このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみ設定可能です。 サーバ起動時にarchive_modeが有効でなければ、これは無視されます。 archive_commandが空文字列(デフォルト)、かつ、archive_modeが有効な場合、WALアーカイブ処理は一時的に無効になりますが、コマンドが後で提供されることを見越して、サーバはWALセグメントの蓄積を続けます。 例えば、/bin/true(WindowsではREM)のように、コマンドに対しarchive_commandを真を返すだけで何もしないように設定すると効果的にアーカイブ処理を無効にしますが、アーカイブからの復帰に必要なWALファイルの連鎖を同時に断ち切ります。従って、特別な場合のみ使用するようにしなければなりません。
archive_commandは完了したWALセグメントに対してのみ呼び出されます。従って、サーバが少ししかWAL流量がない(処理を行わないなぎの期間がある)場合、トランザクションの完了とアーカイブ格納領域への安全な記録との間に長期にわたる遅延があることになります。 古い未アーカイブのデータをどうするかについて制限を付けるために、archive_timeoutを設定して、強制的にサーバを新しいWALセグメントに定期的に切り替えるようにすることができます。 このパラメータが0より大きければ、サーバは前回のセグメントファイル切り替えから指定秒数経過した場合、および単一のチェックポイントを含む何らかのデータベース操作が行われた場合、新しいセグメントファイルに切り替えます。(checkpoint_timeoutを大きくすると待機状態のシステム上の不必要なチェックポイントを減少させます。) 強制切り替えにより早期に閉ざされたアーカイブ済みファイルは完全に完了したファイルと同じ大きさを持つことに注意してください。 そのため、非常に小さなarchive_timeoutを使用することはお勧めしません。 格納領域を膨張させてしまいます。 通常ならば分単位のarchive_timeout設定が合理的です。 このパラメータは postgresql.confファイル内、または、サーバのコマンドラインでのみで設定可能です。
これらの設定は組み込みのストリーミングレプリケーション機能の動作を制御します。 これらのパラメータは1つ以上の待機サーバにレプリケーションデータを送信する主サーバ上で設定されます。
待機サーバからの同時接続を受ける最大数を設定します(つまり、同時に稼動するWAL送信プロセスの最大数です)。 デフォルトはゼロです。このパラメータはサーバ起動時のみ設定可能です。 待機サーバからの接続を許可するにはwal_levelをarchiveまたはhot_standbyに設定しなければなりません。
WAL送信プロセスに対する動作周回間の遅延を設定します。それぞれの周回でWAL送出機構は待機サーバに最終回送った後に蓄積されたWALを送信します。そして、wal_sender_delayミリ秒活動停止し、また繰り返しを行います。デフォルト値は200ミリ秒(200ms)です。 多くのシステムでは、有効な活動停止遅延の分解能は10ミリ秒です。10の倍数でない値にwal_sender_delayを設定しても、次の10の倍数に設定したのと同じ結果となります。このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
待機サーバがストリーミングレプリケーションに対し、取り出す必要に迫られるpg_xlogディレクトリに保存されている過去のログファイルセグメントの最小値を設定します。 それぞれのセグメントは通常16メガバイトです。もし主サーバに接続している待機サーバがwal_keep_segmentsセグメントよりも少なくなってしまった場合、主サーバは待機のため今後とも必要とされるWALセグメントを削除する可能性があります。 このような場合、レプリケーション接続は停止します。(しかし、WALアーカイブが使用されていれば、待機サーバはアーカイブからセグメントを取り出し、復旧することができます。)
pg_xlogに保持されているセグメントの最小値を設定します。 システムはWALアーカイブのため、またはチェックポイントからの回復のためにより大きいセグメントを保持する必要があることがあります。もしwal_keep_segmentsが(デフォルトでの)ゼロの場合、システムは待機目的での余分のセグメントを保持せず、待機サーバが使用できる古いWALセグメントの多くは、前回のチェックポイントとWALアーカイブの状態の場所の機能になります。 このパラメータはリスタートポイントに影響を与えません。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
VACUUMおよびHOT更新がデッドローバージョンの後片付けを異ならせるかを決めるトランザクション数を設定します。 デフォルトはゼロトランザクションです。その意味は、デッドローバージョンはできる限り早く削除することができることで、つまりいかなる開いたトランザクションからも、それらがもはや見えなくなった時点のことです。 項25.5で記述されているように、この設定を主サーバでホット待機サーバがサポートしている非ゼロに設定したい時があります。 これは、行の早期の後片付けによる衝突を招くことなしに、待機サーバ上で問い合わせに対しより時間をさくことができます。 しかし、この値は主サーバ上で発生する書き込みトランザクション数で測られるので、待機サーバにどれだけ多くの追加猶予時間を与えられるかを予想することはできません。 このパラメータは postgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。
これらの設定はレプリケーションデータを受け取る待機サーバの動作を管理します。
項25.5に記載されている通り、リカバリ中に接続し、問い合わせを処理できるか否かを設定します。デフォルト値はoffです。 このパラメータはサーバ起動時のみ設定可能です。これは、アーカイブリカバリ又は待機モードのみに対し効果があります。
ホットスタンバイが稼動している場合、待機サーバはWAL登録が寸前の適用となっていることと衝突する待機問い合わせをキャンセルする以前にどれだけ時間待ちをしなくてはならないかを設定します。 項25.5.2に記述されています。max_standby_archive_delayはWALデータがWALアーカイブから読み込まれている時に適用されます(従って最新ではありません)。 デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまで待機サーバが待ち続けることを許容します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
max_standby_archive_delayは中止前に問い合わせが実行できる最大時間と同じではありません。むしろ、どんな1つのWALセグメントのデータに適用される最大許可全時間です。従って、問い合わせがWALセグメント内でそれ以前に大幅な遅延となった場合、引き続く衝突する問い合わせはより小さな猶予時間を持ちます。
ホットスタンバイが稼動している場合、このパラメータは待機サーバが、WAL書き込みをしようとしているのと衝突する待機問い合わせを中止する前に、れだけ長く待機しなければならないかを決定します。項25.5.2に記載されています。 max_standby_streaming_delayは、WALデータがストリーミングレプリケーションで受け取られている時に適用されます。デフォルトは30秒です。特に指定が無ければ単位はミリ秒です。値-1は衝突する問い合わせが完了するまで待機サーバが待ち続けることを許容します。このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。
max_standby_streaming_delayは中止前に問い合わせが実行できる最大時間と同じではありません。むしろ、どんな1つのWALセグメントのデータに適用される最大許可全時間です。 従って、問い合わせがWALセグメント内でそれ以前に大幅な遅延となった場合、引き続く衝突する問い合わせは、待機サーバが再び追従するまで、より小さな猶予時間を持ちます。