PostgreSQL 9.4.5文書 | |||
---|---|---|---|
前のページ | 上に戻る | 第 49章フロントエンド/バックエンドプロトコル | 次のページ |
ストリーミングレプリケーションを初期化するために、フロントエンドは開始メッセージにてreplicationパラメータを送信します。 ブール値のtrueがバックエンドに対して、SQL文ではなく小規模なレプリケーションコマンド群を発行できるようになる、walsenderモードに入るように伝えます。 walsenderモードでは簡易問い合わせプロトコルのみを使用することができます。 databaseを値として渡すことにより、 dbnameパラメータに指定したデータベースに接続することをwalsenderに教えます。 それにより、そのデータベースからの論理的レプリケーションとして使用する接続が可能となります。
レプリケーションコマンドをテストするために、replicationオプションを含む接続文字列を使用して、psqlまたは他のlibpqによるレプリケーション接続を作成できます。 例を示します。
psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
しかし、物理的レプリケーションのためにpg_receivexlogを使用し、論理的レプリケーションのためにpg_recvlogicalを使用すれば、もっと有用なことが多いです。
walsenderモードで受け付けられるコマンドは以下の通りです。
サーバに自身を識別することを要求します。 サーバは以下の4つのフィールドを持つ単一行の結果セットをもって応答します。
クラスタを識別する一意なシステム識別子です。 これを使用してスタンバイを初期化するために使用するベースバックアップが同じクラスタに由来していることを検査することができます。
現在のタイムラインIDです。 同様にスタンバイがマスタと一貫性を持つことを検査するために使用されます。
現在のxlogの吐き出し位置です。 ストリーミングを開始できるトランザクションログの既知の位置を得る際に有用です。
接続したデータベース名またはNULLです。
tliのタイムラインのため、サーバにTIMELINE HISTORYファイルの送付を要求します。 サーバは2列単一行の結果セットを返します。
TIMELINE HISTORYファイル名、例えば00000002.history
TIMELINE HISTORYファイルの内容
物理的または論理的レプリケーションスロットを作成します。 レプリケーションスロットの詳細は項25.2.6を参照。
サーバに対して、WALのストリーミングをXXX/XXX WAL時点から開始するよう指示します。 TIMELINEオプションが指定された場合、ストリーミングはtliのタイムラインから開始されます。 そうでなければ、サーバの現在のタイムラインが選択されます。 サーバが、例えば、要求されたWALの断片がすでに回収されているなど、エラーを返すことがありえます。 成功時サーバはCopyBothResponseメッセージで応答し、フロントエンドに対するWALストリームを開始します。
slot_nameを経由してスロット名が提供された場合、それはレプリケーションの進行として更新されます。 それによってサーバは、どのWALセグメントがまだスタンバイに必要か、hot_standby_feedbackのトランザクションはどれか、を感知します。
最新ではなくて、サーバの過去のタイムラインをクライアントが要求した場合、サーバは要求された開始時点から他のタイムラインに切り替えるまでの、全てのWALストリームを送付します。 クライアントが旧タイムラインの終点のストリームを要求した場合、サーバはCOPYモードに入らずにCommandCompleteをすぐに応答します。
最新でないタイムラインの全てのWALストリームを送付した後、サーバはCOPYモードを出ることによりストリームを終了します。 クライアントもCOPYモードを出ることにより承認した場合、サーバは2列単一行の結果セットを送付し、サーバにある次のタイムラインを示します。 最初の列は次のタイムラインIDであり、次の列は切り替えたXLOGの位置です。 通常切り替えた位置はWALストリームの終点ですが、昇格する前に再実行されなかった旧タイムラインからWALを送付するというまれな場合もあります。 最後に、サーバはCommandCompleteメッセージを送付し、新規のコマンドを受理できるようになります。
WALデータはCopyDataメッセージ群として送信されます。 (これにより他の情報を混在させることができます。 具体的にはサーバはストリーム開始後に失敗が起きた場合にErrorResponseメッセージを送信することができます。) サーバからクライアントへの各CopyDataメッセージのペイロード、は以下の書式のどれかを含みます。
メッセージをWALデータとして識別します。
このメッセージ内のWALの開始点。
サーバ上の現在のWAL終了点。
転送時点でのサーバのシステム時刻。 2000年1月1日午前0時からのマイクロ秒。
WALデータストリームの断片。
単一の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です。 もはやホットスタンバイフィードバックがこの接続では送信されないという通知を、スタンバイが送信している場合、この値は0でしょう。 後ほど、0でないメッセージがフィードバック機構を再び開始します。
スタンバイの現在のエポックです。
サーバに対して、XXX/XXXWAL時点から、論理的レプリケーションのWALストリームを開始するよう指示します。 例えば、要求されたWALがすでに回収された場合、サーバはエラーを返します。 サーバが、例えば、要求されたWALセクションがすでに回収されている場合、エラーを返すことがありえます。 成功時サーバはCopyBothResponseメッセージで応答し、フロントエンドに対するWALストリームを開始します。
CopyBothResponse内部のメッセージは、START_REPLICATION ... PHYSICALの記述と同じ書式です。
選択されたスロットに関連した出力プラグインは、出力ストリームの処理に使用されます。
ストリームを変更したスロット名。 このパラメータは必須であり、LOGICALモードにおいてCREATE_REPLICATION_SLOTによって作成された、実在する論理的レプリケーションスロットに対応しなければなりません。
ストリームを開始するWAL時点。
レプリケーションスロットのロジカルデコーディング出力プラグインに渡すオプション名。
オプションの値。 文字列定数の形式。
レプリケーションスロットを削除し、サーバ側で準備した資源を解放します。 実行中の接続に現在スロットが使用中の場合、このコマンドは失敗します。
削除するスロット名。
サーバにベースバックアップのストリーミングを始めるよう指示します。 システムはバックアップが開始される前に自動的にバックアップモードになり、バックアップが完了した時に取り出されます。 以下のオプションを受け付けることができます。
バックアップのラベルを設定します。 指定がない場合、base backupというバックアップラベルが使用されます。 ラベルについての引用符付け規則は、standard_conforming_stringsを有効にした場合の標準SQLの文字列の規則と同じです。
進行状況の報告を生成するために必要な情報を要求します。 これは、ストリームが完了するまでにどのくらいかかるかを計算するために使用することができる、各テーブル空間のヘッダ内の概算容量を返送します。 これは、転送を始める前のすべてのファイルサイズを1度数え上げることで計算されます。 これ自体が性能に与える悪影響があるかもしれません。 特に最初のデータがストリームされるまでにより多くの時間がかかる可能性があります。 データベースファイルはバックアップの間変更される可能性がありますので、容量は概算に過ぎず、概算時と実ファイルを送信するまでの間に増減される可能性があります。
高速チェックポイントを要求します。
バックアップ内に必要なWALセグメントを含めます。 ベースディレクトリtarファイルのpg_xlogディレクトリにある、バックアップの開始から終了までのすべてのファイルが含まれます。
デフォルトでは、バックアップは必要な最終xlogセグメントがアーカイブされるまで待機します。 ログアーカイブが有効でない場合は警告が発せられます。 NOWAITにより、必要なログが利用できるようになったことを確認することをクライアント側の責任として、この待機や警告が無効になります。
サーバからクライアントへ転送する単位時間当たりの最大データ容量を制限します(絞ります)。 予期される単位はkB/s(キロバイト/秒)です。 このオプションが指定された場合、値はゼロまたは32 kB以上1 GB以下でなければなりません。 ゼロが渡されるかオプションが指定されない場合、転送の制約は課されません。
バックアップを開始する時、サーバはまず2つの通常の結果セットを送信し、続けて1つ以上のCopyResponse結果を送信します。
最初の通常の結果セットには、1行2列という形でバックアップの開始位置が含まれます。 最初の列にはXLogRecPtr書式の開始位置が、2番目の列には対応するタイムラインIDが含まれます。
2番目の通常の結果セットには各テーブル空間に付き1行を持ちます。 この行のフィールドは以下の通りです。
テーブル空間のoidです。 ベースディレクトリの場合はNULLです。
テーブル空間ディレクトリのフルパスです。 ベースディレクトリの場合はNULLです。
進行状況報告が要求された場合は、テーブル空間の概算容量です。 要求されていない場合はNULLです。
2番目の通常の結果セットの後、1つ以上のCopyResponse結果が送信されます。 1つはPGDATA用、pg_default、pg_global以外の追加のテーブル空間ごとに1つ送信されます。 CopyResponse結果内のデータは、テーブル空間の内容のtar形式(POSIX 1003.1-2008標準で規定された"ustar交換形式"に従う)ダンプです。 ただし標準で規定された最後の2つのゼロブロックは省略されています。 このtarデータが終わった後、最終の通常結果セットが送信されます。 結果セットには、開始位置と同じ書式のバックアップのWAL終了位置が含まれます。
データディレクトリと各テーブル空間のtarアーカイブには、そのディレクトリ内のファイルがPostgreSQLファイルかそのディレクトリに追加された他のファイルかに関係なく、すべて含まれます。 以下に除かれるファイルを示します。
postmaster.pid
postmaster.opts
PostgreSQLサーバの操作中に、種々の一時ファイルが作成されます。
サブディレクトリを含むpg_xlog。 バックアップがwalファイルを含めて実行される場合、合成された版のpg_xlogが含まれます。 これにはバックアップが動作するために必要なファイルのみが含まれ、残りの内容は含まれません。
pg_replslotが空ディレクトリとしてコピーされます。
通常のファイルとディレクトリ以外のもの、シンボリックリンクや特殊なデバイスファイルは省略されます。 (pg_tblspc中のシンボリックリンクは保持されます。)
サーバ上の基盤となるファイルシステムがサポートする場合、所有者、グループ、ファイルのモードが設定されます。
すべてのテーブル空間が送信された後、最終の通常の結果セットが送信されます。 この結果セットには、単一行の単一列という形でXLogRecPtr書式のバックアップの終了位置が含まれます。