他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

46.3. ストリーミングレプリケーションプロトコル

ストリーミングレプリケーションを初期化するために、フロントエンドは開始メッセージにてreplicationパラメータを送信します。 これはバックエンドに対して、SQL文ではなく小規模なレプリケーションコマンド群を発行できるようになる、walsenderモードに入るように伝えます。 walsenderモードでは簡易問い合わせプロトコルのみを使用することができます。 walsenderモードで受け付けられるコマンドは以下の通りです。

IDENTIFY_SYSTEM

サーバに自身を識別することを要求します。 サーバは以下の3つのフィールドを持つ単一行の結果セットをもって応答します。

systemid

クラスタを識別する一意なシステム識別子です。 これを使用してスタンバイを初期化するために使用するベースバックアップが同じクラスタに由来していることを検査することができます。

timeline

現在のTimelineIDです。 同様にスタンバイがマスタと一貫性を持つことを検査するために使用されます。

xlogpos

現在のxlogの書き出し位置です。 ストリーミングを開始できるトランザクションログの既知の位置を得る際に有用です。

START_REPLICATION XXX/XXX

サーバに対して、WALのストリーミングをXXX/XXX WAL時点から開始するよう指示します。 サーバが、例えば、要求されたWALの断片がすでに回収されているなど、エラーを返すことがありえます。 成功時サーバはCopyBothResponseメッセージで応答し、フロントエンドに対するWALのストリーミングを開始します。 WALのストリーミングは接続が壊れるまで継続され、他に受け付けられるコマンドはありません。

WALデータはCopyDataメッセージ群として送信されます。 (これにより他の情報を混在させることができます。 具体的にはサーバはストリーム開始後に失敗が起きた場合にErrorResponseメッセージを送信することができます。) CopyDataメッセージのペイロードは以下の書式に従います。

XLogData (B)

Byte1('w')

メッセージをWALデータとして識別します。

Byte8

このメッセージ内のWALの開始点。 書式はXLogRecPtrです。

Byte8

サーバ上の現在のWAL終了点。 書式はXLogRecPtrです。

Byte8

トランザクションの時点でのサーバのシステム時刻。 書式はTimestampTzです。

Byten

WALデータストリームの断片。

単一のWALレコードが2つのCopyDataメッセージに分かれることはありません。 しかしWALレコードがWALページ境界を跨る場合、継続レコードを用いてすでに分割されていますので、ページ境界で分割することができます。 言い換えると、先頭の主WALレコードとその継続レコードは、別のCopyDataメッセージとして分かれることがありえます。

WALデータ内のすべてのフィールドと上記ヘッダが送信元サーバ用の書式であることに注意してください。 エンディアンやタイムスタンプの書式は受信側が送信元のシステム識別子が自身のpg_controlの内容と一致するかどうかを検証しない限り予測できません。

WAL送信プロセスが(postmasterの停止中に)正常に終了する場合、終了前にCommandCompleteメッセージを送信します。 当然ながら異常終了の場合にはこれは送信されないかもしれません。

受信側のプロセスはいつでも送信側に、以下のメッセージ書式のいずれかを使用して、応答を返送することができます。

スタンバイ状態の更新(F)

Byte1('r')

メッセージを受信側の状態更新として識別します。

Byte8

スタンバイにおいて受信しディスクに書き込まれた最終WALバイト+1のXLogRecPtr書式の場所。

Byte8

スタンバイにおいてディスクに吐き出された最終WALバイト+1のXLogRecPtr書式の場所。

Byte8

スタンバイにおいて適用された最終WALバイト+1のXLogRecPtr書式の場所。

Byte8

送信時のサーバのシステムクロック(TimestampTz書式)です。

ホットスタンバイフィードバックメッセージ(F)

Byte1('h')

メッセージをホットスタンバイのフィードバックメッセージとして識別します。

Byte8

送信時のサーバのシステムクロック(TimestampTz書式)です。

Byte4

スタンバイの現在のxminです。

Byte4

スタンバイの現在のエポックです。

BASE_BACKUP [LABEL 'label'] [PROGRESS] [FAST] [WAL] [NOWAIT]

サーバにベースバックアップのストリーミングを始めるよう指示します。 システムはバックアップが開始される前に自動的にバックアップモードになり、バックアップが完了した時に取り出されます。 以下のオプションを受け付けることができます。

LABEL 'label'

バックアップのラベルを設定します。 指定がない場合、base backupというバックアップラベルが使用されます。 ラベルについての引用符付け規則は、standard_conforming_stringsを有効にした場合の標準SQLの文字列の規則と同じです。

PROGRESS

進行状況の報告を生成するために必要な情報を要求します。 これは、ストリームが完了するまでにどのくらいかかるかを計算するために使用することができる、各テーブル空間のヘッダ内の概算容量を返送します。 これは、転送を始める前のすべてのファイルサイズを1度数え上げることで計算されます。 これ自体が性能に与える悪影響があるかもしれません。 特に最初のデータがストリームされるまでにより多くの時間がかかる可能性があります。 データベースファイルはバックアップの間変更される可能性がありますので、容量は概算に過ぎず、概算時と実ファイルを送信するまでの間に増減される可能性があります。

FAST

高速チェックポイントを要求します。

WAL

バックアップ内に必要なWALセグメントを含めます。 ベースディレクトリtarファイルのpg_xlogディレクトリにある、バックアップの開始から終了までのすべてのファイルが含まれます。

NOWAIT

デフォルトでは、バックアップは必要な最終xlogセグメントがアーカイブされるまで待機します。 ログアーカイブが有効でない場合は警告が発せられます。 NOWAITにより、必要なログが利用できるようになったことを確認することをクライアント側の責任として、この待機や警告が無効になります。

バックアップを開始する時、サーバはまず2つの通常の結果セットを送信し、続けて1つ以上のCopyResponse結果を送信します。

最初の通常の結果セットには、単一行の単一列という形でXLogRecPtr書式のバックアップの開始位置が含まれます。

2番目の通常の結果セットには各テーブル空間に付き1行を持ちます。 この行のフィールドは以下の通りです。

spcoid

テーブル空間のoidです。 ベースディレクトリの場合はNULLです。

spclocation

テーブル空間ディレクトリのフルパスです。 ベースディレクトリの場合はNULLです。

size

進行状況報告が要求された場合は、テーブル空間の概算容量です。 要求されていない場合はNULLです。

2番目の通常の結果セットの後、1つ以上のCopyResponse結果が送信されます。 1つはPGDATA用、pg_defaultpg_global以外の追加のテーブル空間ごとに1つ送信されます。 CopyResponse結果内のデータは、テーブル空間の内容のtar形式ダンプ(ustar00拡張を使用)です。 このtarデータが終わった後、最終の通常結果セットが送信されます。

データディレクトリと各テーブル空間のtarアーカイブには、そのディレクトリ内のファイルがPostgreSQLファイルかそのディレクトリに追加された他のファイルかに関係なく、すべて含まれます。 以下に除かれるファイルを示します。

  • postmaster.pid

  • postmaster.opts

  • サブディレクトリを含むpg_xlog。 バックアップがwalファイルを含めて実行される場合、合成された版のpg_xlogが含まれます。 これにはバックアップが動作するために必要なファイルのみが含まれ、残りの内容は含まれません。

サーバ上の基盤となるファイルシステムがサポートする場合、所有者、グループ、ファイルのモードが設定されます。

すべてのテーブル空間が送信された後、最終の通常の結果セットが送信されます。 この結果セットには、単一行の単一列という形でXLogRecPtr書式のバックアップの終了位置が含まれます。