ストリーミングレプリケーションを初期化するために、フロントエンドは開始メッセージにてreplicationパラメータを送信します。
ブール値のtrue（またはon、yes、1）がバックエンドに対して、SQL文ではなく小規模なレプリケーションコマンド群を発行できるようになる、物理レプリケーションのwalsenderモードに入るように伝えます。
replicationパラメータに対する値としてdatabaseを渡すことは、dbnameパラメータで指定されたデータベースに接続して、バックエンドにロジカルレプリケーションのwalsendeモードに入ることを指示します。
ロジカルレプリケーションwalsenderモードでは、以下に示すレプリケーションコマンドを通常のSQLコマンドと同様に実行できます。
物理レプリケーション、ロジカルレプリケーションいずれかのwalsenderモードでは、簡易問い合わせプロトコルのみ使用できます。
レプリケーションコマンドをテストするために、replicationオプションを含む接続文字列を使用して、psqlまたは他のlibpqを使用するツールによるレプリケーション接続を作成できます。
例を示します。
psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
しかし、物理的レプリケーションのためにpg_receivewalを使用し、論理的レプリケーションのためにpg_recvlogicalを使用すれば、もっと有用なことが多いです。
log_replication_commandsが有効であるとき、サーバログにレプリケーションコマンドが記録されます。
レプリケーションモードで受け付けられるコマンドは以下の通りです。
IDENTIFY_SYSTEM
#サーバに自身を識別することを要求します。 サーバは以下の４つのフィールドを持つ単一行の結果セットをもって応答します。
systemid (text)クラスタを識別する一意なシステム識別子です。 これを使用してスタンバイを初期化するために使用するベースバックアップが同じクラスタに由来していることを検査することができます。
timeline (int8)現在のタイムラインIDです。 同様にスタンバイがプライマリと一貫性を持つことを検査するために使用されます。
xlogpos (text)現在のWALのフラッシュ位置です。 ストリーミングを開始できる先行書き込みログの既知の位置を得る際に有用です。
dbname (text)接続したデータベース名またはNULLです。
SHOW name
#実行時パラメータの現在の設定を送信するようサーバに要求します。 これはSQLコマンドSHOWと同等です。
name実行時パラメータの名前です。 利用できるパラメータは第20章に記述されています。
TIMELINE_HISTORY tli
#
tliのタイムラインのため、サーバにタイムライン履歴ファイルの送付を要求します。
サーバは2列単一行の結果セットを返します。
フィールドにはtextの印が付けられていますが、実際には符号化変換なしの生のバイトが返ります。
filename (text)
タイムライン履歴ファイル名、例えば00000002.history
content (text)タイムライン履歴ファイルの内容
CREATE_REPLICATION_SLOT slot_name [ TEMPORARY ] { PHYSICAL | LOGICAL output_plugin } [ ( option [, ...] ) ]
#物理的または論理的レプリケーションスロットを作成します。 レプリケーションスロットの詳細は27.2.6を参照。
次のオプションがサポートされています。
TWO_PHASE [ boolean ]
trueの場合、この論理レプリケーションスロットは2相コミットのデコードをサポートします。
このオプションを使用すると、PREPARE TRANSACTION、COMMIT PREPAREDおよびROLLBACK PREPAREDなどの2相コミットに関連するコマンドがデコードおよび転送されます。
トランザクションはPREPARE TRANSACTION時にデコードおよび転送されます。
デフォルトはfalseです。
RESERVE_WAL [ boolean ]trueの場合、この物理的レプリケーションスロットが直ちにWALを予約することを指定します。 そうでなければ、WALはストリーミングレプリケーションクライアントからの接続時の予約のみです。 デフォルトはfalseです。
SNAPSHOT { 'export' | 'use' | 'nothing' }
論理スロットの初期化時に作成されたスナップショットの処理について決定します。
デフォルトの'export'はスナップショットが他のセッションで利用できるようエクスポートします。
このオプションはトランザクションの内側で使用することはできません。
'use'はこのコマンドを実行している現在のトランザクションでスナップショットを利用します。
このオプションはトランザクション内で使用しなければならず、CREATE_REPLICATION_SLOTがそのトランザクション内で実行される最初のコマンドでなければなりません。
最後に、'nothing'は論理デコーディングで通常通りにスナップショットを使用するだけで、他には何もしません。
このコマンドへの応答として、サーバは以下のフィールドを含む1行の結果セットを送信します。
slot_name (text)新しく作成されたレプリケーションスロットの名前です。
consistent_point (text)スロットが一貫性のある状態になった時点のWAL位置です。 これが、このスロット上でストリーミングを開始できる最も早い場所となります。
snapshot_name (text)このコマンドでエクスポートされるスナップショットの識別子です。 スナップショットは、この接続上で新しいコマンドが実行されるか、レプリケーション接続が閉じられるまで有効です。 作成されたのが物理スロットの場合はNULLになります。
output_plugin (text)新しく作成されたレプリケーションスロットが使用する出力プラグインの名前です。 作成されたのが物理スロットの場合はNULLになります。
CREATE_REPLICATION_SLOT slot_name [ TEMPORARY ] { PHYSICAL [ RESERVE_WAL ] | LOGICAL output_plugin [ EXPORT_SNAPSHOT | NOEXPORT_SNAPSHOT | USE_SNAPSHOT | TWO_PHASE ] }
#
旧リリースとの互換性を保つために、CREATE_REPLICATION_SLOTコマンドのこの代替構文は引き続きサポートされています。
READ_REPLICATION_SLOT slot_name
#
レプリケーションスロットに関連付けられた情報を読みます。
レプリケーションスロットが存在しない場合は、NULL値を持つタプルが戻されます。
このコマンドは現在、物理レプリケーションスロットでのみサポートされています。
このコマンドへの応答として、サーバは以下のフィールドを含む1行の結果セットを返します。
slot_type (text)
レプリケーションスロットのタイプ、physicalまたはNULL。
restart_lsn (text)
レプリケーションスロットのrestart_lsn。
restart_tli (int8)
現在のタイムライン履歴に従って、restart_lsnに関連付けられたタイムラインID。
START_REPLICATION [ SLOT slot_name ] [ PHYSICAL ] XXX/XXX [ TIMELINE tli ]
#
サーバに対して、WALのストリーミングをXXX/XXX WAL時点から開始するよう指示します。
TIMELINEオプションが指定された場合、ストリーミングはtliのタイムラインから開始されます。
そうでなければ、サーバの現在のタイムラインが選択されます。
サーバが、例えば、要求されたWALの断片がすでに回収されているなど、エラーを返すことがありえます。
成功時サーバはCopyBothResponseメッセージで応答し、フロントエンドに対するWALストリームを開始します。
slot_nameを経由してスロット名が提供された場合、それはレプリケーションの進行として更新されます。
それによってサーバは、どのWALセグメントがまだスタンバイに必要か、hot_standby_feedbackのトランザクションはどれか、を感知します。
最新ではなくて、サーバの過去のタイムラインをクライアントが要求した場合、サーバは要求された開始時点から他のタイムラインに切り替えるまでの、全てのWALストリームを送付します。 クライアントが旧タイムラインの終点のストリームを要求した場合、サーバはCOPYモード全体をスキップします。
最新でないタイムラインの全てのWALストリームを送付した後、サーバはCOPYモードを出ることによりストリームを終了します。
クライアントもCOPYモードを出ることにより承認した場合、サーバは2列単一行の結果セットを送付し、サーバにある次のタイムラインを示します。
最初の列は次のタイムラインID(int8型)であり、次の列は切り替えたWALの位置(text型)です。
通常切り替えた位置はWALストリームの終点ですが、昇格する前に再実行されなかった旧タイムラインからWALを送付するというまれな場合もあります。
最後に、サーバは２つのCommandCompleteメッセージ（一方はCopyDataを終了し、もう一方はSTART_REPLICATION自体を終了する）を送付し、新規のコマンドを受理できるようになります。
WALデータはCopyDataメッセージ群として送信されます。 （これにより他の情報を混在させることができます。 具体的にはサーバはストリーム開始後に失敗が起きた場合にErrorResponseメッセージを送信することができます。） サーバからクライアントへの各CopyDataメッセージのペイロード、は以下の書式のどれかを含みます。
メッセージをWALデータとして識別します。
このメッセージ内のWALの開始点。
サーバ上の現在のWAL終了点。
転送時点でのサーバのシステム時刻。 2000年1月1日午前0時からのマイクロ秒。
nWALデータストリームの断片。
単一のWALレコードが2つのXLogDataメッセージに分かれることはありません。 しかしWALレコードがWALページ境界を跨る場合、継続レコードを用いてすでに分割されていますので、ページ境界で分割することができます。 言い換えると、先頭の主WALレコードとその継続レコードは、別のXLogDataメッセージとして分かれることがありえます。
メッセージを送信元キープアライブとして識別します。
サーバ上の現在のWAL終端。
転送時点でのサーバのシステム時刻。 2000年1月1日午前0時からのマイクロ秒。
タイムアウトによる切断を避けるため、クライアントがこのメッセージに即時に応答するべき方法の1つ。 0またはその他
以下のメッセージ書式の1つ（およびCopyDataメッセージのペイロード中のもの）を使用して、受理プロセスは送信者にいつでも応答できます。
メッセージを受信側の状態更新として識別します。
スタンバイにおいて受信しディスクに書き込まれた最終WALバイト+1の場所。
スタンバイにおいてディスクにフラッシュされた最終WALバイト+1の場所。
スタンバイにおいて適用された最終WALバイト+1の場所。
転送時点でのクライアントのシステム時刻。 2000年1月1日午前0時からのマイクロ秒。
値が1の場合、このメッセージにすぐ応答するように、クライアントはサーバへ要求します。 この方法は、接続がまだ保持されているか検査するために、サーバへのピング送信として使用できます。
メッセージをホットスタンバイのフィードバックメッセージとして識別します。
転送時点でのクライアントのシステム時刻。 2000年1月1日午前0時からのマイクロ秒。
スタンバイの現在のグローバルのxminですが、すべてのレプリケーションスロットのcatalog_xminは除きます。 この値と次のcatalog_xminがいずれも0なら、この接続ではホットスタンバイのフィードバックはもう送信されないという通知として扱われます。 後でゼロでないメッセージによりフィードバック機構を再開することができます。
スタンバイのグローバルのxmin xidのエポックです。
スタンバイのすべてのレプリケーションスロットのcatalog_xminの最小値です。 スタンバイ上にcatalog_xminが存在しない、あるいはホットスタンバイのフィードバックが無効化されている場合は0に設定します。
スタンバイのcatalog_xmin xidのエポックです。
START_REPLICATION SLOT slot_name LOGICAL XXX/XXX [ ( option_name [ option_value ] [, ...] ) ] #
サーバに対して、XXX/XXXWAL時点かスロットconfirmed_flush_lsn(54.19参照)のどちらか大きい方から、論理的レプリケーションのWALストリームを開始するよう指示します。
この動作により、クライアントは処理するデータがないときにローカルLSNステータスを更新しないようにしやすくなります。
しかし、要求されたLSNとは異なるLSNで開始すると、特定の種類のクライアントエラーを検出できない可能性があります。
したがって、クライアントはSTART_REPLICATIONを発行する前にconfirmed_flush_lsnが期待どおりであることを確認したい場合があります。
サーバは、スロットが存在しない場合などにエラーを返すことができます。 成功すると、サーバはCopyBothResponseメッセージで応答し、フロントエンドへのWALのストリーミングを開始します。
CopyBothResponse内部のメッセージは、2つのCommandCompleteメッセージを含めてSTART_REPLICATION ... PHYSICALの記述と同じ書式です。
選択されたスロットに関連した出力プラグインは、出力ストリームの処理に使用されます。
SLOT slot_name
ストリームを変更したスロット名。
このパラメータは必須であり、LOGICALモードにおいてCREATE_REPLICATION_SLOTによって作成された、実在する論理的レプリケーションスロットに対応しなければなりません。
XXX/XXXストリームを開始するWAL時点。
option_name
レプリケーションスロットのロジカルデコーディング出力プラグインに渡すオプション名。
標準(pgoutput)プラグインで受け付けられるオプションについては55.5を参照してください。
option_valueオプションの値。 文字列定数の形式。
DROP_REPLICATION_SLOT slot_name [ WAIT ]
#レプリケーションスロットを削除し、サーバ側で準備した資源を解放します。 このスロットが、walsenderが接続しているデータベース以外のデータベースで作成された論理スロットの場合、このコマンドは失敗します。
slot_name削除するスロット名。
WAITこのオプションを使用すると、スロットが使用中の時に、スロットの使用が終わるまでコマンドを待機させます。 デフォルトの動作ではエラーを発生させます。
BASE_BACKUP [ ( option [, ...] ) ]
#ベースバックアップのストリーミングを開始するようにサーバーに指示します。 システムは自動的に、バックアップが開始される前にバックアップモードに入り、バックアップが完了するとバックアップモードから出ます。 次のオプションを使用できます。
LABEL 'label'
バックアップのラベルを設定します。
何も指定しない場合は、base backupのバックアップラベルが使用されます。
ラベルの引用符付け規則は、standard_conforming_stringsをオンにした標準SQL文字列と同じです。
TARGET 'target'
バックアップの送信先をサーバに通知します。
ターゲットがclientの場合、デフォルトでバックアップデータがクライアントに送信されます。
ターゲットがserverの場合、バックアップデータはサーバのTARGET_DETAILオプションで指定されたパス名に書き込まれます。
ターゲットがblackholeの場合、バックアップデータはどこにも送信されず、単に破棄されます。
serverターゲットはスーパーユーザ権限を必要とするか、pg_write_server_filesロールを与えられている必要があります。
TARGET_DETAIL 'detail'バックアップターゲットに関する追加情報を提供します。
現在、このオプションはバックアップターゲットがサーバの場合にのみ使用できます。
バックアップを書き込むサーバディレクトリを指定します。
PROGRESS [ boolean ]trueの場合、進行状況の報告を生成するために必要な情報を要求します。 これは、ストリームが完了するまでにどのくらいかかるかを計算するために使用することができる、各テーブル空間のヘッダ内の概算容量を返送します。 これは、転送を始める前のすべてのファイルサイズを１度数え上げることで計算されます。 これ自体が性能に与える悪影響があるかもしれません。 特に最初のデータがストリームされるまでにより多くの時間がかかる可能性があります。 データベースファイルはバックアップの間変更される可能性がありますので、容量は概算に過ぎず、概算時と実ファイルを送信するまでの間に増減される可能性があります。 デフォルトはfalseです。
CHECKPOINT { 'fast' | 'spread' }
ベースバックアップの開始時に実行されるチェックポイントのタイプを設定します。
デフォルトはspreadです。
WAL [ boolean ]
trueの場合、バックアップ内に必要なWALセグメントを含めます。
ベースディレクトリtarファイルのpg_walディレクトリにある、バックアップの開始から終了までのすべてのファイルが含まれます。
デフォルトはfalseです。
WAIT [ boolean ]trueの場合、バックアップは必要な最終WALセグメントがアーカイブされるまで待機します。 WALアーカイブが有効でない場合は警告が発せられます。 falseの場合、バックアップは待機も警告もせず、必要なログが利用できるようになったことの確認をクライアントに任せます。 デフォルトはtrueです。
COMPRESSION 'method'
指定された方式を使用してバックアップを圧縮するようサーバに指示します。
現在サポートされている方式は、gzip、lz4およびzstdです。
COMPRESSION_DETAIL detail
選択した圧縮方式の詳細を指定します。
これはCOMPRESSIONオプションと一緒にのみ使用します。
値が整数の場合は、圧縮レベルを指定します。
それ以外の場合は、カンマで区切られたアイテムのリストであり、それぞれの形式はkeywordまたはkeyword=valueです。
現在サポートされているキーワードはlevel、longおよびworkersです。
levelキーワードは圧縮レベルを設定します。
gzipの場合、圧縮レベルは1から9までの整数（デフォルトZ_DEFAULT_COMPRESSIONまたは-1）、lz4の場合は1から12までの整数（高速圧縮モードの場合デフォルト0）、zstdの場合はZSTD_minCLevel()（通常-131072）からZSTD_maxCLevel()（通常は22）、（デフォルトはZSTD_CLEVEL_DEFAULTまたは3）までの整数です。
longキーワードは、長距離一致モードを有効にします。 これにより、圧縮率は向上しますが、メモリ使用量は増加します。
長距離モードはzstdに対してのみサポートされます。
workersキーワードは、並列圧縮に使用するスレッドの数を設定します。
並列圧縮はzstdでのみサポートされています。
MAX_RATE rateサーバからクライアントへ転送する単位時間当たりの最大データ容量を制限します（絞ります）。 予期される単位はkB/s（キロバイト/秒）です。 このオプションが指定された場合、値はゼロまたは32 kB以上1 GB以下でなければなりません。 ゼロが渡されるかオプションが指定されない場合、転送の制約は課されません。
TABLESPACE_MAP [ boolean ]
trueの場合、ディレクトリpg_tblspcにあるシンボリックリンクに関する情報をtablespace_mapという名前のファイルに含めます。
テーブル空間マップファイルには、ディレクトリpg_tblspc/に存在する各シンボリックリンクの名前とそのシンボリックリンクのフルパスが含まれています。
デフォルトはfalseです。
VERIFY_CHECKSUMS [ boolean ]trueの場合、チェックサムが有効になっていれば、ベース・バックアップ中にチェックサムが検証されます。 falseの場合、スキップされます。 デフォルトはtrueです。
MANIFEST manifest_option
このオプションをyesまたはforce-encodeの値で設定すると、バックアップマニフェストが作成され、バックアップとともに送信されます。
マニフェストは、含まれる可能性のあるWALファイルを除きバックアップ内に存在するすべてのファイルのリストです。
また、サイズ、最終更新時刻、オプションでファイル毎のチェックサムも格納します。
force-encodeの値は、全てのファイル名を強制的に16進数でエンコーディングします。
それ以外の場合、このタイプのエンコードは、名前が非UTF-8オクテットシーケンスであるファイルに対してのみ実行されます。
force-encodeは、主にテスト目的で使用されており、バックアップマニフェストを読み取るクライアントがこのケースを処理できることを確認するために使用されます。
以前のリリースとの互換性を保つため、デフォルトは、MANIFEST 'no'です。
MANIFEST_CHECKSUMS checksum_algorithm
バックアップマニフェストに含まれている各ファイルに適用するチェックサムアルゴリズムを指定します。
現在使用可能なアルゴリズムは、NONE、CRC32C、SHA224, SHA256、SHA384、SHA512です。
デフォルトはCRC32Cです。
バックアップを開始する時、サーバはまず２つの通常の結果セットを送信し、続けて１つ以上のCopyOutResponse結果を送信します。
最初の通常の結果セットには、1行2列という形でバックアップの開始位置が含まれます。 最初の列にはXLogRecPtr書式の開始位置が、２番目の列には対応するタイムラインIDが含まれます。
２番目の通常の結果セットには各テーブル空間に付き１行を持ちます。 この行のフィールドは以下の通りです。
spcoid (oid)テーブル空間のOIDです。 ベースディレクトリの場合はNULLです。
spclocation (text)テーブル空間ディレクトリのフルパスです。 ベースディレクトリの場合はNULLです。
size (int8)進行状況の報告が要求された場合は、テーブル空間の概算容量です（キロバイト(1024バイト)単位）。 要求されていない場合はNULLです。
２番目の通常の結果セットの後、CopyOutResponseが送信されます。 各CopyDataメッセージのペイロードには、次のいずれかの形式のメッセージが含まれます
新規アーカイブの開始を示すメッセージを識別します。 メインデータディレクトリ用に1つのアーカイブがあり、追加テーブル空間ごとに1つのアーカイブがあります。 各アーカイブはtarフォーマットを使用します（POSIX 1003.1-2008標準で規定されている「ustar交換形式」に従う）。
このアーカイブのファイル名。
メインデータディレクトリの場合は空の文字列。 その他のテーブル空間の場合は、このアーカイブが作成されたディレクトリへのフルパス。
バックアップマニフェストの開始を示すメッセージを識別します。
メッセージにアーカイブデータまたはマニフェストデータが含まれていることを識別します。
nデータバイト。
メッセージが進捗レポートであることを識別します。
処理が完了した現在のテーブル空間のバイト数。
CopyOutResponse、あるいはこのような応答の全てが送信された後に、バックアップのWAL終了位置を含む通常の最終結果セットが開始位置と同じフォーマットで送信されます。
データディレクトリと各テーブル空間のtarアーカイブには、そのディレクトリ内のファイルがPostgreSQLファイルかそのディレクトリに追加された他のファイルかに関係なく、すべて含まれます。 以下に除かれるファイルを示します。
postmaster.pid
postmaster.opts
pg_internal.init（複数のディレクトリに在ります）
PostgreSQLサーバの操作中に作成される種々の一時ファイルおよびディレクトリで、pgsql_tmpで始まるすべてのファイルおよびディレクトリ、および一時リレーション。
ログを取らないリレーション。ただし、リカバリでログを取らないリレーションの再作成に必要なinitフォークは除かれない。
サブディレクトリを含むpg_wal。
バックアップがwalファイルを含めて実行される場合、合成された版のpg_walが含まれます。
これにはバックアップが動作するために必要なファイルのみが含まれ、残りの内容は含まれません。
pg_dynshmem、pg_notify、pg_replslot、pg_serial、pg_snapshots、pg_stat_tmp、pg_subtransは（それがシンボリックリンクであったとしても）空のディレクトリとしてコピーされます。
シンボリックリンク（上記で列挙したディレクトリは除きます）や特殊デバイスファイル、オペレーティングシステムのファイルなど、通常のファイルとディレクトリ以外のものは省略されます。
（pg_tblspc中のシンボリックリンクは保持されます。）
サーバ上の基盤となるファイルシステムがサポートする場合、所有者、グループ、ファイルのモードが設定されます。