バージョンごとのドキュメント一覧

20.6. レプリケーション #

<title>Replication</title>

These settings control the behavior of the built-in <firstterm>streaming replication</firstterm> feature (see <xref linkend="streaming-replication"/>), and the built-in <firstterm>logical replication</firstterm> feature (see <xref linkend="logical-replication"/>). これらの設定は、組み込みストリーミングレプリケーション機能(27.2.5参照)および組み込みロジカルレプリケーション機能(第31章を参照)の動作を制御します。 27.2.5

For <emphasis>streaming replication</emphasis>, servers will be either a primary or a standby server. Primaries can send data, while standbys are always receivers of replicated data. When cascading replication (see <xref linkend="cascading-replication"/>) is used, standby servers can also be senders, as well as receivers. Parameters are mainly for sending and standby servers, though some parameters have meaning only on the primary server. Settings may vary across the cluster without problems if that is required. ストリーミングレプリケーションでは、サーバ群のサーバはプライマリかスタンバイのいずれかです。 プライマリはデータを送出する一方、複数のスタンバイは複製されたデータを常に受け取ります。 カスケードレプリケーション(27.2.7を参照)が使用されている場合、スタンバイサーバ群は受け取り手でもあり、送り手でもあります。 パラメータは主として送出サーバとスタンバイサーバ用ですが、いくつかのパラメータはプライマリサーバのみに効力を発します。 必要とあればクラスタに渡って問題なく設定を変化させることができます。

For <emphasis>logical replication</emphasis>, <firstterm>publishers</firstterm> (servers that do <link linkend="sql-createpublication"><command>CREATE PUBLICATION</command></link>) replicate data to <firstterm>subscribers</firstterm> (servers that do <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>). Servers can also be publishers and subscribers at the same time. Note, the following sections refer to publishers as "senders". For more details about logical replication configuration settings refer to <xref linkend="logical-replication-config"/>. ロジカルレプリケーションの場合、パブリッシャー(CREATE PUBLICATIONを実行するサーバ)は、データをサブスクライバーCREATE SUBSCRIPTIONを実行するサーバ)に複製します。 サーバは、パブリッシャーとサブスクライバーを同時に兼ねることもできます。 次の項でパブリッシャーを「送信者」と呼ぶことに注意してください。 ロジカルレプリケーション設定設定の詳細は、31.10を参照してください。

20.6.1. 送出サーバ群 #

<title>Sending Servers</title>

These parameters can be set on any server that is to send replication data to one or more standby servers. The primary is always a sending server, so these parameters must always be set on the primary. The role and meaning of these parameters does not change after a standby becomes the primary. これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るすべてのサーバ上で設定することができます。 プライマリは常に送出サーバであるため、パラメータは常にプライマリ上に設定されなければなりません。 これらのパラメータの役割と意味はスタンバイが後にプライマリに昇格しても変わりません。

max_wal_senders (integer) #

Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is <literal>10</literal>. The value <literal>0</literal> means replication is disabled. Abrupt disconnection of a streaming client might leave an orphaned connection slot behind until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. Also, <varname>wal_level</varname> must be set to <literal>replica</literal> or higher to allow connections from standby servers. 複数のスタンバイサーバあるいは、ストリーミングを使ったベースバックアップクライアントからの同時接続を受ける接続最大値を設定します(つまり、同時に稼働するWAL送信プロセスの最大値です)。 デフォルトは10です。 0ならば、レプリケーションは無効であるという意味になります。 ストリーミングクライアントの突然の切断により、タイムアウトになるまで親のない接続スロットが残ることがあります。 ですから、このパラメータは想定されるクライアント数の最大値よりも少し大きめにして、切断されたクライアントが直ちに再接続できるようにした方が良いでしょう。 このパラメータはサーバ起動時のみ設定可能です。 また、スタンバイサーバからの接続を許可するには、wal_levelreplica以上に設定しておかなければなりません。

When running a standby server, you must set this parameter to the same or higher value than on the primary server. Otherwise, queries will not be allowed in the standby server. スタンバイサーバを実行する際は、このパラメータをプライマリサーバと同じか高い値にしなければなりません。 さもなければ、スタンバイサーバでクエリを実行できなくなります。

max_replication_slots (integer) #

Specifies the maximum number of replication slots (see <xref linkend="streaming-replication-slots"/>) that the server can support. The default is 10. This parameter can only be set at server start. Setting it to a lower value than the number of currently existing replication slots will prevent the server from starting. Also, <varname>wal_level</varname> must be set to <literal>replica</literal> or higher to allow replication slots to be used. サーバが使用できるレプリケーションスロット(27.2.6参照)の最大数を指定します。 デフォルトは10です。 このパラメータはサーバ起動時のみ設定可能です。 現在存在しているレプリケーションスロットの数よりも少ない値を設定すると、サーバは起動しません。 また、レプリケーションスロットが使用できるためには、wal_levelreplica以上に設定しなければなりません。

Note that this parameter also applies on the subscriber side, but with a different meaning. このパラメータはサブスクライバー側にも適用されますが、意味が異なることに注意してください。

wal_keep_size (integer) #

Specifies the minimum size of past WAL files kept in the <filename>pg_wal</filename> directory, in case a standby server needs to fetch them for streaming replication. If a standby server connected to the sending server falls behind by more than <varname>wal_keep_size</varname> megabytes, the sending server might remove a WAL segment still needed by the standby, in which case the replication connection will be terminated. Downstream connections will also eventually fail as a result. (However, the standby server can recover by fetching the segment from archive, if WAL archiving is in use.) pg_walディレクトリに保持する過去のWALファイルの最小サイズを指定します。 もし送出サーバに接続しているスタンバイサーバがwal_keep_sizeメガバイトを越えて遅延した場合、送出サーバはスタンバイサーバが今後とも必要とするWALセグメントを削除する可能性があります。 この場合、レプリケーション接続は終了させられます。結果として下流に対する接続も結局は終了されることがあります。(しかし、WALアーカイブが使用されていれば、スタンバイサーバはアーカイブからセグメントを取り出し、復旧することができます。)

This sets only the minimum size of segments retained in <filename>pg_wal</filename>; the system might need to retain more segments for WAL archival or to recover from a checkpoint. If <varname>wal_keep_size</varname> is zero (the default), the system doesn't keep any extra segments for standby purposes, so the number of old WAL segments available to standby servers is a function of the location of the previous checkpoint and status of WAL archiving. If this value is specified without units, it is taken as megabytes. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. pg_walに保持され続けるセグメントの最小値のみを設定します。 システムはWALアーカイブのため、またはチェックポイントからの復旧のため、より多くのセグメント保持が必要となることがあります。 もしwal_keep_sizeが(デフォルトの)ゼロの場合、システムはスタンバイサーバのために追加セグメントを保持することはしません。 従って、スタンバイサーバが使用できる古いWALセグメントの数は、直前のチェックポイントの場所とWALアーカイブの状況によって算出されます。 この値が単位無しで指定されると、メガバイトであると見なします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_slot_wal_keep_size (integer) #

Specify the maximum size of WAL files that <link linkend="streaming-replication-slots">replication slots</link> are allowed to retain in the <filename>pg_wal</filename> directory at checkpoint time. If <varname>max_slot_wal_keep_size</varname> is -1 (the default), replication slots may retain an unlimited amount of WAL files. Otherwise, if restart_lsn of a replication slot falls behind the current LSN by more than the given size, the standby using the slot may no longer be able to continue replication due to removal of required WAL files. You can see the WAL availability of replication slots in <link linkend="view-pg-replication-slots">pg_replication_slots</link>. If this value is specified without units, it is taken as megabytes. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. チェックポイント時にレプリケーションスロットpg_walディレクトリに残すことのできる 最大のWALファイルのサイズを指定します。 max_slot_wal_keep_sizeが-1 (デフォルトです)なら、レプリケーションスロットは無制限のWALファイルを残すかも知れません。 そうでなければ、レプリケーションスロットのrestart_lsnが現在のLSNよりも与えられたサイズ分遅れると、そのスロットを使っているスタンバイは必要なWALファイルが削除されたためにレプリケーションを継続できなくなります。 レプリケーションスロットのWALが存在するかどうかはpg_replication_slotsを見て確認できます。 この値が単位無しで指定されると、メガバイトであると見なします。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

wal_sender_timeout (integer) #

Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. 指定された時間より長く非活動であるレプリケーション接続を停止します。 スタンバイサーバのクラッシュ、またはネットワークの停止を送出サーバが検出することにこれが役立ちます。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は60秒です。 値ゼロはこのタイムアウト機能を無効にします。

With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection. 地理的に複数の場所に分散したクラスタでは、場所によって異なる値を使うことでクラスタ管理がより柔軟にできるようになります。 より小さな値は低遅延ネットワーク接続上のスタンバイの障害検知をより高速にするのに役立ちます。 遅延の大きなネットワーク接続に設置されたスタンバイの健全性の判断にはより大きな値が助けになるでしょう。

track_commit_timestamp (boolean) #

Record commit time of transactions. This parameter can only be set in <filename>postgresql.conf</filename> file or on the server command line. The default value is <literal>off</literal>. トランザクションのコミットタイムを記録します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 デフォルトはoffです。

20.6.2. プライマリサーバ #

<title>Primary Server</title>

These parameters can be set on the primary server that is to send replication data to one or more standby servers. Note that in addition to these parameters, <xref linkend="guc-wal-level"/> must be set appropriately on the primary server, and optionally WAL archiving can be enabled as well (see <xref linkend="runtime-config-wal-archiving"/>). The values of these parameters on standby servers are irrelevant, although you may wish to set them there in preparation for the possibility of a standby becoming the primary. これらのパラメータはレプリケーションデータを1つ、またはそれ以上複数のスタンバイサーバに送るプライマリサーバ上で設定することができます。 これらパラメータに加え、wal_levelはプライマリサーバ上で適切に設定される必要があり、オプションとしてWALアーカイブを有効にしてもかまいません(20.5.3を参照してください)。 スタンバイサーバがプライマリサーバになるかもしれない状況に備え、それらのパラメータをスタンバイサーバで設定したいと考えたとしても、スタンバイサーバ上でのパラメータの値は意味をなしません。

synchronous_standby_names (string) #

Specifies a list of standby servers that can support <firstterm>synchronous replication</firstterm>, as described in <xref linkend="synchronous-replication"/>. There will be one or more active synchronous standbys; transactions waiting for commit will be allowed to proceed after these standby servers confirm receipt of their data. The synchronous standbys will be those whose names appear in this list, and that are both currently connected and streaming data in real-time (as shown by a state of <literal>streaming</literal> in the <link linkend="monitoring-pg-stat-replication-view"> <structname>pg_stat_replication</structname></link> view). Specifying more than one synchronous standby can allow for very high availability and protection against data loss. 27.2.8で説明されているように、同期レプリケーションをサポート可能なスタンバイサーバのリストを指定します。 活動中の同期スタンバイサーバは1つまたはそれ以上です。 コミットを待機しているトランザクションは、このスタンバイサーバがそのデータの受信を確認してから処理の継続が許可されます。 同期スタンバイサーバはこのリストに名前が挙げられていており、現時点で接続され、そしてデータをリアルタイムでストリーミングしているものです(pg_stat_replication ビューにおいてstreaming状態として示されています)。 このリストの後の方に記載されているその他のスタンバイサーバは潜在的に同期スタンバイサーバになることを示しています。 二つ以上の同期スタンバイサーバ名を指定することで、かなりの高可用性とデータ損失に対する保護が得られます。

The name of a standby server for this purpose is the <varname>application_name</varname> setting of the standby, as set in the standby's connection information. In case of a physical replication standby, this should be set in the <varname>primary_conninfo</varname> setting; the default is the setting of <xref linkend="guc-cluster-name"/> if set, else <literal>walreceiver</literal>. For logical replication, this can be set in the connection information of the subscription, and it defaults to the subscription name. For other replication stream consumers, consult their documentation. この目的のためのスタンバイサーバ名は、スタンバイの接続情報で指定された、スタンバイのapplication_name設定です。 物理レプリケーションスタンバイでは、primary_conninfo設定です。 デフォルトはcluster_nameの設定で、さもなければwalreceiverです。 論理レプリケーションでは、サブスクリプションの接続情報で設定でき、デフォルトはサブスクリプション名です。 それ以外のレプリケーションストリームコンシューマーについては、それぞれのドキュメントをご覧ください。

This parameter specifies a list of standby servers using either of the following syntaxes: このパラメータは、以下の構文のいずれかを用いてスタンバイサーバのリストを指定します。

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]

where <replaceable class="parameter">num_sync</replaceable> is the number of synchronous standbys that transactions need to wait for replies from, and <replaceable class="parameter">standby_name</replaceable> is the name of a standby server. <literal>FIRST</literal> and <literal>ANY</literal> specify the method to choose synchronous standbys from the listed servers. ここで、num_syncは、トランザクションが応答を待機する必要のある同期スタンバイの数です。 standby_nameは、スタンバイサーバの名前です。 FIRSTANYは、リスト中のサーバーから同期スタンバイを選ぶ方法を指定します。

The keyword <literal>FIRST</literal>, coupled with <replaceable class="parameter">num_sync</replaceable>, specifies a priority-based synchronous replication and makes transaction commits wait until their WAL records are replicated to <replaceable class="parameter">num_sync</replaceable> synchronous standbys chosen based on their priorities. For example, a setting of <literal>FIRST 3 (s1, s2, s3, s4)</literal> will cause each commit to wait for replies from three higher-priority standbys chosen from standby servers <literal>s1</literal>, <literal>s2</literal>, <literal>s3</literal> and <literal>s4</literal>. The standbys whose names appear earlier in the list are given higher priority and will be considered as synchronous. Other standby servers appearing later in this list represent potential synchronous standbys. If any of the current synchronous standbys disconnects for whatever reason, it will be replaced immediately with the next-highest-priority standby. The keyword <literal>FIRST</literal> is optional. キーワードFIRSTnum_syncと組み合わせると、優先度に基づく同期レプリケーションを指定し、優先度に基づいて選ばれたnum_sync個の同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットは待機します。 たとえばFIRST 3 (s1, s2, s3, s4)とすると、s1s2s3s4の中から選ばれた優先順位の高い3つのスタンバイサーバが応答を返すまでコミットは待機します。 リストの中で前の方に名前が出現するスタンバイには高い優先度が与えられ、同期と見なされます。 それ以外のリストの中で後の方に名前が上がっているスタンバイサーバーは、潜在的な同期スタンバイであることを表しています。 どんな理由であれ、現在の同期スタンバイが切断されると、次に高い優先度を持つスタンバイに直ちに取って代わられます。 キーワードFIRSTはオプションです。

The keyword <literal>ANY</literal>, coupled with <replaceable class="parameter">num_sync</replaceable>, specifies a quorum-based synchronous replication and makes transaction commits wait until their WAL records are replicated to <emphasis>at least</emphasis> <replaceable class="parameter">num_sync</replaceable> listed standbys. For example, a setting of <literal>ANY 3 (s1, s2, s3, s4)</literal> will cause each commit to proceed as soon as at least any three standbys of <literal>s1</literal>, <literal>s2</literal>, <literal>s3</literal> and <literal>s4</literal> reply. キーワードANYnum_syncと組み合わせると、クォーラムに基づく同期レプリケーションを指定し、列挙されたスタンバイのうち少なくともnum_sync個の同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットを待たせます。 たとえばANY 3 (s1, s2, s3, s4)とすると、s1s2s3s4のうちの少なくとも3つが応答を返した時点でコミットが進行します。

<literal>FIRST</literal> and <literal>ANY</literal> are case-insensitive. If these keywords are used as the name of a standby server, its <replaceable class="parameter">standby_name</replaceable> must be double-quoted. FIRSTANYは、大文字小文字を区別しません。 もしこれらのキーワードをスタンバイサーバの名前に使う場合は、standby_nameは二重引用符で囲わなければなりません。

The third syntax was used before <productname>PostgreSQL</productname> version 9.6 and is still supported. It's the same as the first syntax with <literal>FIRST</literal> and <replaceable class="parameter">num_sync</replaceable> equal to 1. For example, <literal>FIRST 1 (s1, s2)</literal> and <literal>s1, s2</literal> have the same meaning: either <literal>s1</literal> or <literal>s2</literal> is chosen as a synchronous standby. 3番目の構文は、PostgreSQL9.6よりも前のバージョンで用いられていたもので、依然としてサポートされています。 最初の構文で、FIRSTnum_syncを1とした時と同じです。 たとえば、FIRST 1 (s1, s2)s1, s2は同じ意味です。 s1s2が同期スタンバイとして選ばれます。

The special entry <literal>*</literal> matches any standby name. 特別なエントリ*は、すべてのスタンバイ名に一致します。

There is no mechanism to enforce uniqueness of standby names. In case of duplicates one of the matching standbys will be considered as higher priority, though exactly which one is indeterminate. スタンバイの一意性を強要する仕組みはありません。 重複があった場合、一致したスタンバイは優先順位が高いと見なされますが、どれが選ばれるかは非決定的です。

注記

Each <replaceable class="parameter">standby_name</replaceable> should have the form of a valid SQL identifier, unless it is <literal>*</literal>. You can use double-quoting if necessary. But note that <replaceable class="parameter">standby_name</replaceable>s are compared to standby application names case-insensitively, whether double-quoted or not. 各々のstandby_nameは、*である場合を除き、SQL識別子の形式を取らなければなりません。 二重引用符を用いることもできます。 しかし、二重引用符の有無に関わらず、standby_nameとスタンバイのアプリケーション名の比較は、大文字小文字の区別なしに行われることに注意してください。

If no synchronous standby names are specified here, then synchronous replication is not enabled and transaction commits will not wait for replication. This is the default configuration. Even when synchronous replication is enabled, individual transactions can be configured not to wait for replication by setting the <xref linkend="guc-synchronous-commit"/> parameter to <literal>local</literal> or <literal>off</literal>. ここに同期スタンバイ名が指定されていない場合、同期レプリケーションは有効とはならず、トランザクションコミットはレプリケーションを待機しません。これがデフォルトの設定です。同期レプリケーションが有効であっても、synchronous_commitパラメータをlocal または offに設定することにより、個別のトランザクションをレプリケーションに対して待機しないように設定できます。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

20.6.3. スタンバイサーバ #

<title>Standby Servers</title>

These settings control the behavior of a <link linkend="standby-server-operation">standby server</link> that is to receive replication data. Their values on the primary server are irrelevant. これらの設定はレプリケーションデータを受け取るスタンバイサーバの動作を管理します。 プライマリサーバ上のこれらの値は無意味です。

primary_conninfo (string) #

Specifies a connection string to be used for the standby server to connect with a sending server. This string is in the format described in <xref linkend="libpq-connstring"/>. If any option is unspecified in this string, then the corresponding environment variable (see <xref linkend="libpq-envars"/>) is checked. If the environment variable is not set either, then defaults are used. スタンバイサーバが送信サーバに接続するための接続文字列を指定します。 この文字列は、34.1.1で説明されている書式で記述されます。 この文字列に何のオプションも指定されていない場合、これに対応する環境変数 (34.15 参照) が確認されます。 環境変数も設定されていなければデフォルトの値が使われます。

The connection string should specify the host name (or address) of the sending server, as well as the port number if it is not the same as the standby server's default. Also specify a user name corresponding to a suitably-privileged role on the sending server (see <xref linkend="streaming-replication-authentication"/>). A password needs to be provided too, if the sender demands password authentication. It can be provided in the <varname>primary_conninfo</varname> string, or in a separate <filename>~/.pgpass</filename> file on the standby server (use <literal>replication</literal> as the database name). Do not specify a database name in the <varname>primary_conninfo</varname> string. 接続文字列では、プライマリサーバのホスト名(またはアドレス)、スタンバイサーバのデフォルトと異なるのであればポート番号も指定する必要があります。 また、送信サーバ上で適切な権限を保有するロールのユーザを指定しなければなりません (27.2.5.1 参照)。 送信サーバが要求するのであれば、パスワードも記述される必要があります。 パスワードは primary_conninfoに記述することもできますし、スタンバイサーバ上の分離されたファイル~/.pgpassに記述することもできます (データベース名には replication を使います)。 primary_conninfo文字列の中には、データベース名を指定しないでください。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting (except if <varname>primary_conninfo</varname> is an empty string). This setting has no effect if the server is not in standby mode. このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します(primary_conninfoが空文字の場合を除きます。) サーバがスタンバイモードでなければこの設定は無効となります。

primary_slot_name (string) #

Optionally specifies an existing replication slot to be used when connecting to the sending server via streaming replication to control resource removal on the upstream node (see <xref linkend="streaming-replication-slots"/>). This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting. This setting has no effect if <varname>primary_conninfo</varname> is not set or the server is not in standby mode. 上流ノードのリソース削除を制御するためにストリーミングレプリケーション経由でプライマリに接続した場合、既存のレプリケーションスロットを使うように、必要に応じて指定します(27.2.6を参照)。 このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します。 primary_conninfoが設定されていない場合、この設定は無効です。

hot_standby (boolean) #

Specifies whether or not you can connect and run queries during recovery, as described in <xref linkend="hot-standby"/>. The default value is <literal>on</literal>. This parameter can only be set at server start. It only has effect during archive recovery or in standby mode. 27.4に記載されている通り、リカバリの最中に接続し、そして問い合わせを実行できるか否かを設定します。デフォルト値はonです。 このパラメータはサーバ起動時のみ設定可能です。これは、アーカイブリカバリ期間、又はスタンバイモードにある場合にのみ効果をもたらします。

max_standby_archive_delay (integer) #

When hot standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in <xref linkend="hot-standby-conflict"/>. <varname>max_standby_archive_delay</varname> applies when WAL data is being read from WAL archive (and is therefore not current). If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. ホットスタンバイがアクティブな場合、このパラメータは、27.4.2で説明されているように、適用されようとしているWALエントリと競合するスタンバイクエリをキャンセルするまで待機する時間を決定します。 max_standby_archive_delayは、WALデータがWALアーカイブから読み取られるときに適用されます(したがって最新ではありません)。 この値が単位なしで指定された場合、ミリ秒単位で取得されます。 デフォルトは30秒です。 値-1を指定すると、スタンバイは競合するクエリが完了するまで永遠に待機します。 このパラメータはpostgresql.confファイル、またはサーバコマンドラインからのみ設定可能です。

Note that <varname>max_standby_archive_delay</varname> is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply any one WAL segment's data. Thus, if one query has resulted in significant delay earlier in the WAL segment, subsequent conflicting queries will have much less grace time. max_standby_archive_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。 むしろ、任意の1つのWALセグメントのデータの適用のために許される最大合計時間です。 従って、ある問い合わせによりWALセグメント内の前の部分で大幅な遅延となった場合、その後の衝突する問い合わせの猶予時間はずっと短くなります。

max_standby_streaming_delay (integer) #

When hot standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in <xref linkend="hot-standby-conflict"/>. <varname>max_standby_streaming_delay</varname> applies when WAL data is being received via streaming replication. If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. ホットスタンバイがアクティブな場合、このパラメータは、 27.4.2で説明されているように、適用されようとしているWALエントリと競合するスタンバイクエリをキャンセルするまで待機する時間を決定します。 max_standby_streaming_delayは、ストリーミングレプリケーションを介してWALデータを受信するときに適用されます。 この値が単位なしで指定された場合、ミリ秒単位で取得されます。 デフォルトは30秒です。 値-1を指定すると、スタンバイは競合するクエリが完了するまで永久に待機します。 このパラメータは、postgresql.confファイル、または、サーバのコマンドラインでのみで設定されます。

Note that <varname>max_standby_streaming_delay</varname> is not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply WAL data once it has been received from the primary server. Thus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again. max_standby_streaming_delayはキャンセル前に問い合わせが実行できる最大の時間の長さと同じでないことに注意してください。 むしろ、プライマリサーバから一度受け取られたWALデータを適用するために許される最大合計時間です。 従って、ある問い合わせが大幅な遅延を起こした場合、その後の衝突する問い合わせは、スタンバイサーバがふたたび遅れを取り戻すまでの間、猶予時間はずっと短くなります。

wal_receiver_create_temp_slot (boolean) #

Specifies whether the WAL receiver process should create a temporary replication slot on the remote instance when no permanent replication slot to use has been configured (using <xref linkend="guc-primary-slot-name"/>). The default is off. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting. 永続レプリケーションスロットが(primary_slot_nameを使って)作成されない設定になっている時に、WAL受信プロセスがリモートインスタンス上に一時レプリケーションスロットを作るかどうかを指定します。 このパラメータはpostgresql.confか、サーバのコマンドラインでのみ設定可能です。 WAL受信プロセスが実行中にこのパラメータが変更されると、そのプロセスにシグナルが送られ、新しい設定で再起動するために停止します。

wal_receiver_status_interval (integer) #

Specifies the minimum frequency for the WAL receiver process on the standby to send information about replication progress to the primary or upstream standby, where it can be seen using the <link linkend="monitoring-pg-stat-replication-view"> <structname>pg_stat_replication</structname></link> view. The standby will report the last write-ahead log location it has written, the last position it has flushed to disk, and the last position it has applied. This parameter's value is the maximum amount of time between reports. Updates are sent each time the write or flush positions change, or as often as specified by this parameter if set to a non-zero value. There are additional cases where updates are sent while ignoring this parameter; for example, when processing of the existing WAL completes or when <varname>synchronous_commit</varname> is set to <literal>remote_apply</literal>. Thus, the apply position may lag slightly behind the true position. If this value is specified without units, it is taken as seconds. The default value is 10 seconds. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. スタンバイサーバ上のWAL受信プロセスがプライマリー、または上位サーバに対してレプリケーションの進捗情報を送信する最小頻度を指定します。 送信された進捗情報はpg_stat_replicationビューにより確認することが可能です。 スタンバイサーバは書き込みがされた直近の先行書き込みログ位置、ディスクにフラッシュされた直近のログ位置、およびリカバリ適用された直近のログ位置を報告します。 このパラメータの値がそれぞれの報告間における最大の時間間隔です。 書き込み、またはフラッシュ位置が変更される毎、あるいはこのパラメータがゼロ以外なら、最低でもこのパラメータで設定された頻度で更新情報が送信されます。 他にもこのパラメータを無視して更新情報が送信される場合があります。 たとえば、既存のWALの処理が完了するか、synchronous_commitremote_applyに設定されている場合です。 従って、適用位置は真の位置よりも少し後ろにずれることがあります。 この値が単位なしで指定された場合は、秒単位であるとみなします。 デフォルトの値は10秒です。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

hot_standby_feedback (boolean) #

Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby. This parameter can be used to eliminate query cancels caused by cleanup records, but can cause database bloat on the primary for some workloads. Feedback messages will not be sent more frequently than once per <varname>wal_receiver_status_interval</varname>. The default value is <literal>off</literal>. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. ホットスタンバイがスタンバイサーバ上で現在処理を行っている問い合わせについて、プライマリーまたは上位サーバにフィードバックを送るか否かを指定します。 このパラメータはレコードの回収に起因する問い合わせの取り消しを排除するために使用することができます。 しかし、いくつかのワークロードに対してはプライマリーサーバ上でのデータベース肥大の原因となります。 フィードバックメッセージはwal_receiver_status_interval毎に、2回以上送信されません。 デフォルトの値はoffです。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

If cascaded replication is in use the feedback is passed upstream until it eventually reaches the primary. Standbys make no other use of feedback they receive other than to pass upstream. カスケードレプリケーションが使用されている場合、フィードバックは最終的にプライマリーに到達するまで上位サーバに転送されます。スタンバイは上位に転送する以外、受け取ったフィードバックを他に使用しません。

This setting does not override the behavior of <varname>old_snapshot_threshold</varname> on the primary; a snapshot on the standby which exceeds the primary's age threshold can become invalid, resulting in cancellation of transactions on the standby. This is because <varname>old_snapshot_threshold</varname> is intended to provide an absolute limit on the time which dead rows can contribute to bloat, which would otherwise be violated because of the configuration of a standby. この設定は、プライマリのold_snapshot_thresholdの挙動を上書きしません。 プライマリの年齢上限を超えたスタンバイ上のスナップショットは無効となる可能性があり、その場合スタンバイにおいてトランザクションのキャンセルを引き起こします。 これは、old_snapshot_thresholdが、無効行によってデータ溢れが起こる時刻の絶対的な制限を提供することを意図しているからです。 そうでなければ、スタンバイの設定によってこの目的は成立しなくなってしまいます。

wal_receiver_timeout (integer) #

Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 指定された時間より長い間、活動していないレプリケーション接続は停止します。 このことは受信するスタンバイサーバがプライマリノードの機能停止、またはネットワーク停止を検出するのに便利です。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルト値は60秒です。 値ゼロは時間切れメカニズムを無効にします。 このパラメータはpostgresql.confファイルまたはサーバのコマンドラインのみで設定可能です。

wal_retrieve_retry_interval (integer) #

Specifies how long the standby server should wait when WAL data is not available from any sources (streaming replication, local <filename>pg_wal</filename> or WAL archive) before trying again to retrieve WAL data. If this value is specified without units, it is taken as milliseconds. The default value is 5 seconds. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. WALデータがソース(ストリーミングレプリケーション、ローカルのpg_wal、またはWALアーカイブ)から取得できない時に、スタンバイサーバがWALデータ受信をリトライするまでにどの位の時間待つべきかを指定します。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルト値は5秒です。 このパラメータは、postgresql.confファイルで設定するか、サーバのコマンドラインでのみ指定できます。

This parameter is useful in configurations where a node in recovery needs to control the amount of time to wait for new WAL data to be available. For example, in archive recovery, it is possible to make the recovery more responsive in the detection of a new WAL file by reducing the value of this parameter. On a system with low WAL activity, increasing it reduces the amount of requests necessary to access WAL archives, something useful for example in cloud environments where the number of times an infrastructure is accessed is taken into account. このパラメータは、リカバリ対象のノードにおいて、新しいWALデータが読み込み可能になるまでの待ち時間を制御する必要のある時に有用です。 たとえば、アーカイブリカバリにおいては、このパラメータの値を小さくすることにより、新しいWALファイルを検出する際にリカバリの応答を早くすることができます。 WALの生成頻度が少ないシステムでは、この値を大きくすることにより、WALアーカイブへのアクセス頻度を減らすことができます。 これは、たとえば基盤へのアクセス回数が課金対象になるクラウド環境において、有用です。

In logical replication, this parameter also limits how often a failing replication apply worker will be respawned. ロジカルレプリケーションでは、このパラメータによって、失敗したレプリケーション適用ワーカーが再生成される頻度も制限されます。

recovery_min_apply_delay (integer) #

By default, a standby server restores WAL records from the sending server as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a specified amount of time. For example, if you set this parameter to <literal>5min</literal>, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the primary. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay. デフォルトでは、スタンバイサーバは可能な限り早くプライマリからWALレコードをリストアします。 時間遅れのデータのコピーを持つことで、データ損失エラーを修正する機会を提供するのは有用かもしれません。 このパラメータを使う事で、決まった時間だけリカバリを遅らせることができます。 例えば、パラメータに5minと指定した場合、各トランザクションについて、スタンバイのシステム時刻が、プライマリから報告されたコミット時刻より5分以上経過している場合のみ、スタンバイサーバはコミットを再生します。 単位を指定しない場合、ミリ秒として扱われます。 デフォルトは0で、遅延を与えません。

It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on primary and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on primary and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers. サーバ間のレプリケーション遅延はパラメータの値を上回る可能性があり、その場合には遅延は追加されません。 遅延は、プライマリサーバで書かれたWALのタイムスタンプと、スタンバイサーバの現在時刻を使って計算されていることに注意してください。 ネットワークの遅延やカスケーディングレプリケーション構成によるデータ転送の遅延は、実際の待ち時間を大幅に減らすかもしれません。 もし、プライマリサーバとスタンバイサーバのシステムクロックが同期されていない場合、期待値よりも早くレコードのリカバリを始めるかもしれません。 しかし、このパラメータの有用な設定値は典型的なサーバ間の時間のずれよりもずっと大きいので、それらは大きな問題ではありません。

The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied. 遅延はトランザクションコミットのWALレコードだけで発生します。 他のレコードは可能な限り早く再生されるでしょう。 対応する(トランザクション)コミットレコードが適用されるまではその効果が不可視であることがMVCCの可視ルールによって保証されているため、他のレコードが可能な限り早く再生されることは問題にはなりません。

The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting. ひとたびリカバリ中のデータベースが整合性のとれた状態になれば、スタンバイサーバが昇格またはトリガーになるまで、遅延が発生します。 その後、スタンバイサーバはそれ以上待たずにリカバリを終了します。

WAL records must be kept on the standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's <filename>pg_wal</filename> directory. WALレコードは、適用される準備が整うまでスタンバイに保持されなければなりません。 したがって、遅延が長くなるとWALファイルの蓄積量が増加し、スタンバイのpg_walディレクトリに必要なディスク容量が増加します。

This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases except crash recovery. <varname>hot_standby_feedback</varname> will be delayed by use of this feature which could lead to bloat on the primary; use both together with care. このパラメータはストリーミングレプリケーション配信で使われることを目的としていますが、パラメータが指定されていると、クラッシュリカバリを除くすべてのケースで使用されます。 この機能を使うことによってhot_standby_feedbackが遅延され、プライマリサーバの肥大化に繋がる可能性があります。両方同時に使う場合には注意して使ってください。

警告

Synchronous replication is affected by this setting when <varname>synchronous_commit</varname> is set to <literal>remote_apply</literal>; every <literal>COMMIT</literal> will need to wait to be applied. synchronous_commitremote_applyに設定されていれば、同期レプリケーションは、この設定に影響を受けます。各COMMITは適用されるのを待つことが必要です。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータは、postgresql.confファイルか、サーバのコマンドラインでのみ設定可能です。

20.6.4. サブスクライバー #

<title>Subscribers</title>

These settings control the behavior of a logical replication subscriber. Their values on the publisher are irrelevant. これらの設定項目は、論理レプリケーションのサブスクライバーの挙動を制御します。 パブリッシャーにおける設定値とは無関係です。 See 31.10 for more details.

max_replication_slots (integer) #

Specifies how many replication origins (see <xref linkend="replication-origins"/>) can be tracked simultaneously, effectively limiting how many logical replication subscriptions can be created on the server. Setting it to a lower value than the current number of tracked replication origins (reflected in <link linkend="view-pg-replication-origin-status">pg_replication_origin_status</link>) will prevent the server from starting. <literal>max_replication_slots</literal> must be set to at least the number of subscriptions that will be added to the subscriber, plus some reserve for table synchronization. サブスクライバー側ではレプリケーション原点(origin)(第50章参照)をいくつ並行して追跡できるかを指定します。 これは実質的に論理レプリケーションのサブスクリプションをサーバ上にいくつ作ることができるかを制限します。 現在追跡しているレプリケーション原点の数(pg_replication_origin_statusに反映されます)よりも小さい値を設定すると、サーバが起動しなくなります。 max_replication_slotsは、少なくともサブスクライバーに追加されるサブスクリプションの数に、テーブル同期用の予備を加えた数に設定する必要があります。 第50章

Note that this parameter also applies on a sending server, but with a different meaning. このパラメータは送信サーバにも適用されますが、意味は異なることに注意してください。

max_logical_replication_workers (integer) #

Specifies maximum number of logical replication workers. This includes leader apply workers, parallel apply workers, and table synchronization workers. 論理レプリケーションワーカーの最大数を指定します。 これには、リーダー適用ワーカー、パラレル適用ワーカーおよびテーブル同期ワーカーが含まれます。

Logical replication workers are taken from the pool defined by <varname>max_worker_processes</varname>. 論理レプリケーションワーカーは、max_worker_processesで定義されたプールから取得されます。

The default value is 4. This parameter can only be set at server start. デフォルト値は4です。 このパラメータはサーバ起動時にのみ設定可能です。

max_sync_workers_per_subscription (integer) #

Maximum number of synchronization workers per subscription. This parameter controls the amount of parallelism of the initial data copy during the subscription initialization or when new tables are added. サブスクリプションごとの同期ワーカーの最大数です。 このパラメータは、サブスクリプションの初期化中、あるいは新しいテーブルが追加されたときの初期データコピーの並列度を制御します。

Currently, there can be only one synchronization worker per table. 今のところ、一つのテーブルにつき、同期ワーカーは一つだけです。

The synchronization workers are taken from the pool defined by <varname>max_logical_replication_workers</varname>. 同期ワーカーは、max_logical_replication_workersで定義されたプールから取得されます。

The default value is 2. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. デフォルト値は2です。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。

max_parallel_apply_workers_per_subscription (integer) #

Maximum number of parallel apply workers per subscription. This parameter controls the amount of parallelism for streaming of in-progress transactions with subscription parameter <literal>streaming = parallel</literal>. サブスクリプションごとの適用並列ワーカーの最大数です。 このパラメータは、サブスクリプションパラメータのstreaming = parallelが指定されている進行中のトランザクションのストリーミングに対する並列度の数を制御します。

The parallel apply workers are taken from the pool defined by <varname>max_logical_replication_workers</varname>. 並列同期ワーカーは、max_logical_replication_workersで定義されたプールから取得されます。

The default value is 2. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. デフォルト値は2です。 このパラメータは、postgresql.confファイル、もしくはサーバコマンドラインでのみ設定可能です。