これらの設定をチューニングする追加情報は30.5を参照してください。
wal_level
(enum
)
#
wal_level
はどれだけの情報がWALに書かれるかを決定します。
デフォルト値はreplica
で、WALアーカイビングおよびレプリケーションをサポートするために十分なデータを書き出し、これにはスタンバイサーバで読み取り専用の問い合わせを実行することも含みます。
minimal
はクラッシュまたは即時停止から回復するのに必要な情報を除き、すべてのログを削除します。
最後に、logical
は、更にロジカルデコーディングをサポートするのに必要な情報を追加します。
それぞれのレベルは、下位のレベルのログ出力を含んでいます。
このパラメータはサーバ起動時のみ設定可能です。
minimal
レベルでは、最小限のWALの量しか生成されません。
永続リレーションを作成あるいは書き換えるトランザクションの差分に関する情報は記録されません。
これにより、それらの操作が大幅に高速になります(14.4.7を参照してください)。
この最適化が適用される操作には以下のものがあげられます。
ALTER ... SET TABLESPACE |
CLUSTER |
CREATE TABLE |
REFRESH MATERIALIZED VIEW
(CONCURRENTLY なし) |
REINDEX |
TRUNCATE |
しかし、minimal WALにはポイントインタイムリカバリのための十分な情報が含まれていないので、replica
以上を使って継続的アーカイブ(archive_mode)とストリーミングバイナリレプリケーションを可能にしなければなりません。
実際、max_wal_senders
が0以外の場合、サーバはこのモードで起動することさえありません。
wal_level
をminimal
に変更すると、以前のベースバックアップがポイントインタイムリカバリとスタンバイサーバで使用できなくなることに注意してください。
logical
レベルでは、replica
と同じ情報が記録されるのに加え、ロジカルチェンジセットをWALから取り出すのに必要な情報が追加されます。
logical
を使うとWALの量が増えます。
とりわけ、多数のテーブルがREPLICA IDENTITY FULL
と設定されていて(訳注: ALTER TABLE参照)、多くのUPDATE
とDELETE
文が実行される場合はこのことが言えます。
9.6よりも前のリリースでは、このパラメータはarchive
とhot_standby
という設定値も可能でした。
引き続きこれらも受け付けられますが、replica
へとマップされます。
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
)
#
トランザクションのコミットがクライアントに「成功」の報告を返す前に、どれだけのWAL処理を完了しなければならないかを指定をします。
有効な値はremote_apply
、on
(デフォルト)、remote_write
、local
、off
です。
synchronous_standby_names
が空文字なら、意味のある設定はon
とoff
だけです。
remote_apply
、remote_write
、local
はすべてon
と同じ同期レベルを提供します。
off
モード以外のローカルの振る舞いは、WALがディスクにローカルにフラッシュされるのを待ちます。
off
モードでは待ちはありません。
ですから、クライアントに成功が報告されてから、トランザクションが後でサーバクラッシュに対して安全が保証されるまでの間に遅延が生じる可能性があります。
(遅延は最大でwal_writer_delayの3倍です。)
fsyncと違って、このパラメータをoff
にすることでデータベースの一貫性が損なわれるリスクはありません。
オペレーティングシステムやデータベースのクラッシュにより最近コミットされたということになっているトランザクションの一部が失われる可能性がありますが、これらのトランザクションが正常にアボートされた時とデータベースの状態は変わりません。
したがって、synchronous_commit
のオフによる調整は、トランザクションの耐障害性を確実にするよりも性能が重要な場合の有用な代替案となるかも知れません。
詳細は30.4を参照してください。
synchronous_standby_namesが空文字でない場合は、synchronous_commit
は、WALレコードが、スタンバイサーバに複製されるまでトランザクションコミットを待機するか否かも制御します。
remote_apply
に設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取って適用し、スタンバイ上で発行されたクエリから見えるようになり、スタンバイ上の永続的な記憶装置に書き込まれたことを報告するまでコミットは待機します。
WALのリプレイを待つので、今までの設定に比べるとこの設定によってずっと大きなコミットの遅延が発生します。
on
に設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、永続的な記憶装置にフラッシュしたことを報告するまでコミットは待機します。
このモードでは、プライマリおよびすべての同期スタンバイがデータベース記憶装置の故障を被った場合を除いて、トランザクションが失われないことが保証されます。
remote_write
に設定すると、現在の同期スタンバイがトランザクションのコミットレコードを受け取り、スタンバイのファイルシステムに書き出したことを報告するまでコミットは待機します。
この設定は仮にPostgreSQLのスタンバイインスタンスがクラッシュしたとしても、データ保護を保証するのに充分です。
しかし、スタンバイがオペレーティングシステムのレベルでクラッシュした場合はこの限りではありません。
データが必ずしもスタンバイの永続的な記憶装置に到達したとは言えないからです。
最後に、local
設定は、コミットがローカルにディスクにフラッシュされるまで待機しますが、レプリケーションされるまでは待機しません。
これは通常同期レプリケーションが使用されている場合は望ましい設定ではありませんが、完全さのために提供されています。
このパラメータはいつでも変更可能です。
どのトランザクションの動作も、コミット時に有効であった設定によって決まります。
したがって、一部のトランザクションのコミットを同期的に、その他を非同期的にすることが可能で、かつ、有用です。
例えば、デフォルトが同期コミットの場合に複数文トランザクションを一つだけ非同期にコミットさせるためには、トランザクション内でSET LOCAL synchronous_commit TO OFF
を発行します。
synchronous_commit
設定の機能のまとめが表 20.1にあります。
表20.1 synchronous_commitモード
synchronous_commit設定 | localの永続的なコミット | PGがクラッシュした後のスタンバイの永続的なコミット | OSがクラッシュした後のスタンバイの永続的なコミット | スタンバイのクエリの一貫性 |
---|---|---|---|---|
remote_apply | • | • | • | • |
on | • | • | • | |
remote_write | • | • | ||
local | • | |||
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ファイルに書き込む)
全てのプラットフォームでこれら全ての選択肢が使えるわけではありません。
デフォルトは、上のリストのプラットフォームでサポートされるものの最初に列挙されているものです。
ただしLinuxとFreeBSDではfdatasync
がデフォルトです。
デフォルトは必ずしも理想的なものではありません。
クラッシュに適応した構成にする、あるいはアーカイブの最適性能を導くためには、この設定あるいはシステム構成の他の部分を変更することが必要かもしれません。
これらの側面は 30.1で解説されます。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみで設定可能です。
full_page_writes
(boolean
)
#このパラメータが有効の場合、PostgreSQLサーバは、チェックポイントの後にそのページが最初に変更された過程で、ディスクページの全ての内容をWALに書き込みます。 オペレーティングシステムがクラッシュした時に進行中のページ書き込みは途中までしか終わっていない可能性があり、ディスク上のページが古いデータと新しいデータが混在する状態になるため、この機能が必要です。 通常WAL内に保存される行レベルの変更データは、クラッシュ後のリカバリ時にこうしたページを完全に復旧させるには不十分です。 完全なページイメージを保存することにより、ページを正しく復旧できることを保証しますが、その代わりに、WALに書き込まなければならないデータ量が増加することになります。 (WAL再生は常にチェックポイントから始まるため、チェックポイント後のそれぞれのページの最初の変更時にこれを行えば十分です。 従って、完全ページ書き出しのコストを低減する方法の1つは、チェックポイント間隔パラメータを大きくすることです。)
このパラメータを無効にすると、通常の操作速度が上がりますが、システム障害後に、回復不能なデータ破損、あるいは警告なしのデータ損壊をもたらすかもしれません。
このリスクは小さいながらfsync
を無効にした場合と似ています。そしてそのfsync
に対して推奨されている同一の状況に基づく限りにおいて停止されなければなりません。
このパラメータを無効にしてもポイントインタイムリカバリ(PITR)用のWALアーカイブの使用に影響ありません( 26.3を参照してください)。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
デフォルトはon
です。
wal_log_hints
(boolean
)
#
このパラメータがon
の場合、PostgreSQLサーバはチェックポイント後にはじめてページを変更する際に、ディスクページの全内容をWALに書き出します。
これは、あまり重要でない、ヒントビットと呼ばれるものに対する変更にさえ当てはまります。
データチェックサムが有効であると、ヒントビットの更新は常にWALにログされ、この設定パラメータは無視されます。この設定パラメータを使って、データチェックサムが有効なときにどれだけのWALログは余計に書きだされるかをテストすることができます。
このパラメータはサーバ起動時のみ設定可能です。
デフォルト値はoff
です。
wal_compression
(enum
)
#
このパラメータは、指定された圧縮方式を使用したWALの圧縮を有効にします。
有効にすると、PostgreSQLサーバはfull_page_writesがオンの時またはベースバックアップ中にWALに書き込まれた全ページイメージを圧縮します。
圧縮されたページイメージはWAL再生中に伸長されます。
サポートされている方法はpglz
、lz4
(PostgreSQLが--with-lz4
でコンパイルされた場合)およびzstd
(PostgreSQLが--with-zstd
でコンパイルされた場合)です。
デフォルト値はoff
です。
スーパーユーザと適切なSET
権限を持つユーザのみがこの設定を変更できます。
このパラメータを有効にすると、回復不可能なデータ破壊のリスクを増やすこと無しにWALの量を減らすことができます。 しかし、WALロギングの際の圧縮のため、またWALリプレイの際には伸張のために余分なCPUを使用するというコストが発生します。
wal_init_zero
(boolean
)
#
このオプションがon
(デフォルト)に設定されると、新しいWALファイルはゼロで初期化されます。
システムによっては、このことによってWALレコードを書く必要が出てくる前にスペースが割り当てられることを保証します。
しかし、Copy-On-Write (COW)ファイルシステムではこの技術は利点がないかもしれず、このオプションはスキップできるようになっています。
off
に設定すると、ファイルを作る時に期待する大きさになるように最後のバイトだけが書かれます。
wal_recycle
(boolean
)
#
このオプションがon
(デフォルト)に設定されると、新しくファイルを作るのを避けるために、名前を変えてWALファイルが再利用されます。
COWファイルシステムでは、新しいファイルを作るほうが速いかも知れないので、この挙動を無効にできるようにオプションとなっています。
wal_buffers
(integer
)
#
未だディスクに書き込まれていないWALデータに対して使用される共有メモリ容量です。
デフォルトの設定である-1は、shared_buffersの1/32(約3%)の容量に等しい大きさを選択します。
しかし、64kB
未満ではなく、かつ典型的に16MB
であるWALセグメントの大きさを超えることはありません。
もし、自動設定による選択が大きすぎたり、小さすぎる場合この値は手作業で設定可能です。
しかし、32kB
未満のどんな正の値であっても、32kB
として取り扱われます。
この値が単位なしで指定された場合は、WALブロック単位であるとみなします。すなわち、XLOG_BLCKSZ
バイト、一般的には8kBです。
このパラメータはサーバ起動時のみ設定可能です。
WALバッファの内容はトランザクションのコミット毎にディスクに書き込まれます。 したがって、極端に大きな値は有意な効果を期待できません。 しかし、この値を数メガバイトに設定することにより、多くのクライアントが同時にコミットするトラフィック量の多いサーバでは書き込み性能が向上します。 デフォルト設定の-1で選択される自動チューニングによると、ほとんどの場合妥当な結果が得られます。
wal_writer_delay
(integer
)
#
WALライタがWALをフラッシュする頻度を時間で指定します。
WALをフラッシュしたあと、非同期コミットしているトランザクションに起こされない限り、wal_writer_delay
ミリ秒待機します。
最後のフラッシュが過去wal_writer_delay
以内に行われ、かつそれ以降wal_writer_flush_after
相当のWALが生成されている場合は、WALはオペレーティングシステムに書き込まれますが、ディスクにはフラッシュされません。
この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。
デフォルト値は200ミリ秒(200ms
)です。
多くのシステムでは、待機間隔の実質的な分解能は10ミリ秒です。
10の倍数以外の値をwal_writer_delay
に設定しても、その次に大きい10の倍数を設定した場合と同じ結果となります。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
wal_writer_flush_after
(integer
)
#
WALライタがWALをフラッシュする頻度を量で指定します。
最後のフラッシュが過去wal_writer_delay
以内に起こなわれ、かつそれ以降wal_writer_flush_after
相当のWALが生成されている場合は、WALはオペレーティングシステムに書き込まれますが、ディスクにはフラッシュされません。
wal_writer_flush_after
が0
に設定されている場合は、WALデータが書かれるたびにWALが即時にフラッシュされます。
この値が単位なしで指定された場合は、WALブロック単位であるとみなします。すなわち、XLOG_BLCKSZ
バイト、一般的には8kBです。
デフォルト値は1MB
です。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
wal_skip_threshold
(integer
)
#
wal_level
がminimal
で、トランザクションのコミットが永続リレーションを作るかあるいは書き換えた場合に、この設定は新しいデータをどのように永続させるかを決定します。
データがこの設定よりも少なければ、WALログに書きます。そうでなければ、影響のあるファイルに対してfsyncを使用します。
そのようなコミットが現在のトランザクションを低速化しているようであれば、使用する記憶装置の特性によってはこの値を増減することが役に立つかも知れません。
この値が単位なしに指定されるとキロバイトであると見なします。
デフォルトは2メガバイト(2MB
)です。
commit_delay
(integer
)
#
commit_delay
を設定することにより、WALフラッシュを開始する前の時間遅延が追加されます。
このことにより、もし追加のトランザクションが与えられた時間間隔内でコミットが可能になるほどシステム負荷が充分に高い場合、一回のWALフラッシュでより多くの数のトランザクションをコミットできるようになり、コミット群のスループットを改善できます。
とは言っても、それぞれのWALフラッシュに対して最大commit_delay
の待ち時間の増加をきたします。
コミットの準備が完了したトランザクションが他に存在しない場合、遅延は無駄になるため、遅延はフラッシュが開始されようとしている時点で少なくともcommit_siblings
だけのトランザクションが活動している場合にだけ機能します。
同様に、fsync
が無効の場合も遅延は機能しません。
この値が単位なしで指定された場合は、マイクロ秒単位であるとみなします。
デフォルトのcommit_delay
はゼロ(遅延無し)です。
スーパーユーザと適切なSET
権限を持つユーザのみがこの設定を変更できます。
9.3より前のPostgreSQLでは、commit_delay
の振る舞いは異なっており、あまり効果がありませんでした。
全てのWALフラッシュではなく、コミットだけに影響していました。また、そしてWALフラッシュが早めに完了しても設定された遅延分待機していました。
PostgreSQL 9.3以降では、フラッシュの準備が整った最初のプロセスが設定値分待機し、後続のプロセスは最初のプロセスがフラッシュ操作を完了するまでの間だけ待機をします。
commit_siblings
(integer
)
#
commit_delay
の遅延を実行するときに必要とされる同時に開いているトランザクションの最小数です。
より大きい値にすると、遅延周期の間に、少なくとも1つの他のトランザクションのコミットの準備が整う確率が高くなります。
デフォルトは5トランザクションです。
checkpoint_timeout
(integer
)
#
自動的WALチェックポイント間の最大間隔を指定します。
この値が単位なしで指定された場合は、秒単位であるとみなします。
有効な範囲は、30秒から1日の間です。
デフォルトは5分(5min
)です。
このパラメータを増やすと、クラッシュリカバリで必要となる時間が増加します。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
checkpoint_completion_target
(floating point
)
#
チェックポイントの間の時間のうち、どの程度の割合を使うかをチェックポイントの完了目標として指定します。
デフォルトは0.9で、可能な限りの間隔のほとんどにチェックポイントを拡散し、かなり一定のI/O負荷をもたらしますが、チェックポイントが完了するにあたってオーバーヘッドをもたらします。
チェックポイントの完了を早くするので、このパラメータを小さくするのはお勧めできません。
これにより、チェックポイント中はI/Oの割合が大きくなり、チェックポイントの完了から次のチェックポイントまでの間はより少ないI/Oとなります。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
checkpoint_flush_after
(integer
)
#
チェックポイント実行中にこのデータ量よりも多く書く度に、OSが記憶装置に書き込むことを強制しようとします。
このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsync
が実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。
多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。
この設定が無効なプラットフォームがあります。
この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZ
バイト、一般的には8kBです。
有効な設定値は、この強制書き込み機能が無効になる0
から、2MB
までです。
デフォルト値は、Linuxでは256kB
で、それ以外は0
です。
(BLCKSZ
が8kbでなければ、この設定のデフォルト値と最大値がBLCKSZ
に比例して変更されます。)
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみで設定可能です。
checkpoint_warning
(integer
)
#
WALセグメントファイルが溢れることが原因で起きるチェックポイントが、ここで指定した時間よりも短い間隔で発生したとき、サーバログにメッセージを書き出します
(これは、max_wal_size
を増やす必要があることを示唆しています)。
この値が単位なしで指定された場合は、秒単位であるとみなします。
デフォルトは30秒(30s
)です。
零の場合は警告を出しません。
checkpoint_timeout
がcheckpoint_warning
より小さい場合は警告を出しません。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
max_wal_size
(integer
)
#
自動WALチェックポイントの際にWALが増加する最大サイズです。
これはソフトリミットです。特別な状況下、たとえば高負荷、archive_command
の失敗、archive_library
の失敗、wal_keep_size
が大きな値に設定されている、などの時には、WALサイズはmax_wal_size
を超えることがあります。
この値が単位なしで指定された場合は、メガバイト単位であるとみなします。
デフォルトは1GBです。
このパラメータを大きくすると、クラッシュリカバリに必要な時間が長くなります。
このパラメータは、postgresql.conf
ファイルで設定するか、サーバのコマンドラインでのみ指定できます。
min_wal_size
(integer
)
#
この設定以下にWALのディスク使用量が保たれる限り、古いWALファイルは、消去されることなく今後のチェックポイントで使用するために常にリサイクルされます。
この設定は、たとえば大きなバッチジョブを走らせる際のWALの利用スパイクを取り扱うために、十分なWALのスペースが予約されていることを保証するために使用できます。
この値が単位なしで指定された場合は、メガバイト単位であるとみなします。
デフォルトは80MBです。
このパラメータは、postgresql.conf
ファイルで設定するか、サーバのコマンドラインでのみ指定できます。
archive_mode
(enum
)
#
archive_mode
が有効な場合、archive_commandあるいはarchive_libraryを設定することにより、完了したWALセグメントはアーカイブ格納領域に送信されます。
無効にするためのoff
に加え、2つのモードがあります。on
とalways
です。
通常の運用ではこの2つのモードには違いはありませんが、always
に設定すると、アーカイブリカバリおよびスタンバイモードでWALアーカイバが有効になります。
always
モードでは、アーカイブからリストアされたファイルや、ストリーミングレプリケーションでストリームされたファイルもすべて(再び)アーカイブされます。
詳細は27.2.9を参照してください。
archive_command
とarchive_library
がアーカイブモードを停止することなく変更できるように、archive_mode
は、archive_command
とarchive_library
とは別の設定項目になっています。
このパラメータはサーバ起動時のみ設定可能です。
wal_level
がminimal
に設定されている場合、archive_mode
を有効にすることはできません。
archive_command
(string
)
#
完了したWALファイルセグメントのアーカイブを実行するローカルのシェルコマンドです。
文字列内のすべての%p
は、格納されるファイルのパスで置き換えられ、そして、%f
はファイル名のみ置換します。
(このパス名はサーバの作業用ディレクトリ、つまり、クラスタのデータディレクトリからの相対パスです。)
コマンド内に%
文字そのものを埋め込むには%%
を使用します。
コマンドが成功した場合にのみ終了ステータスゼロを返すことが重要です。
詳しくは26.3.1を参照ください。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
サーバ起動時にarchive_mode
が有効で、archive_library
が空文字の時にのみ使用されます。
archive_command
とarchive_library
の両方が有効ならばエラーが発生します。
archive_mode
が有効であるにもかかわらず、archive_command
が空文字列(デフォルト)、(そしてarchive_library
が空文字列)である場合、WALアーカイブ処理は一時的に無効になりますが、コマンドが後で提供されることを見越して、サーバはWALセグメントの蓄積を続けます。
例えば、/bin/true
(WindowsではREM
)のように、真を返すだけで何もしないコマンドをarchive_command
に設定すると、実質的にアーカイブ処理が無効になりますが、アーカイブからの復帰に必要なWALファイルの連鎖も同時に断ち切るため、特別な場合のみ使用するようにしなければなりません。
archive_library
(string
)
#
アーカイビングが完了したWALファイルセグメントに使用するライブラリです。
空文字列(デフォルト)に設定された場合、シェル経由のアーカイビングが有効になり、archive_commandが使用されます。
archive_command
とarchive_library
の両方が有効ならばエラーが発生します。
それ以外の場合は、指定された共有ライブラリがアーカイブに使用されます。
WALアーカイバプロセスは、このパラメータが変更されたときにpostmasterによって再起動されます。
詳細については、26.3.1および第51章を参照してください。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
archive_timeout
(integer
)
#
archive_commandまたはarchive_library は、完了したWALセグメントに対してのみ呼び出されます。
したがって、サーバがWALトラフィックをほとんど生成しない場合(あるいはそのような余裕期間がある場合)、トランザクションの完了とアーカイブストレージへの安全な記録との間に長い遅延が発生する可能性があります。
アーカイブされていないデータの古さを制限するために、archive_timeout
を設定して、サーバに新しいWALセグメントファイルへの定期的な切り替えを強制することができます。
このパラメータが0より大きい場合、サーバは、最後のセグメントファイル切り替えからこの時間が経過し、単一のチェックポイント(データベースアクティビティがない場合はチェックポイントはスキップされます)を含むデータベースアクティビティが発生するたびに新しいセグメントファイルへの切り替えを行います。
強制的な切り替えにより早期に閉じられたアーカイブファイルは、完全に満杯のファイルと同じ長さのままであることに注意してください。
したがって、非常に短いarchive_timeout
を使用することは賢明ではなく、アーカイブストレージを膨張させます。
通常は1分程度のarchive_timeout
設定が妥当です。
プライマリサーバからデータをより迅速にコピーしたい場合は、アーカイブではなくストリーミングレプリケーションを使用することを検討してください。この値が単位なしで指定された場合、秒として取得されます。
このパラメータはpostgresql.conf
ファイル、または、サーバのコマンドラインでのみ設定可能です。
このセクションでは、クラッシュリカバリ、ストリーミングレプリケーション、およびアーカイブベースのレプリケーションに影響する一般的なリカバリに適用される設定について説明します。
recovery_prefetch
(enum
)
#
リカバリ中に、まだバッファプールにない、WALで参照されているブロックをプリフェッチしようとするかどうか。
有効な値はoff
、on
、try
(デフォルト)です。
try
設定は、オペレーティングシステムがposix_fadvise
関数を提供している場合にのみプリフェッチを有効にします。
この関数は現在、プリフェッチの実装に使用されています。
一部のオペレーティングシステムはこの関数を提供していますが、何も行わないことに注意してください。
すぐに必要になるブロックをプリフェッチすると、一部のワークロードでリカバリ中のI/O待機時間を短縮できます。 プリフェッチ・アクティビティを制限するwal_decode_buffer_sizeおよびmaintenance_io_concurrency設定も参照してください。
wal_decode_buffer_size
(integer
)
#サーバがプリフェッチするブロックを見つけるためにWAL内をどれだけ先まで見ることができるかの制限です。 この値が単位なしで指定された場合、バイトとして扱われます。 デフォルトは512KBです。
この節では、リカバリの間だけ適用する設定について説明します。 その後実施するリカバリでは、その設定はリセットしなければなりません。
「リカバリ」は、サーバをスタンバイとして使用するとき、あるいはターゲットを指定したリカバリで適用されます。 通常、スタンバイモードは、高可用性または読み出しスケーラビリティ、あるいはその両方を提供するために使用します。 一方ターゲットを指定したリカバリは失なわれたデータを回復するために使用します。
スタンバイモードでサーバを起動するには、standby.signal
と呼ばれるファイルをデータディレクトリに作ります。
サーバはリカバリモードに入り、アーカイブWALの終端に到着してもリカバリを止めず、primary_conninfo
の設定で指定された送信サーバに接続するか、restore_command
を使って新しいWALセグメントを取得するか、あるいはその両方によってリカバリを継続しようとします。
このモードでは、この節と20.6.3で説明するパラメータが関係します。
20.5.6のパラメータも適用できますが、このモードでは通常有用ではありません。
サーバをターゲットリカバリモードで起動するには、recovery.signal
という名前のファイルをデータディレクトリに作ります。
standby.signal
とrecovery.signal
の両方が作られた場合は、スタンバイモードが優先します。
ターゲットリカバリモードはアーカイブWALが完全に再生されるか、recovery_target
に到達した時に終了します。
このモードでは、この節と20.5.6のパラメータの両方が使用されます。
restore_command
(string
)
#
一連のWALファイルからアーカイブセグメントを取り出すために実行するローカルのシェルコマンドです。
このパラメータはアーカイブリカバリでは必須ですが、ストリーミングレプリケーションではオプションです。
文字列中の%f
はアーカイブから取り出すファイルの名前に置換され、%p
はサーバ上のコピー先のパス名に置換されます。
(パス名は現在の作業ディレクトリの相対パス、つまりクラスタのデータディレクトリです。)
%r
は有効な最後のリスタートポイントを含むファイル名に置換されます。
これはリストアが再開可能であるために維持しなければならない最古のファイルで、現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。
%r
は通常ウォームスタンバイ構成でのみ使用されます。
(27.2参照。)
%
文字自体を埋め込むには%%
と書いてください。
コマンドは、成功した時のみ終了コードのゼロを返却することが重要です。 コマンドはアーカイブにないファイル名を聞かれることになります。 その場合には、非ゼロの値を返却しなければなりません。以下に例を示します。
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
例外は、データベースサーバのシャットダウンの一部として、SIGTERM以外のシグナルでコマンドが終了させられたり、シェルによってエラーが発生した(コマンドが見つからない場合など)場合で、その場合はリカバリは中断され、サーバはスタートアップしなくなります。
このパラメータは postgresql.conf
ファイル、または、サーバのコマンドラインでのみで設定可能です。
archive_cleanup_command
(string
)
#
オプションのパラメータは、すべてのリスタートポイントで実行されるシェルコマンドを指定します。
archive_cleanup_command
の目的は、スタンバイサーバにとって必要とされない古いアーカイブWALファイルをクリーンアップする仕組みを提供することです。
%r
は最後の有効なリスタートポイントを含むファイル名に置換されます。
これはリストアが再開可能であるために保持しなければならない最古のファイルで、%r
よりも前のすべてのファイルは安全に削除できます。
これは現在のリストアからの再開をサポートするのに最小限必要なアーカイブを残して切り詰めるのに必要な情報として利用できます。
単一のスタンバイ構成用のarchive_cleanup_command
で、たとえば以下のように、しばしばpg_archivecleanupモジュールが使われます。
archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'
だたし、複数のスタンバイサーバが同じアーカイブディレクトリからリストアしている場合は、どのサーバにおいてももはや必要がなくなるまでWALファイルが削除されることのないようにする必要があることに留意してください。
archive_cleanup_command
は通常ウォームスタンバイ構成で使用されます。
(27.2参照。)
%
文字自体を埋め込むには%%
と書いてください。
コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されます。 例外は、コマンドがシグナルで終了されたとき、あるいはシェルがエラーを起こしたとき(コマンドが見つからないなど)で、その場合致命的エラーが生じます。
このパラメータは、postgresql.conf
ファイル、もしくはサーバコマンドラインでのみ設定可能です。
recovery_end_command
(string
)
#
このパラメータは、リカバリの終了時に一度だけ起動されるシェルコマンドを指定します。
このパラメータはオプションです。
recovery_end_command
の目的はレプリケーションあるいはリカバリの後のクリーンアップのための機構を提供することにあります。
%r
は、archive_cleanup_commandと同じように、有効な最後のリスタートポイントを含むWALファイル名に置換されます。
コマンドが非ゼロの終了ステータスを返した場合、警告ログメッセージが出力されますが、データベースはスタートアップ処理を続けます。 例外は、コマンドがシグナルによって終了させられたか、シェルによってエラーが発生した(そのようなコマンドは見つからない)場合で、その場合はデータベースはスタートアップ処理を継続させません。
このパラメータは、postgresql.conf
ファイル、もしくはサーバコマンドラインでのみ設定可能です。
デフォルトではWALログの最後までリカバリを行います。
次のパラメータがそれより前の時点でリカバリを停止するために利用できます。
次のrecovery_target
、recovery_target_lsn
、recovery_target_name
、recovery_target_time
、recovery_target_xid
のどれか一つが使えます。
設定ファイルの中で2つ以上指定するとエラーとなります。
これらのパラメータはサーバ起動時のみ設定可能です。
recovery_target
= 'immediate'
#このパラメータは、リカバリが一貫した状態になり次第、すなわちできるだけ早く終了することを指定します。 オンラインバックアップからリストアした場合、これはバックアップが終了した時点を意味します。
技術的にはこれは文字列型のパラメータですが、現時点では'immediate'
だけが許容されている値です。
recovery_target_name
(string
)
#
このパラメータは、指定した(pg_create_restore_point()
により作成された)名前付きリストアポイントまでリカバリを進行させます。
recovery_target_time
(timestamp
)
#このパラメータは、指定したタイムスタンプまでリカバリを進行させます。 正確な停止点はrecovery_target_inclusiveにも影響されます。
(timezone_abbreviations変数が設定ファイルで先に設定されていない限り)時間帯略語を使えないことを除けば、このパラメータの値はtimestamp with time zone
データ型が受け付けるのと同じ形式のタイムスタンプです。
おすすめの形式はUTCからのオフセットか、EEST
ではなくEurope/Helsinki
のような完全な時間帯名です。
recovery_target_xid
(string
)
#このパラメータは、指定したトランザクションIDまでリカバリを進行させます。 トランザクションIDはトランザクション起動時に順番に割り当てられますが、トランザクションは数字順によらず完了することがあることに留意してください。 リカバリされるトランザクションは、指定されたものよりも前 (オプションによっては指定されたものも含まれる) にコミットされたものになります。 正確な停止点はrecovery_target_inclusiveにも影響されます。
recovery_target_lsn
(pg_lsn
)
#
このパラメータは、指定した先行書き込みログ(WAL)の場所のLSNまでリカバリを進行させます。
正確な停止点は、recovery_target_inclusiveの影響も受けます。
このパラメータは、 システムデータ型pg_lsn
を使用して解析されます。
以下のオプションはリカバリ対象をより詳細に指定し、リカバリが対象に達した時の動作に影響を与えます。
recovery_target_inclusive
(boolean
)
#
指定したリカバリ対象のちょうど後に停止するか(on
)、ちょうどその前に停止するか(off
)を指定します。
recovery_target_lsn、recovery_target_time、又はrecovery_target_xidが指定されている場合は適用されます。
この設定は、指定した対象のWALの場所(LSN)、コミット時刻、あるいはトランザクションIDが、それぞれ正確に一致するトランザクションをリカバリに含めるかどうかを制御します。
デフォルトはon
です。
recovery_target_timeline
(string
)
#
リカバリが作成する個別のタイムラインを指定します。
値は数値のタイムラインIDか、特殊な値です。
current
では、ベースバックアップが取得されたときにカレントだったタイムラインに沿ってリカバリします。
latest
では、アーカイブ時に見つけた最新のタイムラインにリカバリします。これはスタンバイサーバで有用です。
デフォルトはlatest
です。
タイムラインIDを16進数で指定するには(たとえば、WALファイル名前または歴史ファイルから抽出した場合)、0x
を前に置きます。
例として、WALファイル名前が00000011000000A10000004F
であれば、タイムラインIDは0x11
(または10進数で17)になります。
通常このパラメータの設定が必要となるのは、ポイントインタイムリカバリの実施後に到達した状態に戻す場合など、複雑なリカバリの状況のみです。 この論考については26.3.5を参照してください。
recovery_target_action
(enum
)
#
リカバリ対象に到達した場合に、サーバがする動作を指定します。
デフォルトはpause
で、リカバリを休止することを意味します。
promote
は、リカバリの過程が終われば、サーバは接続の受け付けを始めることを意味します。
最後に、shutdown
は、リカバリ対象に到達した後にサーバを停止します。
pause
の設定の意図した使い方は、このリカバリ対象がリカバリのための最も望ましいポイントかどうかチェックするために、データベースに対して問い合わせを実行できるようにすることです。
休止された状態は、pg_wal_replay_resume()
(表 9.93参照)の使用により再開することができます。
その後、それはリカバリを終了させます。
このリカバリ対象が希望の止まるポイントでない場合、サーバをシャットダウンし、リカバリ対象の設定をより後の対象に変更し、リカバリを継続するために再起動してください。
shutdown
の設定はインスタンスを正確に望ましい再生ポイントで準備するのに有用です。
インスタンスはさらに多くのWALレコードを再生できます(実際、次に起動するときには最後のチェックポイントからWALレコードを再生しなければなりません)。
recovery.signal
はrecovery_target_action
がshutdown
に設定されていると削除されないことに留意してください。
設定が変更されるか、recovery.signal
が手動で削除されない限り、以降起動しても直ちに停止されてしまいます。
この設定はリカバリ対象が設定されていない場合には効果がありません。
hot_standbyが有効になっていない場合、pause
の設定はshutdown
と同じように動作します。
昇格中にリカバリ対象に到達した場合は、pause
はpromote
と同じように働きます。
どのような場合でも、リカバリ対象が設定されていて、アーカイブリカバリがそのリカバリ対象に到達する前に終了すると、サーバはフェイタルエラーで停止します。