# 27.2.日志传送备用服务器
连续存档可用于创建高可用性(HA)具有一个或多个备用服务器准备好在主服务器出现故障时接管操作。这种能力被广泛称为热备用或原木运输.
主服务器和备用服务器协同工作以提供此功能,尽管服务器只是松散耦合的。主服务器以连续存档模式运行,而每个备用服务器以连续恢复模式运行,从主服务器读取WAL文件。启用此功能不需要更改数据库表,因此与其他一些复制解决方案相比,它提供了较低的管理开销。这种配置对主服务器的性能影响也相对较低。
将WAL记录从一个数据库服务器直接移动到另一个数据库服务器通常称为日志传送。PostgreSQL通过一次传输一个文件(WAL段)来实现基于文件的日志传送。WAL文件(16MB)可以轻松、廉价地跨任意距离发送,无论是到相邻系统、同一站点的另一个系统,还是地球另一端的另一个系统。这种技术所需的带宽根据主服务器的事务速率而变化。基于记录的日志传送更细粒度,并且通过网络连接进行增量更改(请参阅第27.2.5节).
应该注意的是,日志传送是异步的,也就是说,WAL记录是在事务提交之后传送的。因此,如果主服务器发生灾难性故障,则存在数据丢失的窗口;尚未发货的交易将丢失。在基于文件的日志传送中,数据丢失窗口的大小可以通过使用存档超时
参数,可将其设置为最短几秒钟。但是,这样的低设置将大大增加文件传送所需的带宽。流式复制(请参阅第27.2.5节)允许更小的数据丢失窗口。
恢复性能足够好,一旦激活,待机通常只需几分钟即可完全可用。因此,这被称为热备用配置,可提供高可用性。从存档的基本备份和前滚恢复服务器将花费相当长的时间,因此该技术只提供了灾难恢复解决方案,而不是高可用性。备用服务器也可以用于只读查询,在这种情况下,它被称为热备用服务器。看见第27.4节了解更多信息。
# 27.2.1.计划
通常明智的做法是创建主服务器和备用服务器,使它们尽可能相似,至少从数据库服务器的角度来看是如此。特别是,与表空间关联的路径名将在未修改的情况下传递,因此,如果使用该功能,主服务器和备用服务器必须具有相同的表空间装载路径。记住,如果创建表空间在主服务器上执行时,必须在主服务器和所有备用服务器上创建该命令所需的任何新装载点,然后才能执行该命令。硬件不一定完全相同,但经验表明,在应用程序和系统的生命周期内,维护两个相同的系统比维护两个不同的系统更容易。在任何情况下,硬件架构都必须是相同的——比如说,从32位系统运送到64位系统都不起作用。
一般来说,运行不同主要PostgreSQL版本的服务器之间不可能进行日志传送。PostgreSQL Global Development Group的政策是在小版本升级期间不更改磁盘格式,因此,在主服务器和备用服务器上运行不同的小版本很可能会成功。但是,没有提供对此的正式支持,建议您尽可能将主服务器和备用服务器保持在相同的版本级别。当更新到新的次要版本时,最安全的策略是首先更新备用服务器——新的次要版本更有可能从以前的次要版本读取WAL文件,反之亦然。
# 27.2.2.备用服务器操作
如果出现以下情况,服务器将进入待机模式:备用物品信号
服务器启动时,数据目录中存在文件。
在待机模式下,服务器持续应用从主服务器接收的WAL。备用服务器可以从WAL存档中读取WAL(请参阅恢复_命令)或者通过TCP连接直接从主服务器(流式复制)。备用服务器还将尝试恢复在备用群集的普格沃尔
目录这通常发生在服务器重新启动后,当备用服务器重新播放在重新启动前从主服务器流式传输的文件时,但您也可以手动将文件复制到普格沃尔
随时让他们重播。
启动时,待机状态首先恢复存档位置中的所有可用WAL,然后调用恢复命令
.当它到达沃尔的尽头时恢复命令
如果失败,它将尝试恢复中可用的所有WAL普格沃尔
目录如果失败,并且已配置流式复制,则备用服务器将尝试连接到主服务器,并从存档或备份中找到的最后一条有效记录开始流式复制普格沃尔
。如果该操作失败或未配置流式复制,或者如果稍后断开连接,则待机设备将返回到步骤1,并再次尝试从存档恢复文件。从档案中进行的一系列重试,普格沃尔
,并通过流式复制继续进行,直到服务器停止或由触发器文件触发故障转移。
待机模式退出,服务器在以下情况下切换到正常操作:pg_ctl促进
它在运行,pg_promote()
调用,或找到触发器文件(升级触发文件
)。在故障切换之前,任何WAL都可以立即在存档或普格沃尔
将被还原,但未尝试连接到主服务器。
# 27.2.3.为备用服务器准备主服务器
如中所述,将主服务器上的连续存档设置为可从备用服务器访问的存档目录第26.3节。即使主服务器关闭,存档位置也应该可以从备用服务器访问,即它应该位于备用服务器本身或另一个受信任的服务器上,而不是主服务器上。
如果要使用流式复制,请在主服务器上设置身份验证,以允许从备用服务器进行复制连接;也就是说,创建一个角色并在中提供一个或多个合适的条目pg_hba。形态
数据库字段设置为复制
.还要确保max_wal_senders
在主服务器的配置文件中设置为足够大的值。如果要使用复制插槽,请确保最大复制插槽数
也设置得足够高。
按照中的说明进行基本备份第26.3.2节引导备用服务器。
# 27.2.4.设置备用服务器
要设置备用服务器,请还原从主服务器获取的基本备份(请参阅第26.3.4节).创建一个文件备用物品信号
在备用设备的群集数据目录中。设置恢复_命令到一个简单的命令,从WAL档案复制文件。如果计划使用多台备用服务器以实现高可用性,请确保恢复_目标_时间表
即将最近的
(默认设置),使备用服务器遵循故障切换到另一个备用服务器时发生的时间线更改。
# 笔记
恢复_命令如果文件不存在,应立即返回;如有必要,服务器将再次重试该命令。
如果要使用流式复制,请填写主要的,重要的_康宁使用libpq连接字符串,包括主机名(或IP地址)以及连接到主服务器所需的任何其他详细信息。如果主服务器需要密码进行身份验证,则需要在中指定密码主要的,重要的_康宁也
如果出于高可用性目的设置备用服务器,请像主服务器一样设置WAL存档、连接和身份验证,因为备用服务器在故障切换后将作为主服务器工作。
如果您使用的是WAL存档,则可以使用档案文件_清理_命令参数删除备用服务器不再需要的文件。pg_archivecleanup实用程序专门设计用于存档\u清除\u命令
在典型的单待机配置中,请参阅pg_archivecleanup。但是,请注意,如果您将存档用于备份目的,则需要保留至少从最新的基本备份中恢复所需的文件,即使备份不再需要这些文件。
配置的一个简单示例是:
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'
您可以有任意数量的备用服务器,但如果使用流式复制,请确保设置max_wal_senders
一次侧足够高,可以同时连接。
# 27.2.5.流式复制
流式复制允许备用服务器比基于文件的日志传送更及时地更新。备用服务器连接到主服务器,主服务器在生成WAL记录时将WAL记录流式传输到备用服务器,而无需等待WAL文件被填充。
默认情况下,流式复制是异步的(请参阅第27.2.8节),在这种情况下,在主系统中提交事务和在备用系统中显示更改之间会有一个小的延迟。然而,这种延迟比基于文件的日志传送要小得多,通常在一秒钟之内,前提是备用设备足够强大,能够跟上负载。通过流式复制,存档超时
不需要减少数据丢失窗口。
如果使用流式复制而不使用基于文件的连续存档,服务器可能会在待机设备收到旧WAL段之前回收它们。如果出现这种情况,则需要从新的基本备份重新初始化备用。可以通过设置wal_keep_尺码
设置一个足够大的值,以确保WAL段不会过早回收,或者通过为备用配置复制插槽。如果您设置了一个可以从备用计算机访问的WAL存档,则不需要这些解决方案,因为备用计算机只要保留足够的数据段,就可以随时使用该存档进行追赶。
要使用流式复制,请设置基于文件的日志传送备用服务器,如中所述第27.2节。将基于文件的日志传送备用转换为流式复制备用的步骤是设置主要信息
设置为指向主服务器。设置听_地址和身份验证选项(请参见pg_hba。形态
)在主服务器上,以便备用服务器可以连接到复制
主服务器上的伪数据库(请参阅第27.2.5.1节).
在支持keepalive套接字选项的系统上,设置tcp_keepalives_闲置的, tcp_keepalives_间隔和tcp_keepalives_计数帮助主服务器及时发现断开的连接。
设置备用服务器的最大并发连接数(请参阅最大值_沃尔_寄件人详细信息)。
当待机启动时主要信息
如果设置正确,则在重放存档中所有可用的WAL文件后,备用设备将连接到主设备。如果成功建立连接,您将看到沃尔接收机
在待机状态下,以及相应的沃尔森德
初级阶段的过程。
# 27.2.5.1.认证
设置复制的访问权限非常重要,这样只有受信任的用户才能读取WAL流,因为很容易从其中提取特权信息。备用服务器必须作为具有复制
特权或超级用户。建议使用创建一个专用用户帐户复制
和登录
复制权限。虽然复制
特权赋予非常高的权限,它不允许用户修改主系统上的任何数据,而超级用户
特权的确如此。
复制的客户端身份验证由pg_hba。形态
记录指定复制
在*数据库
*领域例如,如果备用设备在主机IP上运行192.168.1.100
复制的帐户名为福
,管理员可以将以下行添加到pg_hba。形态
主服务器上的文件:
# 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.
#
# TYPE DATABASE USER ADDRESS METHOD
host replication foo 192.168.1.100/32 md5
主连接的主机名和端口号、连接用户名和密码在主要的,重要的_康宁。也可以在中设置密码~/.pgpass
备份文件(指定复制
在*数据库
*字段)。例如,如果主服务器在主机IP上运行192.168.1.50
港口城市5432
,复制的帐户名为福
,密码是福帕斯
,管理员可以将以下行添加到postgresql。形态
备用文件:
# 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".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
# 27.2.5.2.监控
流式复制的一个重要运行状况指标是在主服务器中生成但尚未在备用服务器中应用的WAL记录的数量。您可以通过比较主服务器上的当前WAL写入位置和备用服务器接收到的最后一个WAL位置来计算此延迟。这些位置可以使用pg_current_wal_lsn
关于初选和初选pg_last_wal_receive_lsn
分别处于待机状态(参见表9.87和表9.88详细信息)。待机状态下的最后一个WAL接收位置也会显示在WAL接收进程的进程状态中,使用附言
命令(参见第28.1节详细信息)。
您可以通过pg_stat_复制
看法两者之间的巨大差异pg_current_wal_lsn
而且景色很美发送
字段可能表示主服务器负载较重,而发送
和pg_last_wal_receive_lsn
在待机状态下,可能表示网络延迟,或者待机状态处于重负载状态。
在热备用状态下,WAL接收器进程的状态可以通过pg_stat_wal_接收器
看法两者之间的巨大差异pg_last_wal_replay_lsn
而且景色很美发红的
表示接收WAL的速度快于可以重播的速度。
# 27.2.6.复制插槽
复制插槽提供了一种自动化的方法,以确保主服务器在所有备用服务器收到WAL段之前不会删除它们,并且主服务器不会删除可能导致错误的行恢复冲突即使备用电源断开连接。
代替使用复制插槽,可以使用沃尔_保持_大小,或使用档案文件_命令然而,这些方法通常会导致保留的WAL段比所需的多,而复制插槽只保留已知所需的段数。另一方面,复制插槽可以保留如此多的WA段,以至于它们填满了为其分配的空间普格沃尔
; 最大值_狭槽_沃尔_保持_大小限制复制插槽保留的WAL文件的大小。
同样地,热的_备用物品_反馈和真空_推迟_清理_年龄提供保护,防止相关行被真空移除,但前者在未连接备用设备的任何时间段内均不提供保护,后者通常需要设置为高值,以提供足够的保护。复制插槽可以克服这些缺点。
# 27.2.6.1.查询和操作复制插槽
每个复制槽都有一个名称,可以包含小写字母、数字和下划线字符。
现有复制插槽及其状态可以在中看到pg_复制_插槽
看法
可以通过流式复制协议创建和删除插槽(请参阅第53.4节)或者通过SQL函数(参见第9.27.6节).
# 27.2.6.2.配置示例
您可以创建如下复制插槽:
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
slot_name | lsn
### 27.2.7. Cascading Replication
[]()
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.
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.
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.
Cascading replication is currently asynchronous. Synchronous replication (see [Section 27.2.8](warm-standby.html#SYNCHRONOUS-REPLICATION)) settings have no effect on cascading replication at present.
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 `recovery_target_timeline` is set to `'latest'` (the default).
To use cascading replication, set up the cascading standby so that it can accept replication connections (that is, set [max\_wal\_senders](runtime-config-replication.html#GUC-MAX-WAL-SENDERS) and [hot\_standby](runtime-config-replication.html#GUC-HOT-STANDBY), and configure [host-based authentication](auth-pg-hba-conf.html)). You will also need to set `primary_conninfo` in the downstream standby to point to the cascading standby.
### 27.2.8. Synchronous Replication
[]()
PostgreSQL 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.
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 `synchronous_commit` is set to `remote_write`.
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 `pg_receivewal` and `pg_recvlogical` as well as some third-party replication systems and custom programs. Check the respective documentation for details on synchronous replication support.
#### 27.2.8.1. Basic Configuration
Once streaming replication has been configured, configuring synchronous replication requires only one additional configuration step: [synchronous\_standby\_names](runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES) must be set to a non-empty value. `synchronous_commit` must also be set to `on`, but since this is the default value, typically no change is required. (See [Section 20.5.1](runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS) and [Section 20.6.2](runtime-config-replication.html#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. `synchronous_commit` 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.
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 `wal_receiver_status_interval` is set to zero on the standby. In the case that `synchronous_commit` is set to `remote_apply`, 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 `synchronous_standby_names` 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.
Setting `synchronous_commit` to `remote_write` 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 `on` does: the standby could lose the data in the event of an operating system crash, though not a PostgreSQL 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.
Setting `synchronous_commit` to `remote_apply` 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.
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.
#### 27.2.8.2. Multiple Synchronous Standbys
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 `synchronous_standby_names`. This parameter also specifies a list of standby names and the method (`FIRST` and `ANY`) to choose synchronous standbys from the listed ones.
The method `FIRST` 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.
An example of `synchronous_standby_names` for a priority-based multiple synchronous standbys is:
同步_备用_名称='FIRST 2(s1、s2、s3)'
In this example, if four standby servers `s1`, `s2`, `s3` and `s4` are running, the two standbys `s1` and `s2` will be chosen as synchronous standbys because their names appear early in the list of standby names. `s3` is a potential synchronous standby and will take over the role of synchronous standby when either of `s1` or `s2` fails. `s4` is an asynchronous standby since its name is not in the list.
The method `ANY` specifies a quorum-based synchronous replication and makes transaction commits wait until their WAL records are replicated to *at least* the requested number of synchronous standbys in the list.
An example of `synchronous_standby_names` for a quorum-based multiple synchronous standbys is:
同步_备用_名称='任意2(s1、s2、s3)'
In this example, if four standby servers `s1`, `s2`, `s3` and `s4` are running, transaction commits will wait for replies from at least any two standbys of `s1`, `s2` and `s3`. `s4` is an asynchronous standby since its name is not in the list.
The synchronous states of standby servers can be viewed using the `pg_stat_replication` view.
#### 27.2.8.3. Planning for Performance
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.
PostgreSQL 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.
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.
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.
#### 27.2.8.4. Planning for High Availability
`synchronous_standby_names` specifies the number and names of synchronous standbys that transaction commits made when `synchronous_commit` is set to `on`, `remote_apply` or `remote_write` will wait for responses from. Such transaction commits may never be completed if any one of synchronous standbys should crash.
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 `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 `catchup` mode. Once the lag between standby and primary reaches zero for the first time we move to real-time `streaming` 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 `streaming` state. This state can be viewed using the `pg_stat_replication` view.
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.
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 `synchronous_standby_names` (or disable it) and reload the configuration file on the primary server.
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 commands pg\_start\_backup() and pg\_stop\_backup() are run in a session with `synchronous_commit` = `off`, otherwise those requests will wait forever for the standby to appear.
### 27.2.9. Continuous Archiving in Standby
[]()
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 `archive_mode` to `always`, 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 `archive_command` must test if the file being archived exists already, and if the existing file has identical contents. This requires more care in the `archive_command`, 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.
If `archive_mode` is set to `on`, 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 `on` and `always` modes.