## 20.6. Replication

[20.6.1. Sending Servers](runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER)

[20.6.2. Primary Server](runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-PRIMARY)

[20.6.3. Standby Servers](runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-STANDBY)

[20.6.4. Subscribers](runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SUBSCRIBER)

These settings control the behavior of the built-in*streaming replication*feature (see[Section 27.2.5](warm-standby.html#STREAMING-REPLICATION)). 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[Section 27.2.7](warm-standby.html#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.

### 20.6.1. Sending Servers

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.

`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`10`. The value`0`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,`wal_level`must be set to`replica`or higher to allow connections from standby servers.

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[Section 27.2.6](warm-standby.html#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,`wal_level`must be set to`replica`or higher to allow replication slots to be used.

On the subscriber side, specifies how many replication origins (see[Chapter 50](replication-origins.html)) 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[pg_replication_origin_status](view-pg-replication-origin-status.html), not[pg_replication_origin](catalog-pg-replication-origin.html)) will prevent the server from starting.

`wal_keep_size`(`integer`)[](<>)

指定保存在`pg_wal`目录，以防备用服务器需要获取它们以进行流复制。如果连接到发送服务器的备用服务器落后超过`wal_keep_size`兆字节，发送服务器可能会删除备用服务器仍需要的 WAL 段，在这种情况下，复制连接将被终止。结果，下游连接最终也会失败。（但是，如果 WAL 归档正在使用，备用服务器可以通过从归档中获取段来恢复。）

这仅设置保留在`pg_wal`;系统可能需要为 WAL 归档或从检查点恢复保留更多段。如果`wal_keep_size`为零（默认值），系统不会为备用目的保留任何额外的段，因此备用服务器可用的旧 WAL 段的数量是前一个检查点的位置和 WAL 归档状态的函数。如果此值指定为不带单位，则以兆字节为单位。该参数只能在`postgresql.conf`文件或在服务器命令行上。

`max_slot_wal_keep_size`(`整数`)[](<>)

指定 WAL 文件的最大大小[复制槽](warm-standby.html#STREAMING-REPLICATION-SLOTS)被允许保留在`pg_wal`检查点时的目录。如果`max_slot_wal_keep_size`是 -1（默认值），复制槽可以保留无限数量的 WAL 文件。否则，如果重新启动\_复制槽的 lsn 落后于当前 LSN 超过给定大小，由于删除了所需的 WAL 文件，使用该槽的备用可能不再能够继续复制。您可以在中查看复制槽的 WAL 可用性[皮克\_复制\_插槽](view-pg-replication-slots.html). If this value is specified without units, it is taken as megabytes. This parameter can only be set in the`postgresql.conf`file or on the server command line.

`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.

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`postgresql.conf`file or on the server command line. The default value is`off`.

### 20.6.2. Primary Server

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,[wal_level](runtime-config-wal.html#GUC-WAL-LEVEL)must be set appropriately on the primary server, and optionally WAL archiving can be enabled as well (see[Section 20.5.3](runtime-config-wal.html#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.

`synchronous_standby_names`(`string`)[](<>)

指定可以支持的备用服务器列表*同步复制*，如中所述[第 27.2.8 节](warm-standby.html#SYNCHRONOUS-REPLICATION).将有一个或多个活动同步备用；在这些备用服务器确认收到其数据后，将允许等待提交的事务继续进行。同步备用数据库将是其名称出现在此列表中的那些，并且它们既是当前连接的又是实时流数据的（如状态所示`流媒体`在里面[`pg_stat_replication`](monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW)看法）。指定多个同步备用可以实现非常高的可用性并防止数据丢失。

用于此目的的备用服务器的名称是`应用名称`备用设备的设置，如备用设备的连接信息中所设置。在物理复制备用的情况下，这应该在`primary_conninfo`环境;默认是设置[簇\_姓名](runtime-config-logging.html#GUC-CLUSTER-NAME)如果设置，否则`接收器`.对于逻辑复制，可以在订阅的连接信息中设置，默认为订阅名。对于其他复制流消费者，请查阅他们的文档。

此参数使用以下任一语法指定备用服务器列表：

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

在哪里*`num_sync`*是事务需要等待回复的同步备用数据库的数量，并且*`备用名称`*是备用服务器的名称。`第一的`和`任何`指定从列出的服务器中选择同步备用服务器的方法。

关键字`第一的`，再加上*`num_sync`*，指定基于优先级的同步复制，并使事务提交等到它们的 WAL 记录被复制到*`num_sync`*根据优先级选择同步备用。例如，一个设置`前 3 (s1, s2, s3, s4)`将导致每个提交等待来自备用服务器选择的三个更高优先级备用服务器的回复`s1`,`s2`,`s3`和`s4`.名称在列表中较早出现的备用数据库具有更高的优先级，并将被视为同步的。此列表后面出现的其他备用服务器代表潜在的同步备用服务器。如果任何当前同步备用数据库由于某种原因断开连接，它将立即被下一个最高优先级备用数据库替换。关键字`第一的`是可选的。

关键字`任何`，再加上*`num_sync`*, 指定基于仲裁的同步复制并使事务提交等到它们的 WAL 记录被复制到*至少* *`num_sync`*列出的备用。例如，一个设置`任意 3 个（s1、s2、s3、s4）`将导致每个提交在至少任何三个备用`s1`,`s2`,`s3`和`s4`回复。

`第一的`和`任何`不区分大小写。如果这些关键字用作备用服务器的名称，它的*`备用名称`*必须双引号。

第三种语法在 PostgreSQL 版本 9.6 之前使用并且仍然受支持。它与第一个语法相同`第一的`和*`num_sync`*等于 1。例如，第 1 个 (s1, s2)`和`s1, s2`具有相同的含义：要么`s1`或者`s2`被选为同步备用。`特殊条目

\*`匹配任何备用名称。`没有强制备用名称唯一性的机制。

在重复的情况下，匹配的备用数据库之一将被视为更高的优先级，但究竟哪一个是不确定的。

### 笔记

每个*`备用名称`*应该具有有效 SQL 标识符的形式，除非它是`*`.如有必要，您可以使用双引号。但请注意*`备用名称`*s 与备用应用程序名称进行比较，不区分大小写，无论是否双引号。

如果此处未指定同步备用名称，则不会启用同步复制，并且事务提交不会等待复制。这是默认配置。即使启用了同步复制，也可以通过设置单个事务来配置不等待复制[同步\_犯罪](runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT)参数为`当地的`或者`离开`.

该参数只能在`postgresql.conf`文件或在服务器命令行上。

`vacuum_defer_cleanup_age`(`整数`)[](<>)

指定交易数量`真空`和 HOT 更新将推迟对死行版本的清理。默认值为零事务，这意味着可以尽快删除死行版本，也就是说，只要它们不再对任何打开的事务可见。您可能希望在支持热备用服务器的主服务器上将其设置为非零值，如中所述[第 27.4 节](hot-standby.html).这允许有更多时间完成备用数据库上的查询，而不会因提前清理行而引发冲突。但是，由于该值是根据主服务器上发生的写入事务数来衡量的，因此很难预测有多少额外的宽限时间可用于备用查询。该参数只能在`postgresql.conf`file or on the server command line.

You should also consider setting`hot_standby_feedback`on standby server(s) as an alternative to using this parameter.

This does not prevent cleanup of dead rows which have reached the age specified by`old_snapshot_threshold`.

### 20.6.3. Standby Servers

These settings control the behavior of a[standby server](warm-standby.html#STANDBY-SERVER-OPERATION)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[Section 34.1.1](libpq-connect.html#LIBPQ-CONNSTRING). If any option is unspecified in this string, then the corresponding environment variable (see[Section 34.15](libpq-envars.html)) is checked. If the environment variable is not set either, then defaults are used.

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[Section 27.2.5.1](warm-standby.html#STREAMING-REPLICATION-AUTHENTICATION)). A password needs to be provided too, if the sender demands password authentication. It can be provided in the`primary_conninfo`string, or in a separate`~/.pgpass`file on the standby server (use`replication`as the database name). Do not specify a database name in the`primary_conninfo`细绳。

该参数只能在`postgresql.conf`文件或在服务器命令行上。如果在 WAL 接收器进程运行时更改了此参数，则该进程会发出关闭信号并期望以新设置重新启动（除非`primary_conninfo`是一个空字符串）。如果服务器未处于待机模式，此设置无效。

`primary_slot_name`(`细绳`)[](<>)

可选地指定一个现有的复制槽，当通过流复制连接到发送服务器以控制上游节点上的资源删除时（请参阅[第 27.2.6 节](warm-standby.html#STREAMING-REPLICATION-SLOTS)）。该参数只能在`postgresql.conf`文件或在服务器命令行上。如果在 WAL 接收器进程正在运行时更改了此参数，则该进程会发出关闭信号，并希望以新设置重新启动。此设置无效，如果`primary_conninfo`未设置或服务器未处于待机模式。

`提升触发器文件`(`细绳`)[](<>)

指定一个触发器文件，其存在结束备用数据库中的恢复。即使未设置此值，您仍然可以使用`pg_ctl 提升`或打电话`pg_promote()`.该参数只能在`postgresql.conf`文件或在服务器命令行上。

`热备`(`布尔值`)[](<>)

指定您是否可以在恢复期间连接和运行查询，如中所述[第 27.4 节](hot-standby.html).默认值为`在`.此参数只能在服务器启动时设置。它仅在存档恢复或待机模式下有效。

`max_standby_archive_delay`(`整数`)[](<>)

当 Hot Standby 处于活动状态时，此参数确定备用服务器在取消与即将应用的 WAL 条目冲突的备用查询之前应等待多长时间，如中所述[第 27.4.2 节](hot-standby.html#HOT-STANDBY-CONFLICT).`max_standby_archive_delay`当从 WAL 存档中读取 WAL 数据时适用（因此不是最新的）。如果指定此值没有单位，则以毫秒为单位。默认值为 30 秒。值 -1 允许备用数据库永远等待冲突查询完成。该参数只能在`postgresql.conf`文件或在服务器命令行上。

注意`max_standby_archive_delay`与取消前查询可以运行的最长时间不同；相反，它是允许应用任何一个 WAL 段数据的最大总时间。因此，如果一个查询在 WAL 段的早期导致了显着延迟，那么后续的冲突查询将具有更少的宽限时间。

`max_standby_streaming_delay`(`整数`)[](<>)

当 Hot Standby 处于活动状态时，此参数确定备用服务器在取消与即将应用的 WAL 条目冲突的备用查询之前应等待多长时间，如中所述[第 27.4.2 节](hot-standby.html#HOT-STANDBY-CONFLICT).`max_standby_streaming_delay`当通过流复制接收 WAL 数据时适用。如果指定此值没有单位，则以毫秒为单位。默认值为 30 秒。值 -1 允许备用数据库永远等待冲突查询完成。该参数只能在`postgresql.conf`文件或在服务器命令行上。

注意`max_standby_streaming_delay`与取消前查询可以运行的最长时间不同；相反，它是从主服务器接收到 WAL 数据后允许应用的最大总时间。因此，如果一个查询导致了明显的延迟，那么后续的冲突查询将有更少的宽限时间，直到备用服务器再次赶上。

`wal_receiver_create_temp_slot`(`布尔值`)[](<>)

指定当没有配置要使用的永久复制槽时（使用[基本的\_投币口\_姓名](runtime-config-replication.html#GUC-PRIMARY-SLOT-NAME)）。默认为关闭。该参数只能在`postgresql.conf`文件或在服务器命令行上。如果在 WAL 接收器进程正在运行时更改了此参数，则该进程会发出关闭信号，并希望以新设置重新启动。

`wal_receiver_status_interval`(`整数`)[](<>)

指定备用服务器上的 WAL 接收器进程向主备用服务器或上游备用服务器发送有关复制进度的信息的最小频率，可以使用[`pg_stat_replication`](monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-VIEW)看法。备用数据库将报告它写入的最后一个预写日志位置、它刷新到磁盘的最后一个位置以及它应用的最后一个位置。此参数的值是报告之间的最长时间。每次写入或刷新位置更改时发送更新，或者如果设置为非零值，则按照此参数指定的频率发送更新。还有其他情况会在忽略此参数的情况下发送更新；例如，当现有 WAL 的处理完成或当`同步提交`设定为`远程应用`.因此，应用位置可能会稍微落后于真实位置。如果指定此值没有单位，则以秒为单位。默认值为 10 秒。该参数只能在`postgresql.conf`文件或在服务器命令行上。

`hot_standby_feedback`(`布尔值`)[](<>)

指定热备用是否将有关当前在备用上执行的查询的反馈发送到主备用或上游备用。此参数可用于消除因清除记录而导致的查询取消，但可能会导致某些工作负载的主数据库膨胀。反馈消息的发送频率不会超过一次`wal_receiver_status_interval`.默认值为`离开`.该参数只能在`postgresql.conf`文件或在服务器命令行上。

如果级联复制正在使用，则反馈将向上传递，直到最终到达主节点。除了向上游传递之外，备用服务器不使用他们收到的反馈。

此设置不会覆盖`old_snapshot_threshold`在初级;备用数据库上超过主数据库年龄阈值的快照可能会变得无效，从而导致备用数据库上的事务取消。这是因为`old_snapshot_threshold`旨在为死行可能导致膨胀的时间提供绝对限制，否则会因为备用配置而被违反。

`wal_receiver_timeout`(`整数`)[](<>)

终止超过此时间不活动的复制连接。这对于接收备用服务器检测主节点崩溃或网络中断很有用。如果指定此值没有单位，则以毫秒为单位。默认值为 60 秒。零值禁用超时机制。该参数只能在`postgresql.conf`文件或在服务器命令行上。

`wal_retrieve_retry_interval`(`整数`)[](<>)

指定当 WAL 数据不能从任何源（流复制、本地`pg_wal`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`postgresql.conf`file or on the server command line.

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 log 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 amount of times an infrastructure is accessed is taken into account.

`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`5min`, 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.

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.

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.

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.

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.`hot_standby_feedback`will be delayed by use of this feature which could lead to bloat on the primary; use both together with care.

### Warning

Synchronous replication is affected by this setting when`synchronous_commit`is set to`remote_apply`; every`COMMIT`will need to wait to be applied.

This parameter can only be set in the`postgresql.conf`file or on the server command line.

### 20.6.4. Subscribers

These settings control the behavior of a logical replication subscriber. Their values on the publisher are irrelevant.

Note that`wal_receiver_timeout`,`wal_receiver_status_interval`and`wal_retrieve_retry_interval`configuration parameters affect the logical replication workers as well.

`max_logical_replication_workers`(`int`)[](<>)

Specifies maximum number of logical replication workers. This includes both apply workers and table synchronization workers.

Logical replication workers are taken from the pool defined by`max_worker_processes`.

The default value is 4. This parameter can only be set at server start.

`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`max_logical_replication_workers`.

The default value is 2. This parameter can only be set in the`postgresql.conf`file or on the server command line.