Continuous archiving can be used to create a <firstterm>high availability</firstterm> (HA) cluster configuration with one or more <firstterm>standby servers</firstterm> ready to take over operations if the primary server fails. This capability is widely referred to as <firstterm>warm standby</firstterm> or <firstterm>log shipping</firstterm>. 継続的なアーカイブ処理を使用して、プライマリサーバが失敗した場合に操作を引き継ぐ準備がなされた、1つ以上のスタンバイサーバを持つ高可用性(HA)クラスタ構成を作成することができます。 この機能はウォームスタンバイまたはログシッピングとして広く知られています。
The primary and standby server work together to provide this capability, though the servers are only loosely coupled. The primary server operates in continuous archiving mode, while each standby server operates in continuous recovery mode, reading the WAL files from the primary. No changes to the database tables are required to enable this capability, so it offers low administration overhead compared to some other replication solutions. This configuration also has relatively low performance impact on the primary server. プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼働しますが、サーバとサーバはゆるく結合しています。 プライマリサーバは継続的アーカイブモードで動作し、各スタンバイサーバはプライマリからWALファイルを読み取る、継続的リカバリモードで動作します。 この機能を可能にするために、データベースのテーブル変更は不要です。 したがって、他のレプリケーションの解法に比べて、管理にかかるオーバーヘッドが減少します。 この構成はプライマリサーバの性能への影響も相対的に減少させます。
Directly moving WAL records from one database server to another is typically described as log shipping. <productname>PostgreSQL</productname> implements file-based log shipping by transferring WAL records one file (WAL segment) at a time. WAL files (16MB) can be shipped easily and cheaply over any distance, whether it be to an adjacent system, another system at the same site, or another system on the far side of the globe. The bandwidth required for this technique varies according to the transaction rate of the primary server. Record-based log shipping is more granular and streams WAL changes incrementally over a network connection (see <xref linkend="streaming-replication"/>). あるデータベースサーバから他へ直接WALレコードを移動することは通常、ログシッピングと説明されます。 PostgreSQLはファイルベースのログシッピングを実装します。 つまりWALレコードはある時点で1つのファイル(WALセグメント)として送信されることを意味します。 WALファイル(16MB)は隣り合うシステム、同じサイトの別システム、地球の裏側のシステムなど距離に関わらず、簡単かつ安価に送付することができます。 この技法に必要な帯域幅はプライマリサーバのトランザクションの頻度に応じて変動します。 レコードベースのログシッピングはより粒度を細かくしたもので、ネットワーク接続を介してWALの変更を増分的に流します（26.2.5参照）。
It should be noted that log shipping is asynchronous, i.e., the WAL
records are shipped after transaction commit. As a result, there is a
window for data loss should the primary server suffer a catastrophic
failure; transactions not yet shipped will be lost. The size of the
data loss window in file-based log shipping can be limited by use of the
<varname>archive_timeout</varname> parameter, which can be set as low
as a few seconds. However such a low setting will
substantially increase the bandwidth required for file shipping.
Streaming replication (see <xref linkend="streaming-replication"/>)
allows a much smaller window of data loss.
ログシッピングが非同期であることに注意しなければなりません。
つまり、WALレコードはトランザクションがコミットした後に転送されます。
結果として、プライマリサーバが災害などの致命的な失敗をうけた場合、送信されていないトランザクションが失われますので、データを損失する空白期間があります。
ファイルベースのログシッピングにおけるデータ損失の空白期間量をarchive_timeoutパラメータを用いて制限することができます。
これは数秒程度まで小さく設定することができます。
しかし、低く設定するとファイル転送に必要な帯域幅が増大します。
ストリーミングレプリケーション（26.2.5参照）により、データを損失する期間を非常に小さくすることができます。
Recovery performance is sufficiently good that the standby will typically be only moments away from full availability once it has been activated. As a result, this is called a warm standby configuration which offers high availability. Restoring a server from an archived base backup and rollforward will take considerably longer, so that technique only offers a solution for disaster recovery, not high availability. A standby server can also be used for read-only queries, in which case it is called a <firstterm>hot standby</firstterm> server. See <xref linkend="hot-standby"/> for more information. リカバリ処理の性能は十分よく、一度実施されれば、スタンバイサーバが完全な状態から逸脱するのは一時的にしかすぎません。 結果としてこれは、高可用性を提供するウォームスタンバイ構成と呼ばれます。 保管されたベースバックアップからサーバをリストアし、ロールフォワードを行うことはおそらく長時間かかりますので、これは高可用性のための解法とはいえず、災害からのリカバリのための解法です。 スタンバイサーバは読み取り専用の問い合わせに使用することもできます。 この場合ホットスタンバイサーバと呼ばれます。 詳細については26.4を参照してください。
It is usually wise to create the primary and standby servers so that they are as similar as possible, at least from the perspective of the database server. In particular, the path names associated with tablespaces will be passed across unmodified, so both primary and standby servers must have the same mount paths for tablespaces if that feature is used. Keep in mind that if <xref linkend="sql-createtablespace"/> is executed on the primary, any new mount point needed for it must be created on the primary and all standby servers before the command is executed. Hardware need not be exactly the same, but experience shows that maintaining two identical systems is easier than maintaining two dissimilar ones over the lifetime of the application and system. In any case the hardware architecture must be the same — shipping from, say, a 32-bit to a 64-bit system will not work. プライマリサーバとスタンバイサーバを、少なくともデータベースサーバという見地でできる限り同じになるように作成することを通常勧めます。 具体的には、テーブル空間に関連するパス名はそのまま渡されますので、テーブル空間機能を使用する場合には、プライマリとスタンバイサーバの両方でテーブル空間用のマウントパスを同じにしておかなければなりません。 CREATE TABLESPACEをプライマリで実行する場合、そのコマンドを実行する前に必要な新しいマウントポイントをプライマリとすべてのスタンバイサーバで作成しなければならないことに注意してください。 ハードウェアをまったく同じにする必要はありませんが、経験上アプリケーションとシステムの運用期間に渡って2つの同じシステムを管理する方が、異なる2つのシステムを管理するよりも簡単です。 いずれにしてもハードウェアアーキテクチャは必ず同じでなければなりません。 例えば32ビットシステムから64ビットシステムへのシッピングは動作しません。
In general, log shipping between servers running different major <productname>PostgreSQL</productname> release levels is not possible. It is the policy of the PostgreSQL Global Development Group not to make changes to disk formats during minor release upgrades, so it is likely that running different minor release levels on primary and standby servers will work successfully. However, no formal support for that is offered and you are advised to keep primary and standby servers at the same release level as much as possible. When updating to a new minor release, the safest policy is to update the standby servers first — a new minor release is more likely to be able to read WAL files from a previous minor release than vice versa. 一般的に、異なるメジャーリリースレベルのPostgreSQL間でログシッピングはできません。 マイナーリリースの更新ではディスク書式を変更しないというのがPostgreSQLグローバル開発グループの方針ですので、プライマリサーバとスタンバイサーバとの間でマイナーリリースレベルの違いがあってもうまく動作するはずです。 しかし、この場合、公的なサポートは提供されません。 できる限りプライマリサーバとスタンバイサーバとで同じリリースレベルを使用してください。 新しいマイナーリリースに更新する場合、もっとも安全な方針はスタンバイサーバを先に更新することです。 新しいマイナーリリースは以前のマイナーリリースのWALファイルを読み込むことはできますが、逆はできないかもしれません。
A server enters standby mode if a
<anchor id="file-standby-signal" xreflabel="standby.signal"/>
<filename>standby.signal</filename>
<indexterm><primary><filename>standby.signal</filename></primary></indexterm>
file exists in the data directory when the server is started.
サーバが起動した時にデータディレクトリにstandby.signalが存在すると、サーバはスタンバイモードに入ります。
In standby mode, the server continuously applies WAL received from the
primary server. The standby server can read WAL from a WAL archive
(see <xref linkend="guc-restore-command"/>) or directly from the primary
over a TCP connection (streaming replication). The standby server will
also attempt to restore any WAL found in the standby cluster's
<filename>pg_wal</filename> directory. That typically happens after a server
restart, when the standby replays again WAL that was streamed from the
primary before the restart, but you can also manually copy files to
<filename>pg_wal</filename> at any time to have them replayed.
スタンバイモードでは、サーバは継続的にプライマリサーバから受け取ったWALを適用します。
スタンバイサーバはWALアーカイブ(restore_command参照)から、または直接TCP接続(ストリーミングレプリケーション)を介してプライマリサーバから、WALを読み取ることができます。
またスタンバイサーバはスタンバイクラスタのpg_walディレクトリにあるすべてのWALをリストアしようと試みます。
これはよくサーバの再起動後、スタンバイが再起動前にプライマリから流れ込んだWALを再生する時に発生します。
しかしまたファイルを再生する任意の時点で、手作業でpg_walにコピーすることもできます。
At startup, the standby begins by restoring all WAL available in the
archive location, calling <varname>restore_command</varname>. Once it
reaches the end of WAL available there and <varname>restore_command</varname>
fails, it tries to restore any WAL available in the <filename>pg_wal</filename> directory.
If that fails, and streaming replication has been configured, the
standby tries to connect to the primary server and start streaming WAL
from the last valid record found in archive or <filename>pg_wal</filename>. If that fails
or streaming replication is not configured, or if the connection is
later disconnected, the standby goes back to step 1 and tries to
restore the file from the archive again. This loop of retries from the
archive, <filename>pg_wal</filename>, and via streaming replication goes on until the server
is stopped or is promoted.
起動時、スタンバイサーバはrestore_commandを呼び出して、アーカイブ場所にある利用可能なすべてのWALをリストアすることから始めます。
そこで利用可能なWALの終端に達し、restore_commandが失敗すると、pg_walディレクトリにある利用可能な任意のWALのリストアを試みます。
ストリーミングレプリケーションが設定されている場合、これに失敗すると、スタンバイはプライマリサーバへの接続を試み、アーカイブまたはpg_wal内に存在した最終の有効レコードからWALのストリーミングを開始します。
ストリーミングレプリケーションが未設定時にこれに失敗する場合、または、接続が後で切断される場合、スタンバイは最初に戻り、アーカイブからのファイルのリストアを繰り返し行います。
このアーカイブ、pg_wal、ストリーミングレプリケーションからという再試行の繰り返しはサーバが停止する、あるいは昇格するまで続きます。
Standby mode is exited and the server switches to normal operation
when <command>pg_ctl promote</command> is run, or
<function>pg_promote()</function> is called. Before failover,
any WAL immediately available in the archive or in <filename>pg_wal</filename>
will be restored, but no attempt is made to connect to the primary.
スタンバイモードは、pg_ctl promoteが実行されたとき、またはpg_promote()が呼び出されたときに終了し、サーバは通常の動作に切り替わります。
フェイルオーバーの前に、アーカイブまたはpg_wal内で直ちに使用可能なWALはすべてリストアされますが、プライマリへの接続は試みられません。
Set up continuous archiving on the primary to an archive directory accessible from the standby, as described in <xref linkend="continuous-archiving"/>. The archive location should be accessible from the standby even when the primary is down, i.e., it should reside on the standby server itself or another trusted server, not on the primary server. 25.3で説明したように、スタンバイからアクセス可能なアーカイブディレクトリに対してプライマリで継続的なアーカイブを設定してください。 このアーカイブ場所はプライマリが停止した時であってもスタンバイからアクセス可能でなければなりません。 つまり、プライマリサーバ上ではなく、スタンバイサーバ自身上に存在するか、または他の高信頼性サーバ上に存在しなければなりません。
If you want to use streaming replication, set up authentication on the
primary server to allow replication connections from the standby
server(s); that is, create a role and provide a suitable entry or
entries in <filename>pg_hba.conf</filename> with the database field set to
<literal>replication</literal>. Also ensure <varname>max_wal_senders</varname> is set
to a sufficiently large value in the configuration file of the primary
server. If replication slots will be used,
ensure that <varname>max_replication_slots</varname> is set sufficiently
high as well.
ストリーミングレプリケーションを使用したい場合、スタンバイサーバ(複数可)からのレプリケーション接続を受け付けるようにプライマリサーバで認証を設定してください。
つまり、ロールを作成し適切な項目を提供、あるいは、そのデータベースフィールドとしてreplicationを持つ項目をpg_hba.conf内に設定してください。
また、プライマリサーバの設定ファイルにおいてmax_wal_sendersが十分大きな値に設定されていることを確認してください。
レプリケーションスロットを使用している場合は、max_replication_slotsも十分に設定されているか確認してください。
Take a base backup as described in <xref linkend="backup-base-backup"/> to bootstrap the standby server. 25.3.2に記述したように、スタンバイサーバの再起動のために、ベースバックアップを取得してください。
To set up the standby server, restore the base backup taken from primary
server (see <xref linkend="backup-pitr-recovery"/>). Create a file
<link linkend="file-standby-signal"><filename>standby.signal</filename></link><indexterm><primary>standby.signal</primary></indexterm>
in the standby's cluster data
directory. Set <xref linkend="guc-restore-command"/> to a simple command to copy files from
the WAL archive. If you plan to have multiple standby servers for high
availability purposes, make sure that <varname>recovery_target_timeline</varname> is set to
<literal>latest</literal> (the default), to make the standby server follow the timeline change
that occurs at failover to another standby.
スタンバイサーバを設定するためには、プライマリサーバから取得したベースバックアップをリストアしてください(25.3.5参照)。
スタンバイのクラスタデータディレクトリ内にstandby.signalファイルを作成してください。
WALアーカイブからファイルをコピーする簡単なコマンドをrestore_commandに設定してください。
高可用性のために複数のスタンバイサーバを持たせようとしている場合、recovery_target_timelineをlatestに設定し（デフォルト）、スタンバイサーバが他のスタンバイにフェイルオーバーする時に発生するタイムラインの変更に従うようにします。
<xref linkend="guc-restore-command"/> should return immediately if the file does not exist; the server will retry the command again if necessary. そのファイルが存在しなければrestore_commandは直ちに終了すべきです。サーバは必要ならばそのコマンドをリトライします。
If you want to use streaming replication, fill in <xref linkend="guc-primary-conninfo"/> with a libpq connection string, including the host name (or IP address) and any additional details needed to connect to the primary server. If the primary needs a password for authentication, the password needs to be specified in <xref linkend="guc-primary-conninfo"/> as well. ストリーミングレプリケーションを使用したい場合には、ホスト名(またはIPアドレス)とプライマリサーバとの接続に必要な追加情報を含む、libpq接続文字列でprimary_conninfoを記述してください。 プライマリで認証用のパスワードが必要な場合はprimary_conninfoにそのパスワードも指定する必要があります。
If you're setting up the standby server for high availability purposes, set up WAL archiving, connections and authentication like the primary server, because the standby server will work as a primary server after failover. スタンバイサーバを高可用性を目的に設定しているのであれば、スタンバイサーバはフェイルオーバーの後プライマリサーバとして動作しますので、プライマリサーバと同様にWALアーカイブ処理、接続、認証を設定してください。
If you're using a WAL archive, its size can be minimized using the <xref
linkend="guc-archive-cleanup-command"/> parameter to remove files that are no
longer required by the standby server.
The <application>pg_archivecleanup</application> utility is designed specifically to
be used with <varname>archive_cleanup_command</varname> in typical single-standby
configurations, see <xref linkend="pgarchivecleanup"/>.
Note however, that if you're using the archive for backup purposes, you
need to retain files needed to recover from at least the latest base
backup, even if they're no longer needed by the standby.
WALアーカイブを使用している場合、archive_cleanup_commandパラメータを使用してスタンバイサーバで不要となったファイルを削除することで、その容量を最小化することができます。
特にpg_archivecleanupユーティリティは、典型的な単一スタンバイ構成（pg_archivecleanup参照）におけるarchive_cleanup_commandと共に使用されるように設計されています。
しかし、バックアップを目的にアーカイブを使用している場合には、スタンバイから必要とされなくなったファイルであっても、最新のベースバックアップの時点からリカバリするために必要なファイルを保持しなければならないことに注意してください。
A simple example of configuration is: 簡単な設定例を以下に示します。
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000''' restore_command = 'cp /path/to/archive/%f %p' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
You can have any number of standby servers, but if you use streaming
replication, make sure you set <varname>max_wal_senders</varname> high enough in
the primary to allow them to be connected simultaneously.
スタンバイサーバの台数に制限はありませんが、ストリーミングレプリケーションを使用するなら、プライマリサーバに同時に接続できるようにmax_wal_sendersを十分な数に設定してください。
Streaming replication allows a standby server to stay more up-to-date than is possible with file-based log shipping. The standby connects to the primary, which streams WAL records to the standby as they're generated, without waiting for the WAL file to be filled. ストリーミングレプリケーションによりスタンバイサーバはファイルベースのログシッピングよりもより最近の状態を維持できるようになります。 スタンバイは、WALレコードが生成された時にWALファイルがいっぱいになるまで待機せずにWALレコードをスタンバイに流し出すプライマリと接続します。
Streaming replication is asynchronous by default
(see <xref linkend="synchronous-replication"/>), in which case there is
a small delay between committing a transaction in the primary and the
changes becoming visible in the standby. This delay is however much
smaller than with file-based log shipping, typically under one second
assuming the standby is powerful enough to keep up with the load. With
streaming replication, <varname>archive_timeout</varname> is not required to
reduce the data loss window.
ストリーミングレプリケーションはデフォルトで非同期で、(26.2.8参照)
この場合、プライマリでトランザクションがコミットされてから、その変更がスタンバイ側で参照可能になるまでの間にわずかな遅延がまだあります。
しかし、この遅延はファイルベースのログシッピングよりも非常に小さなもので、負荷に追随できる程度の能力があるスタンバイであれば通常は1秒以下です。
ストリーミングレプリケーションでは、データ損失期間を減らすためのarchive_timeoutを必要としません。
If you use streaming replication without file-based continuous
archiving, the server might recycle old WAL segments before the standby
has received them. If this occurs, the standby will need to be
reinitialized from a new base backup. You can avoid this by setting
<varname>wal_keep_size</varname> to a value large enough to ensure that
WAL segments are not recycled too early, or by configuring a replication
slot for the standby. If you set up a WAL archive that's accessible from
the standby, these solutions are not required, since the standby can
always use the archive to catch up provided it retains enough segments.
ファイルベースの継続的アーカイブのないストリーミングレプリケーションを使用している場合、スタンバイが受け取る前に古いWALセグメントを再利用するかもしれません。
もし、そうなった場合はスタンバイは新しいベースバックアップから再作成しなければならなくなります。
wal_keep_sizeを十分に大きくしたり、レプリケーションスロットにスタンバイを設定することでWALセグメントがすぐに再利用されることを防ぎ、これを防ぐことができます。WALアーカイブをスタンバイからアクセスできる位置に設定する場合は、スタンバイが常にWALセグメントを追随することができるため、これらの解決策は要求されません。
To use streaming replication, set up a file-based log-shipping standby
server as described in <xref linkend="warm-standby"/>. The step that
turns a file-based log-shipping standby into streaming replication
standby is setting the <varname>primary_conninfo</varname> setting
to point to the primary server. Set
<xref linkend="guc-listen-addresses"/> and authentication options
(see <filename>pg_hba.conf</filename>) on the primary so that the standby server
can connect to the <literal>replication</literal> pseudo-database on the primary
server (see <xref linkend="streaming-replication-authentication"/>).
ストリーミングレプリケーションを使用するためには、26.2の説明のようにファイルベースのログシッピングを行うスタンバイサーバを設定してください。
ファイルベースのログシッピングを行うスタンバイをストリーミングレプリケーションを行うスタンバイに切り替える手順は、primary_conninfo設定をプライマリサーバを指し示すように設定することです。
スタンバイサーバがプライマリサーバ上のreplication疑似データベースに接続できる(26.2.5.1参照)ように、プライマリでlisten_addressesと認証オプション(pg_hba.conf参照)を設定してください。
On systems that support the keepalive socket option, setting <xref linkend="guc-tcp-keepalives-idle"/>, <xref linkend="guc-tcp-keepalives-interval"/> and <xref linkend="guc-tcp-keepalives-count"/> helps the primary promptly notice a broken connection. キープアライブソケットオプションをサポートするシステムでは、tcp_keepalives_idle、tcp_keepalives_intervalおよびtcp_keepalives_countを設定することで、プライマリの接続切断の即時検知に有用です。
Set the maximum number of concurrent connections from the standby servers (see <xref linkend="guc-max-wal-senders"/> for details). スタンバイサーバからの同時接続数の最大値を設定してください（詳細はmax_wal_sendersを参照）。
When the standby is started and <varname>primary_conninfo</varname> is set
correctly, the standby will connect to the primary after replaying all
WAL files available in the archive. If the connection is established
successfully, you will see a <literal>walreceiver</literal> in the standby, and
a corresponding <literal>walsender</literal> process in the primary.
スタンバイが起動し、primary_conninfoが正しく設定されると、スタンバイはアーカイブ内で利用可能なWALファイルをすべて再生した後にプライマリと接続します。
接続の確立に成功すると、スタンバイでwalreceiverが存在し、プライマリで対応するwalsenderが存在します。
It is very important that the access privileges for replication be set up
so that only trusted users can read the WAL stream, because it is
easy to extract privileged information from it. Standby servers must
authenticate to the primary as an account that has the
<literal>REPLICATION</literal> privilege or a superuser. It is
recommended to create a dedicated user account with
<literal>REPLICATION</literal> and <literal>LOGIN</literal>
privileges for replication. While <literal>REPLICATION</literal>
privilege gives very high permissions, it does not allow the user to
modify any data on the primary system, which the
<literal>SUPERUSER</literal> privilege does.
信頼できるユーザのみがWALストリームを読み取ることができるように、レプリケーション用のアクセス権限を設定することは非常に重要です。
WALから機密情報を取り出すことは簡単だからです。
スタンバイサーバはプライマリに対してプライマリのREPLICATION権限を持つアカウントか、スーパーユーザとして認証されなければなりません。
レプリケーションのためのREPLICATION権限 と LOGIN権限を持つ専用のユーザを作成することをお勧めします。
REPLICATION権限は非常に強力な権限なので、SUPERUSERのようにプライマリのデータを変更することを許可されていません。
Client authentication for replication is controlled by a
<filename>pg_hba.conf</filename> record specifying <literal>replication</literal> in the
<replaceable>database</replaceable> field. For example, if the standby is running on
host IP <literal>192.168.1.100</literal> and the account name for replication
is <literal>foo</literal>, the administrator can add the following line to the
<filename>pg_hba.conf</filename> file on the primary:
レプリケーション用のクライアント認証はpg_hba.conf内でそのdatabaseフィールドにreplicationを指定したレコードで制御されます。
例えば、スタンバイがIPアドレス192.168.1.100のホストで稼働し、レプリケーション用のアカウントの名前がfooである場合、管理者はプライマリ上のpg_hba.confに以下の行を追加することができます。
# Allow the user "foo" from host 192.168.1.100 to connect to the primary
# as a replication standby if the user's password is correctly supplied.
# 利用者 foo のホスト 192.168.1.100 からプライマリサーバへのレプリケーションスタンバイとしての接続を
# 利用者のパスワードが正しく入力されたならば許可する
#
# TYPE DATABASE USER ADDRESS METHOD
host replication foo 192.168.1.100/32 md5
The host name and port number of the primary, connection user name,
and password are specified in the <xref linkend="guc-primary-conninfo"/>.
The password can also be set in the <filename>~/.pgpass</filename> file on the
standby (specify <literal>replication</literal> in the <replaceable>database</replaceable>
field).
For example, if the primary is running on host IP <literal>192.168.1.50</literal>,
port <literal>5432</literal>, the account name for replication is
<literal>foo</literal>, and the password is <literal>foopass</literal>, the administrator
can add the following line to the <filename>postgresql.conf</filename> file on the
standby:
プライマリサーバのホスト名とポート番号、接続する利用者名およびパスワードは、primary_conninfoで指定します。
パスワードはスタンバイサーバの~/.pgpassファイルでも設定できます（databaseフィールドのreplicationを指定します）。
例えば、プライマリサーバが稼働するホストの IP アドレスが192.168.1.50でポート番号が5432であり、レプリケーションのアカウント名がfooであり、パスワードがfoopassである場合、管理者はスタンバイサーバのpostgresql.confファイルに次行を追加できます。
# The standby connects to the primary that is running on host 192.168.1.50
# and port 5432 as the user "foo" whose password is "foopass".
# プライマリサーバが 192.168.1.50 のホストの 5432ポートで稼働し
# 利用者名が foo でパスワードが foopass とする
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
An important health indicator of streaming replication is the amount
of WAL records generated in the primary, but not yet applied in the
standby. You can calculate this lag by comparing the current WAL write
location on the primary with the last WAL location received by the
standby. These locations can be retrieved using
<function>pg_current_wal_lsn</function> on the primary and
<function>pg_last_wal_receive_lsn</function> on the standby,
respectively (see <xref linkend="functions-admin-backup-table"/> and
<xref linkend="functions-recovery-info-table"/> for details).
The last WAL receive location in the standby is also displayed in the
process status of the WAL receiver process, displayed using the
<command>ps</command> command (see <xref linkend="monitoring-ps"/> for details).
ストリーミングレプリケーションの重要な健全性尺度は、プライマリサーバで生成されたがスタンバイサーバではまだ適用されていないWALレコードの量です。
プライマリサーバの現在のWAL書き込み位置とスタンバイサーバの受理したWALの最終位置を比較すれば、この遅延を計算できます。
これらの位置は、プライマリサーバではpg_current_wal_lsnを、スタンバイサーバではpg_last_wal_receive_lsnを使用すれば検索できます（詳細は表 9.95および表 9.96を参照）。
スタンバイサーバの最終位置は、psコマンドを使用して WAL受信プロセスの状態としても表示できます（詳細は27.1を参照）。
You can retrieve a list of WAL sender processes via the
<link linkend="monitoring-pg-stat-replication-view"><structname>
pg_stat_replication</structname></link> view. Large differences between
<function>pg_current_wal_lsn</function> and the view's <literal>sent_lsn</literal> field
might indicate that the primary server is under heavy load, while
differences between <literal>sent_lsn</literal> and
<function>pg_last_wal_receive_lsn</function> on the standby might indicate
network delay, or that the standby is under heavy load.
pg_stat_replicationビューを介してWAL送信処理プロセスのリストを入手することができます。
pg_current_wal_lsnとビューのsent_lsnフィールドとの違いが大きい場合、プライマリサーバが高負荷状態であることを示している可能性があります。
一方でスタンバイサーバ上のsent_lsnとpg_last_wal_receive_lsnの値の差異は、ネットワーク遅延、またはスタンバイが高負荷状態であることを示す可能性があります。
On a hot standby, the status of the WAL receiver process can be retrieved
via the <link linkend="monitoring-pg-stat-wal-receiver-view">
<structname>pg_stat_wal_receiver</structname></link> view. A large
difference between <function>pg_last_wal_replay_lsn</function> and the
view's <literal>flushed_lsn</literal> indicates that WAL is being
received faster than it can be replayed.
ホットスタンバイ上では、WAL受信プロセスの状態は、pg_stat_wal_receiverビューを通じて入手することができます。
pg_last_wal_replay_lsnとビューのflushed_lsnとの違いが大きい場合、WALのリプレイを上回る速さでWALが受信されていることを示しています。
Replication slots provide an automated way to ensure that the primary server does not remove WAL segments until they have been received by all standbys, and that the primary does not remove rows which could cause a <link linkend="hot-standby-conflict">recovery conflict</link> even when the standby is disconnected. 《マッチ度[91.746032]》レプリケーションスロットは、以下のことを保証する自動的な方法を提供します。 全てのスタンバイがWALセグメントを受け取るまでは、プライマリがWALセグメントを削除しないこと、また、スタンバイが接続していない際にも、リカバリの競合が発生する可能性がある行をプライマリが削除しないこと、です。
In lieu of using replication slots, it is possible to prevent the removal of old WAL segments using <xref linkend="guc-wal-keep-size"/>, or by storing the segments in an archive using <xref linkend="guc-archive-command"/> or <xref linkend="guc-archive-library"/>. A disadvantage of these methods is that they often result in retaining more WAL segments than required, whereas replication slots retain only the number of segments known to be needed. 《機械翻訳》レプリケーションスロットを使用する代わりに、wal_keep_sizeを使用したり、archive_commandやarchive_libraryを使用してアーカイブにセグメントを保存したりすることで、古いWALセグメントの削除を防ぐことができます。 これらの方法の欠点は、レプリケーションスロットが必要とされる数のセグメントしか保持しないのに対して、必要以上のWALセグメントを保持することが多いことです。
Similarly, <xref linkend="guc-hot-standby-feedback"/> on its own, without also using a replication slot, provides protection against relevant rows being removed by vacuum, but provides no protection during any time period when the standby is not connected. 《マッチ度[73.046875]》同様に、hot_standby_feedbackは、レプリケーションスロットを使用しない場合、関連する行がバキュームによって削除されることに対して保護しますが、スタンバイが接続されていない間は保護しません。 レプリケーションスロットはこれらの欠点を克服します。 《機械翻訳》同様に、レプリケーションスロットを使用しないhot_standby_feedback自体は、関連する行がバキュームによって除去されることに対する保護を提供するが、ピリオドが接続されていないときは、スタンバイ中に保護を提供しない。
Beware that replication slots can cause the server to retain so
many WAL segments that they fill up the space allocated for
<literal>pg_wal</literal>.
<xref linkend="guc-max-slot-wal-keep-size"/> can be used to limit the size
of WAL files retained by replication slots.
《機械翻訳》レプリケーションスロットは、サーバが非常に多くのWALセグメントを保持し、pg_walに割り当てられたスペースを一杯にしてしまう可能性があることに注意してください。
max_slot_wal_keep_sizeは、レプリケーションスロットが保持するWALファイルのサイズを制限するために使用できます。
Each replication slot has a name, which can contain lower-case letters, numbers, and the underscore character. いずれのレプリケーションスロットにも小文字、数字、アンダースコアを含む名前があります。
Existing replication slots and their state can be seen in the
<link linkend="view-pg-replication-slots"><structname>pg_replication_slots</structname></link>
view.
レプリケーションスロットとその状態はpg_replication_slots
ビューより確認できます。
Slots can be created and dropped either via the streaming replication protocol (see <xref linkend="protocol-replication"/>) or via SQL functions (see <xref linkend="functions-replication"/>). レプリケーションスロットはストリーミングレプリケーションプロトコル( 53.4参照)もしくはSQL関数(9.28.6参照)を使用し、作成や削除ができます。
You can create a replication slot like this: 以下のような方法でレプリケーションスロットを作成できます。
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
slot_name | lsn
-------------+-----
node_a_slot |
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-------------+-----------+--------
node_a_slot | physical | f
(1 row)
To configure the standby to use this slot, <varname>primary_slot_name</varname>
should be configured on the standby. Here is a simple example:
スタンバイのレプリケーションスロットを使用できるように設定するためには、primary_slot_nameをスタンバイ側で設定します。
以下は単純な設定例です。：
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' primary_slot_name = 'node_a_slot'
The cascading replication feature allows a standby server to accept replication connections and stream WAL records to other standbys, acting as a relay. This can be used to reduce the number of direct connections to the primary and also to minimize inter-site bandwidth overheads. カスケードレプリケーションは、リレーのような振る舞い、つまり、スタンバイサーバから他のスタンバイにレプリケーション接続し、WALレコードを送信することができます。 プライマリサーバへ直接の接続を減らしたり、サイト相互の帯域オーバーヘッドを最小化するために使用することができます。
A standby acting as both a receiver and a sender is known as a cascading standby. Standbys that are more directly connected to the primary are known as upstream servers, while those standby servers further away are downstream servers. Cascading replication does not place limits on the number or arrangement of downstream servers, though each standby connects to only one upstream server which eventually links to a single primary server. カスケードスタンバイとして知られているとおり、スタンバイは受け取り手としても送り手としても振る舞うことができます。 よりプライマリサーバに近いスタンバイサーバは上流サーバと呼ばれるのに対し、より遠いスタンバイサーバは下流サーバと呼ばれます。 カスケードレプリケーションには下流サーバの数に制限は設定されていません。しかし、どのスタンバイサーバも最終的には1つのプライマリサーバに繋がる1つの上流サーバに接続します。
A cascading standby sends not only WAL records received from the primary but also those restored from the archive. So even if the replication connection in some upstream connection is terminated, streaming replication continues downstream for as long as new WAL records are available. カスケードスタンバイはプライマリから受け取ったWALレコードだけでなく、アーカイブからリストアしたWALレコードも送信します。 このため、レプリケーション接続が上流サーバで切断しても、ストリーミングレプリケーションは下流サーバへ新しいWAL レコードがある限り継続します。
Cascading replication is currently asynchronous. Synchronous replication (see <xref linkend="synchronous-replication"/>) settings have no effect on cascading replication at present. カスケードレプリケーションは現時点では非同期です。同期レプリケーション（参照26.2.8）の設定は現時点でカスケードレプリケーションへは影響を与えません。
Hot standby feedback propagates upstream, whatever the cascaded arrangement. ホットスタンバイがどの様にカスケード配置されていても、ホットスタンバイフィードバックは上流に伝播します。
If an upstream standby server is promoted to become the new primary, downstream
servers will continue to stream from the new primary if
<varname>recovery_target_timeline</varname> is set to <literal>'latest'</literal> (the default).
上流スタンバイサーバが昇格し、新しいプライマリサーバになった場合、recovery_target_timelineが'latest'に設定されていれば、下流サーバは新プライマリからのストリーミングレプリケーションを継続します（デフォルトです）。
To use cascading replication, set up the cascading standby so that it can
accept replication connections (that is, set
<xref linkend="guc-max-wal-senders"/> and <xref linkend="guc-hot-standby"/>,
and configure
<link linkend="auth-pg-hba-conf">host-based authentication</link>).
You will also need to set <varname>primary_conninfo</varname> in the downstream
standby to point to the cascading standby.
カスケードレプリケーションを使うためには、カスケードスタンバイをセットアップ、つまり、レプリケーション接続を許可してください。(max_wal_sendersとhot_standbyおよび、 クライアント認証を設定してください)
また、下流スタンバイがカスケードスタンバイに接続できるために、下流スタンバイではprimary_conninfoを設定する必要があります。
<productname>PostgreSQL</productname> streaming replication is asynchronous by default. If the primary server crashes then some transactions that were committed may not have been replicated to the standby server, causing data loss. The amount of data loss is proportional to the replication delay at the time of failover. PostgreSQLのストリーミングレプリケーションはデフォルトで非同期です。 プライマリサーバがクラッシュした場合、コミットされた一部のトランザクションがスタンバイサーバに複製されず、データ損失を引き起こす可能性があります。 データ損失量はフェイルオーバー時点のレプリケーション遅延に比例します。
Synchronous replication offers the ability to confirm that all changes
made by a transaction have been transferred to one or more synchronous
standby servers. This extends that standard level of durability
offered by a transaction commit. This level of protection is referred
to as 2-safe replication in computer science theory, and group-1-safe
(group-safe and 1-safe) when <varname>synchronous_commit</varname> is set to
<literal>remote_write</literal>.
同期レプリケーションは、あるトランザクションでなされた変更はすべて、１つ以上の同期スタンバイサーバに転送されていることを確実にする機能を提供します。
これはトランザクションコミットで提供される永続性の標準レベルを拡張します。
この保護レベルはコンピュータ科学理論では、2-safeレプリケーション、そしてsynchronous_commitがremote_writeに設定されている場合にはgroup-1-safe (group-safeと1-safe) と呼ばれます。
When requesting synchronous replication, each commit of a write transaction will wait until confirmation is received that the commit has been written to the write-ahead log on disk of both the primary and standby server. The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. This can provide a much higher level of durability, though only if the sysadmin is cautious about the placement and management of the two servers. Waiting for confirmation increases the user's confidence that the changes will not be lost in the event of server crashes but it also necessarily increases the response time for the requesting transaction. The minimum wait time is the round-trip time between primary and standby. 同期レプリケーションを要求する時、書き込みトランザクションのコミットはそれぞれ、そのコミットがプライマリサーバおよびスタンバイサーバの両方で、ディスク上の書き込み先行ログに書き込まれたという確認を受けとるまで待機します。 データ損失が起こる可能性は、プライマリサーバとスタンバイサーバが同時にクラッシュしてしまった場合のみです。 これは非常に高い永続性を提供することができますが、それはシステム管理者が２つのサーバの設置と管理に関して注意を払っている場合のみです。 確認のための待機は、サーバがクラッシュした場合でも変更が失われないということでユーザからの信頼性が大きくなりますが、同時に要求するトランザクションの応答時間も必ず大きくなります。 最小待機時間はプライマリとスタンバイの間の往復遅延時間です。
Read-only transactions and transaction rollbacks need not wait for replies from standby servers. Subtransaction commits do not wait for responses from standby servers, only top-level commits. Long running actions such as data loading or index building do not wait until the very final commit message. All two-phase commit actions require commit waits, including both prepare and commit. 読み取り専用のトランザクションおよびトランザクションのロールバックはスタンバイサーバからの応答を待つ必要はありません。 副トランザクションのコミットもスタンバイサーバからの応答を待つことはなく、最上位レベルのコミットのみ待機します。 データロード処理やインデックス構築など長時間実行される操作は、最終コミットメッセージまで待機しません。 準備およびコミットの両方を含め、二相コミット動作はすべてコミット待機を必要とします。
A synchronous standby can be a physical replication standby or a logical
replication subscriber. It can also be any other physical or logical WAL
replication stream consumer that knows how to send the appropriate
feedback messages. Besides the built-in physical and logical replication
systems, this includes special programs such
as <command>pg_receivewal</command> and <command>pg_recvlogical</command>
as well as some third-party replication systems and custom programs.
Check the respective documentation for details on synchronous replication
support.
同期スタンバイは、物理レプリケーションのスタンバイでも、論理レプリケーションのサブスクライバーのどちらでも構いません。
また同期スタンバイは、適切なフィードバックメッセージを送信する方法を知っている、物理あるいは論理WALレプリケーションストリームの消費者であっても構いません。
組み込みの物理あるいは論理レプリケーションシステムを別にすると、pg_receivewalとpg_recvlogical、それにサードパーティのレプリケーションシステムとカスタムプログラムが該当します。
対応する同期レプリケーションのサポートの詳細に関するドキュメントを参照してください。
Once streaming replication has been configured, configuring synchronous
replication requires only one additional configuration step:
<xref linkend="guc-synchronous-standby-names"/> must be set to
a non-empty value. <varname>synchronous_commit</varname> must also be set to
<literal>on</literal>, but since this is the default value, typically no change is
required. (See <xref linkend="runtime-config-wal-settings"/> and
<xref linkend="runtime-config-replication-primary"/>.)
This configuration will cause each commit to wait for
confirmation that the standby has written the commit record to durable
storage.
<varname>synchronous_commit</varname> can be set by individual
users, so it can be configured in the configuration file, for particular
users or databases, or dynamically by applications, in order to control
the durability guarantee on a per-transaction basis.
一度、ストリーミングレプリケーションが設定されている場合、同期レプリケーションの設定には必要な追加設定は１つだけ：synchronous_standby_namesを空でない値に設定することです。
またsynchronous_commitはonに設定されていなければなりませんが、これはデフォルト値ですので、通常は変更する必要はありません。（19.5.1 および19.6.2を参照してください。）
この設定によりスタンバイがそのコミットレコードを信頼できるストレージに書き込んだことが確認できるまで、各コミットが待たされるようになります。
synchronous_commitは個々のユーザによって設定することができます。
このため、トランザクション単位を基準とした永続性の保証を制御するために、設定ファイルの中で特定のユーザまたはデータベースについて設定することも、アプリケーションによって動的に設定することもできます。
After a commit record has been written to disk on the primary, the
WAL record is then sent to the standby. The standby sends reply
messages each time a new batch of WAL data is written to disk, unless
<varname>wal_receiver_status_interval</varname> is set to zero on the standby.
In the case that <varname>synchronous_commit</varname> is set to
<literal>remote_apply</literal>, the standby sends reply messages when the commit
record is replayed, making the transaction visible.
If the standby is chosen as a synchronous standby, according to the setting
of <varname>synchronous_standby_names</varname> on the primary, the reply
messages from that standby will be considered along with those from other
synchronous standbys to decide when to release transactions waiting for
confirmation that the commit record has been received. These parameters
allow the administrator to specify which standby servers should be
synchronous standbys. Note that the configuration of synchronous
replication is mainly on the primary. Named standbys must be directly
connected to the primary; the primary knows nothing about downstream
standby servers using cascaded replication.
コミットレコードがプライマリ上のディスクに書き出された後、WALレコードがスタンバイに送信されます。
スタンバイにてwal_receiver_status_intervalがゼロに設定されていない限り、スタンバイは新しいWALデータの塊がディスクに書き出される度に応答メッセージを返します。
synchronous_commitがremote_applyに設定されている場合には、コミットレコードが再生され、そのトランザクションが可視化されたときに応答メッセージを返します。
スタンバイが、プライマリ上のsynchronous_standby_namesにしたがって、同期スタンバイとして選ばれた時は、コミットレコードの受領の確認のために待機しているトランザクションをいつ解放すべきかを決めるために、他の同期スタンバイとともにそれらスタンバイからの応答メッセージが考慮されます。
これらのパラメータにより、管理者はどのスタンバイサーバを同期スタンバイとすべきかを指定することができます。
同期レプリケーションの設定は主にプライマリでなされることに注意してください。
指名されたスタンバイは直接プライマリサーバに接続される必要があります。
つまり、カスケードレプリケーションを使用している下流スタンバイサーバについて、プライマリサーバは何も知りません。
Setting <varname>synchronous_commit</varname> to <literal>remote_write</literal> will
cause each commit to wait for confirmation that the standby has received
the commit record and written it out to its own operating system, but not
for the data to be flushed to disk on the standby. This
setting provides a weaker guarantee of durability than <literal>on</literal>
does: the standby could lose the data in the event of an operating system
crash, though not a <productname>PostgreSQL</productname> crash.
However, it's a useful setting in practice
because it can decrease the response time for the transaction.
Data loss could only occur if both the primary and the standby crash and
the database of the primary gets corrupted at the same time.
synchronous_commitをremote_writeに設定することで、個々のコミットは、スタンバイサーバがコミットされたレコードを受け取り、オペレーティングシステムに書きだしたことが確認できるまで待ちますが、スタンバイ上のディスクにフラッシュするまでは待ちません。
これは、onと設定するより、提供される永続性は弱くなります。
具体的には、スタンバイサーバはオペレーティングシステムがクラッシュした場合にデータを失う可能性がありますが、PostgreSQLがクラッシュした場合にはデータを失いません。
しかし、実用的にはこの設定はトランザクションの応答時間を短くすることができるので有用です。
データの損失は、プライマリサーバとスタンバイサーバが同時にクラッシュし、かつ、プライマリのデータベースが同時に壊れた場合にのみ発生します。
Setting <varname>synchronous_commit</varname> to <literal>remote_apply</literal> will
cause each commit to wait until the current synchronous standbys report
that they have replayed the transaction, making it visible to user
queries. In simple cases, this allows for load balancing with causal
consistency.
synchronous_commitをremote_applyに設定することで、現在の同期スタンバイがトランザクションを再生し、ユーザから見えるようにしたと報告するまでは各々のコミットは待たされます。
単純なケースでは、因果一貫性を保つ負荷分散を可能にします。
Users will stop waiting if a fast shutdown is requested. However, as when using asynchronous replication, the server will not fully shutdown until all outstanding WAL records are transferred to the currently connected standby servers. 高速シャットダウンが要求された場合、ユーザは待ち状態ではなくなります。 しかし非同期レプリケーションを使用している時と同じく、送信中のWALレコードが現在接続しているスタンバイサーバに転送されるまで、サーバは完全に停止しません。
Synchronous replication supports one or more synchronous standby servers;
transactions will wait until all the standby servers which are considered
as synchronous confirm receipt of their data. The number of synchronous
standbys that transactions must wait for replies from is specified in
<varname>synchronous_standby_names</varname>. This parameter also specifies
a list of standby names and the method (<literal>FIRST</literal> and
<literal>ANY</literal>) to choose synchronous standbys from the listed ones.
同期レプリケーションは、一つ以上の同期スタンバイサーバをサポートします。
同期と見なされるすべてのスタンバイサーバがデータの受領を確認するまで、トランザクションは待機します。
トランザクションが応答を待たなければならない同期スタンバイの数は、synchronous_standby_namesで指定されます。
また、このパラメータには、スタンバイの名前のリストと、リストされたものから同期スタンバイを選ぶ方法（FIRSTとANY）を指定します。
The method <literal>FIRST</literal> specifies a priority-based synchronous
replication and makes transaction commits wait until their WAL records are
replicated to the requested number of synchronous standbys chosen based on
their priorities. 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.
方法FIRSTは優先度に基づく同期レプリケーションを指定し、優先度に応じて選択された同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットは待機します。
リストの前の方に名前が書いてあるスタンバイにはより高い優先度が与えられ、同期とみなされます。
リストの後ろの方に書いてあるスタンバイは、潜在的な同期スタンバイであることを示します。
どんな理由であれ、現在のスタンバイのどれかの接続が切断されると、次に優先度が高いスタンバイがとって代わります。
An example of <varname>synchronous_standby_names</varname> for
a priority-based multiple synchronous standbys is:
優先度に基づく複数同期スタンバイのためのsynchronous_standby_namesの例を示します。
synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
In this example, if four standby servers <literal>s1</literal>, <literal>s2</literal>,
<literal>s3</literal> and <literal>s4</literal> are running, the two standbys
<literal>s1</literal> and <literal>s2</literal> will be chosen as synchronous standbys
because their names appear early in the list of standby names.
<literal>s3</literal> is a potential synchronous standby and will take over
the role of synchronous standby when either of <literal>s1</literal> or
<literal>s2</literal> fails. <literal>s4</literal> is an asynchronous standby since
its name is not in the list.
この例では、もし4つのスタンバイサーバs1、s2、s3、s4が稼働中なら、s1とs2が同期スタンバイに選ばれます。
それらの名前がスタンバイ名のリストの最初の方にあるからです。
s3は潜在的な同期スタンバイで、s1あるいはs2が故障した時に同期スタンバイの役割を取って代わります。
このリストに名前が載っていないので、s4は非同期スタンバイです。
The method <literal>ANY</literal> specifies a quorum-based synchronous
replication and makes transaction commits wait until their WAL records
are replicated to <emphasis>at least</emphasis> the requested number of
synchronous standbys in the list.
方法ANYはクォーラムに基づく同期レプリケーションを指定し、少なくともリスト中で指定された数の同期スタンバイにWALレコードがレプリケーションされるまで、トランザクションのコミットを待たせます
An example of <varname>synchronous_standby_names</varname> for
a quorum-based multiple synchronous standbys is:
クォーラムに基づく同期スタンバイのためのsynchronous_standby_namesの例を示します。
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
In this example, if four standby servers <literal>s1</literal>, <literal>s2</literal>,
<literal>s3</literal> and <literal>s4</literal> are running, transaction commits will
wait for replies from at least any two standbys of <literal>s1</literal>,
<literal>s2</literal> and <literal>s3</literal>. <literal>s4</literal> is an asynchronous
standby since its name is not in the list.
この例では、もし4つのスタンバイサーバs1、s2、s3、s4が稼働中なら、トランザクションのコミットは、s1、s2、s3のどれか二つのスタンバイから応答があるまで待たされます。
このリストに名前が載っていないので、s4は非同期スタンバイです。
The synchronous states of standby servers can be viewed using
the <structname>pg_stat_replication</structname> view.
pg_stat_replicationビューを使って、スタンバイサーバの同期状態を見ることができます。
Synchronous replication usually requires carefully planned and placed standby servers to ensure applications perform acceptably. Waiting doesn't utilize system resources, but transaction locks continue to be held until the transfer is confirmed. As a result, incautious use of synchronous replication will reduce performance for database applications because of increased response times and higher contention. 通常、同期レプリケーションは、アプリケーションが満足できる程度に実行されることを確実にするために、注意深くスタンバイサーバを計画し設置しなければなりません。 待機のためにシステムリソースを使用することはありませんが、トランザクションロックは転送が確認されるまで継続して保持されます。 結果として同期レプリケーションを注意せずに使用すると、応答時間が増加する、および競合がより高くなるため、データベースアプリケーションの性能は低下します。
<productname>PostgreSQL</productname> allows the application developer to specify the durability level required via replication. This can be specified for the system overall, though it can also be specified for specific users or connections, or even individual transactions. PostgreSQLではアプリケーション開発者がレプリケーション経由で必要とする永続性レベルを指定することができます。 これをシステム全体に対して指定することができますし、特定のユーザ、接続、個々のトランザクションに対してさえ指定することもできます。
For example, an application workload might consist of: 10% of changes are important customer details, while 90% of changes are less important data that the business can more easily survive if it is lost, such as chat messages between users. 例えばアプリケーションの作業量が、重要な顧客詳細の変更が10%、ユーザ間のチャットメッセージなど、あまり重要ではなく、失ったとしても業務をより簡単に戻すことができるようなデータの変更が90% という構成を考えてみます。
With synchronous replication options specified at the application level (on the primary) we can offer synchronous replication for the most important changes, without slowing down the bulk of the total workload. Application level options are an important and practical tool for allowing the benefits of synchronous replication for high performance applications. （プライマリ上で）アプリケーションレベルで指定する同期レプリケーションオプションを使用して、作業全体を低速化させることなく、最も重要な変更に対して同期レプリケーションを企てることができます。 アプリケーションレベルのオプションは、高い性能が求められるアプリケーションで同期レプリケーションの利点が得られる、重要かつ現実的な手段です。
You should consider that the network bandwidth must be higher than the rate of generation of WAL data. 生成されるWALデータの割合よりネットワーク帯域幅が大きくなければならないことを考慮しなければなりません。
<varname>synchronous_standby_names</varname> specifies the number and
names of synchronous standbys that transaction commits made when
<varname>synchronous_commit</varname> is set to <literal>on</literal>,
<literal>remote_apply</literal> or <literal>remote_write</literal> will wait for
responses from. Such transaction commits may never be completed
if any one of the synchronous standbys should crash.
synchronous_commitが、on、remote_apply、remote_writeのいずれかに設定されている場合、synchronous_standby_namesには、コミットされたトランザクションが応答を待つ同期スタンバイの数と名前を指定します。
もし同期スタンバイのどれかがクラッシュした場合、そのようなトランザクションのコミットは決して完了しないかもしれません。
The best solution for high availability is to ensure you keep as many
synchronous standbys as requested. This can be achieved by naming multiple
potential synchronous standbys using <varname>synchronous_standby_names</varname>.
高可用性のもっとも良い解決方法は、想定したのと同じ数の同期スタンバイを確実に確保することです。
これは、synchronous_standby_namesを使って同期スタンバイ候補を複数指定することによって実現できます。
そのリストの最初の方に名前が上がっているスタンバイは、同期スタンバイとして使用されます。
その後の方に名前が上がっているスタンバイは、同期スタンバイのどれかが故障した時に、その役割を取って代わります。
In a priority-based synchronous replication, the standbys whose names appear earlier in the list will be used as synchronous standbys. Standbys listed after these will take over the role of synchronous standby if one of current ones should fail. 優先度に基づく同期レプリケーションでは、リストの前の方に名前が現れるスタンバイが同期スタンバイになります。 現在の同期スタンバイのどれかが故障した際には、リストの後の方にあるスタンバイが同期スタンバイの役割を引き継ぎます。
In a quorum-based synchronous replication, all the standbys appearing in the list will be used as candidates for synchronous standbys. Even if one of them should fail, the other standbys will keep performing the role of candidates of synchronous standby. クォーラムに基づく同期レプリケーションでは、リストに現れたすべてのスタンバイが同期スタンバイの候補となります。 そのどれかが故障した場合でも、他のスタンバイは引き続き同期スタンバイの候補としての役割を担い続けます。
When a standby first attaches to the primary, it will not yet be properly
synchronized. This is described as <literal>catchup</literal> mode. Once
the lag between standby and primary reaches zero for the first time
we move to real-time <literal>streaming</literal> state.
The catch-up duration may be long immediately after the standby has
been created. If the standby is shut down, then the catch-up period
will increase according to the length of time the standby has been down.
The standby is only able to become a synchronous standby
once it has reached <literal>streaming</literal> state.
This state can be viewed using
the <structname>pg_stat_replication</structname> view.
スタンバイが最初にプライマリに接続された時、それはまだ適切に同期されていません。
これはcatchupモードと呼ばれます。
一旦スタンバイとプライマリ間の遅延がゼロになると、実時間streaming状態に移ります。
追従（catchup）期間はスタンバイが作成された直後は長くなるかもしれません。
スタンバイが停止している場合、追従期間はスタンバイの停止期間にしたがって長くなります。
スタンバイは、streaming状態に達した後でのみ、同期スタンバイになることができます。
この状態は、pg_stat_replicationビューで見ることができます。
If primary restarts while commits are waiting for acknowledgment, those waiting transactions will be marked fully committed once the primary database recovers. There is no way to be certain that all standbys have received all outstanding WAL data at time of the crash of the primary. Some transactions may not show as committed on the standby, even though they show as committed on the primary. The guarantee we offer is that the application will not receive explicit acknowledgment of the successful commit of a transaction until the WAL data is known to be safely received by all the synchronous standbys. コミットが受領通知を待機している間にプライマリが再起動した場合、プライマリデータベースが復旧した後、待機中のトランザクションは完全にコミットされたものと記録されます。 すべてのスタンバイがプライマリのクラッシュ時点で送信中のWALデータのすべてを受信したかどうかを確認する方法はありません。 トランザクションの一部は、プライマリではコミットされたものと表示されていたとしても、スタンバイではコミットされていないと表示されるかもしれません。 PostgreSQLは、WALデータをすべてのスタンバイが安全に受信したことが分かるまで、アプリケーションは明示的なトランザクションコミットの成功に関する受領通知を受けとらないことを保証しています。
If you really cannot keep as many synchronous standbys as requested
then you should decrease the number of synchronous standbys that
transaction commits must wait for responses from
in <varname>synchronous_standby_names</varname> (or disable it) and
reload the configuration file on the primary server.
要求していた数の同期スタンバイを本当に確保できないときは、トランザクションが応答を待たなければならない同期スタンバイの数を、synchronous_standby_namesから減らしてください（もしくは無効にします）。
そして、プライマリサーバの設定ファイルを再読み込みしてください。
If the primary is isolated from remaining standby servers you should fail over to the best candidate of those other remaining standby servers. プライマリが既存のスタンバイサーバから切り離された場合は、スタンバイサーバの中から最善と思われる候補にフェイルオーバーしてください。
If you need to re-create a standby server while transactions are
waiting, make sure that the functions <function>pg_backup_start()</function>
and <function>pg_backup_stop()</function> are run in a session with
<varname>synchronous_commit</varname> = <literal>off</literal>, otherwise those
requests will wait forever for the standby to appear.
《マッチ度[80.758017]》トランザクションの待機中にスタンバイサーバを再作成する必要がある場合、pg_backup_start()およびpg_backup_stop()を実行するコマンドをsynchronous_commit = offであるセッション内で確実に実行してください。
さもないとこれらの要求はスタンバイに現れるまで永遠に待機します。
《機械翻訳》トランザクションの待機中にスタンバイサーバを再作成する必要がある場合、makeは、関数pg_backup_start()とpg_backup_stop()がsynchronous_commit = offで実行されていることを確認します。
そうでない場合、これらの要求はスタンバイが現れるまで永遠に待機します。
When continuous WAL archiving is used in a standby, there are two
different scenarios: the WAL archive can be shared between the primary
and the standby, or the standby can have its own WAL archive. When
the standby has its own WAL archive, set <varname>archive_mode</varname>
to <literal>always</literal>, and the standby will call the archive
command for every WAL segment it receives, whether it's by restoring
from the archive or by streaming replication. The shared archive can
be handled similarly, but the <varname>archive_command</varname> or <varname>archive_library</varname> must
test if the file being archived exists already, and if the existing file
has identical contents. This requires more care in the
<varname>archive_command</varname> or <varname>archive_library</varname>, as it must
be careful to not overwrite an existing file with different contents,
but return success if the exactly same file is archived twice. And
all that must be done free of race conditions, if two servers attempt
to archive the same file at the same time.
スタンバイにおいてWALの継続的アーカイビングが行われる場合、2つのシナリオが考えられます。
WALアーカイブがプライマリとスタンバイで共有されるケースと、スタンバイが自分のWALアーカイブを持つケースです。
スタンバイが自分のWALアーカイブを持つケースでは、archive_modeをalwaysに設定しておくことにより、アーカイブからリストアされたWALセグメントであろうと、ストリーミングレプリケーション由来のWALセグメントであろうと、WALセグメントを受信する度にスタンバイはアーカイブコマンドを呼び出します。
共有アーカイブのケースも同じように扱えますが、archive_commandまたはarchive_libraryはアーカイブしようとしているファイルがすでに存在していて、それが同一内容かどうかのチェックを行う必要があります。
archive_commandやarchive_libraryでは、異なる内容で既存のファイルを上書きしないように、ただしまったく同じファイルが2回アーカイブされた場合は成功を返すように注意する必要があります
また、2つのサーバが同時に同じファイルをアーカイブしようとした場合は、競合状態が発生しないようにする必要があります。
If <varname>archive_mode</varname> is set to <literal>on</literal>, the
archiver is not enabled during recovery or standby mode. If the standby
server is promoted, it will start archiving after the promotion, but
will not archive any WAL or timeline history files that
it did not generate itself. To get a complete
series of WAL files in the archive, you must ensure that all WAL is
archived, before it reaches the standby. This is inherently true with
file-based log shipping, as the standby can only restore files that
are found in the archive, but not if streaming replication is enabled.
When a server is not in recovery mode, there is no difference between
<literal>on</literal> and <literal>always</literal> modes.
archive_modeがonの場合には、リカバリモードあるいはスタンバイモードではアーカイブは有効になりません。
スタンバイサーバが昇格すると、昇格後にスタンバイサーバはアーカイブを開始します。
しかし、自分が生成しなかったWALやタイムライン履歴ファイルは一切アーカイブしません。
完全な一連のWALファイルをアーカイブから取り出すためには、WALがスタンバイに到着する前に、すべてのWALがアーカイブされていることを保証しなければなりません。
ファイルベースのログシッピングにおいても本質的にはこの通りです。
というのも、スタンバイはアーカイブにあるファイルだけをリストアできるからです。
ストリーミングレプリケーションが有効ならば、この限りではありません。
サーバがリカバリモードでない場合には、onとalwaysのモードの間には違いはありません。