# 27.4.热备用

27.4.1. 用户概述

27.4.2. 处理查询冲突

27.4.3. 管理员概述

27.4.4. 热备用参数参考

27.4.5. 警告

热备份是一个术语,用于描述在服务器处于存档恢复或待机模式时连接到服务器并运行只读查询的能力。这对于复制和将备份精确地恢复到所需状态都很有用。术语“热备用”还指在用户继续运行查询和/或保持连接打开的情况下,服务器从恢复到正常运行的能力。

在热备用模式下运行查询类似于正常的查询操作,不过下面解释了几种用法和管理差异。

# 27.4.1.用户概述

热的_备用物品参数在备用服务器上设置为true时,一旦恢复使系统处于一致状态,它将开始接受连接。所有这些连接都是严格只读的;甚至连临时表格都不能写。

备用服务器上的数据需要一段时间才能从主服务器到达,因此主服务器和备用服务器之间会有可测量的延迟。因此,在主查询和备用查询上几乎同时运行同一查询可能会返回不同的结果。我们说备用设备上的数据是最终一致初选的时候。一旦事务的提交记录在待机状态下重播,该事务所做的更改将对在待机状态下拍摄的任何新快照可见。快照可以在每个查询的开始或每个事务的开始时拍摄,具体取决于当前的事务隔离级别。有关更多详细信息,请参阅第13.2节.

在热备用期间启动的事务可能会发出以下命令:

  • 查询访问:选择,抄送

  • 光标命令:声明,取来,

  • 设置:显示, 设置, 重置

  • 事务管理命令:

    • 开始, 终止, 中止, 开始交易

    • 保存点, 释放, 回滚到保存点

    • 例外块和其他内部子事务

  • 锁桌,但仅当明确处于以下模式之一时:访问共享, 行共享排他.

  • 计划和资源:准备, 处决, 解除分配, 丢弃

  • 插件和扩展:负载

  • 不听

    在热备用期间启动的事务将永远不会被分配事务ID,并且无法写入系统预写日志。因此,以下操作将产生错误消息:

  • 数据操作语言(DML):插入, 使现代化, 删去, 抄袭, 截断。请注意,在恢复过程中,不允许执行导致执行触发器的操作。这一限制甚至适用于临时表,因为在不分配事务ID的情况下无法读取或写入表行,这在热备用环境中目前是不可能的。

  • 数据定义语言(DDL):创造, , 改变, 议论。此限制甚至适用于临时表,因为执行这些操作需要更新系统目录表。

  • 选择分享|更新,因为在不更新基础数据文件的情况下无法获取行锁。

  • 规定选择生成DML命令的语句。

  • 它明确要求一个高于行独占模式.

  • 简而言之,默认形式,因为它要求访问独占模式.

  • 显式设置非只读状态的事务管理命令:

    • 开始读写, 启动事务读写

    • 设置事务读写, 将会话特征设置为事务读写

    • 将事务设置为只读=关闭

  • 两阶段提交命令:准备交易, 做好准备, 准备回滚因为即使是只读事务也需要在准备阶段(两阶段提交的第一阶段)写入WAL。

  • 序列更新:nextval(), setval()

  • , 通知

    在正常操作中,允许使用“只读”事务通知,因此热备用会话的操作限制比普通只读会话稍微严格。在未来的版本中,可能会放宽其中一些限制。

    在热备用期间,参数事务_只读永远是真实的,不可能改变。但是,只要不尝试修改数据库,热备用期间的连接将与任何其他数据库连接一样。如果发生故障转移或切换,数据库将切换到正常处理模式。服务器更改模式时,会话将保持连接。一旦热备用完成,就可以启动读写事务(即使是从热备用期间开始的会话)。

    用户可以通过发出在待机状态下显示(在14之前的服务器版本中处于待机状态参数不存在;为旧服务器提供了一种可行的替代方法仅显示事务\u只读\u)此外,还有一组函数(表9.88)允许用户访问有关备用服务器的信息。这些允许您编写了解数据库当前状态的程序。它们可以用来监视恢复的进度,或者让您编写复杂的程序,将数据库恢复到特定状态。

# 27.4.2.处理查询冲突

主服务器和备用服务器在许多方面是松散连接的。主设备上的操作将对备用设备产生影响。因此,它们之间可能存在负面互动或冲突。最容易理解的冲突是性能:如果主服务器上发生了巨大的数据负载,那么这将在备用服务器上生成类似的WAL记录流,因此备用查询可能会争夺系统资源,例如I/O。

热备用还可能发生其他类型的冲突。这些冲突是激烈的冲突从某种意义上说,可能需要取消查询,在某些情况下,需要断开会话来解决这些问题。为用户提供了几种处理这些冲突的方法。冲突案例包括:

  • 访问主服务器上的独占锁,包括命令和各种DDL操作与备用查询中的表访问冲突。

  • 在主服务器上删除表空间与将该表空间用于临时工作文件的备用查询相冲突。

  • 在主服务器上删除数据库与在备用服务器上连接到该数据库的会话冲突。

  • WAL中真空清理记录的应用与备用事务冲突,备用事务的快照仍然可以“看到”任何要删除的行。

  • 从WAL应用真空清理记录与访问待机状态下目标页面的查询冲突,无论要删除的数据是否可见。

    在主服务器上,这些情况只会导致等待;用户可能会选择取消任何一个冲突操作。但是,在备用设备上没有选择:WAL记录的操作已经在主设备上发生,因此备用设备不能不应用它。此外,允许WAL应用程序无限期等待可能是非常不可取的,因为备用状态将越来越落后于主状态。因此,提供了一种机制来强制取消与待应用WAL记录冲突的备用查询。

    问题情况的一个例子是主服务器上正在运行的管理员升降台在备用服务器上当前正在查询的表上。显然,如果升降台在待机状态下应用。如果这种情况发生在主服务器上,则升降台将等待另一个查询完成。但是什么时候升降台在主服务器上运行时,主服务器没有关于在备用服务器上运行的查询的信息,因此它不会等待任何此类备用查询。当备用查询仍在运行时,WAL更改记录会传递到备用查询,从而导致冲突。备用服务器必须延迟WAL记录的应用(以及它们之后的所有内容),或者取消冲突查询,以便升降台可以应用。

    当一个冲突的查询很短时,通常希望通过稍微延迟WAL应用程序来完成它;但长期延迟申请通常是不可取的。所以取消机制有参数,最大值_备用物品_档案文件_延迟最大值_备用物品_流动_延迟,这定义了WAL应用程序中允许的最大延迟。冲突查询将在应用新接收的WAL数据所需的时间超过相关延迟设置后取消。有两个参数,以便在从存档读取WAL数据(即从基本备份中初始恢复或“追赶”落后于其他备用服务器)的情况下,可以指定不同的延迟值,而不是通过流复制读取WAL数据。

    在主要为高可用性而存在的备用服务器中,最好设置相对较短的延迟参数,这样服务器就不会因为备用查询造成的延迟而落后于主服务器。然而,如果备用服务器是用于执行长时间运行的查询,那么高或甚至无限延迟值可能更可取。但是,请记住,如果长期运行的查询延迟了WAL记录的应用,则可能会导致备用服务器上的其他会话在主服务器上看不到最近的更改。

    一旦延迟指定为最大\u待机\u存档\u延迟最大\u待机\u流式\u延迟已超过,将取消冲突的查询。这通常只会导致取消错误,尽管在重放时删除数据库整个冲突会话将终止。此外,如果冲突是在空闲事务所持有的锁之上,则冲突会话将终止(这种行为可能在将来发生变化)。

    取消的查询可以立即重试(当然,在开始新事务之后)。由于查询取消取决于正在重放的WAL记录的性质,因此如果再次执行已取消的查询很可能成功。

    请记住,延迟参数与备用服务器接收WAL数据以来经过的时间进行比较。因此,允许在待机状态下的任何一个查询的宽限期永远不超过延迟参数,并且如果由于等待以前的查询完成或无法跟上沉重的更新负载,待机已经落后,则可能会大大减少。

    备用查询与WAL重播冲突的最常见原因是“早期清理”。通常,PostgreSQL允许在没有需要查看它们的事务时清理旧行版本,以确保根据MVCC规则正确地显示数据。但是,此规则只能应用于在主服务器上执行的事务。因此,主服务器上的清理可能会删除对备用事务仍然可见的行版本。

    有经验的用户应该注意,行版本清理和行版本冻结都可能与备用查询冲突。运行手册真空冷冻即使在没有更新或删除行的表上,也可能导致冲突。

    用户应该清楚,主服务器上定期大量更新的表将很快导致在备用服务器上取消运行时间较长的查询。在这种情况下,为最大待机时间存档时间延迟最大待机时间流延迟可以认为与设置类似语句超时.

    如果发现备用查询取消次数不可接受,则存在补救可能性。第一个选项是设置参数热备份反馈,防止真空删除最近死掉的行,这样就不会发生清理冲突。如果这样做,您应该注意,这将延迟清理主服务器上的死行,这可能会导致不希望出现的表膨胀。但是,清理情况不会比直接在主服务器上运行备用查询更糟,而且您仍然可以从将执行卸载到备用服务器上获得好处。如果备用服务器频繁连接和断开连接,您可能需要调整以处理热备份反馈没有提供反馈。例如,考虑增加最大待机时间存档时间延迟这样,在断开连接期间,查询不会因WAL存档文件中的冲突而迅速取消。你也应该考虑增加。最大待机时间流延迟避免重新连接后新到达的流媒体条目快速取消。

    另一个选择是增加真空_推迟_清理_年龄在主服务器上,这样就不会像正常情况下那样快速地清理死行。这将使查询在待机状态下被取消之前有更多的时间执行,而无需设置高值最大待机时间流延迟.然而,这种方法很难保证任何特定的执行时间窗口,因为真空延迟清理以在主服务器上执行的事务来衡量。

    可以使用pg_统计_数据库_冲突备用服务器上的系统视图。这个pg_统计数据库系统视图还包含摘要信息。

    用户可以控制当WAL replay等待的时间超过死锁超时因为冲突。这是由日志_恢复_冲突_等待参数

# 27.4.3.管理员概述

如果热备用在…上在里面postgresql。形态(默认值)并且有一个备用物品信号文件存在时,服务器将以热备用模式运行。但是,允许热备用连接可能需要一些时间,因为服务器在完成足够的恢复以提供一致的状态以运行查询之前,不会接受连接。在此期间,尝试连接的客户端将被拒绝并显示错误消息。要确认服务器已启动,请尝试从应用程序进行连接,或在服务器日志中查找以下消息:

LOG:  entering standby mode

... then some time later ...

LOG:  consistent recovery state reached
LOG:  database system is ready to accept read-only connections

一致性信息在主服务器上的每个检查点记录一次。在以下时间段读取或写入WAL时,不可能启用热备用:瓦卢层没有设置为复制品必然的初选的时候。在以下两种情况下,也可能延迟达到一致状态:

  • 一个写事务有超过64个子事务

  • 非常长寿命的写事务

    如果您正在运行基于文件的日志传送(“热备份”),则可能需要等到下一个WAL文件到达,这可能与存档超时设定初选。

    一些参数的设置决定了用于跟踪事务ID、锁和准备好的事务的共享内存的大小。这些共享内存结构在备用设备上不得小于主设备上,以确保备用设备在恢复期间不会耗尽共享内存。例如,如果主设备使用了准备好的事务,但备用设备没有分配任何共享内存来跟踪准备好的事务,那么在备用设备的配置更改之前,恢复无法继续。受影响的参数包括:

  • max_连接

  • max_准备的_事务

  • 每个事务的最大锁数

  • max_wal_senders

  • max_worker_进程

    确保这不会成为问题的最简单方法是将备用设备上的这些参数设置为等于或大于主设备上的值。因此,如果要增加这些值,应该先在所有备用服务器上增加,然后再将更改应用到主服务器。相反,如果要减小这些值,则应先在主服务器上进行,然后再将更改应用于所有备用服务器。请记住,当提升备用时,它将成为后续备用所需参数设置的新参考。因此,为了避免在切换或故障切换期间出现问题,建议在所有备用服务器上保持这些设置不变。

    WAL跟踪主屏幕上这些参数的更改。如果热备用处理的WAL指示主设备上的当前值高于其自身值,它将记录警告并暂停恢复,例如:

WARNING:  hot standby is not possible because of insufficient parameter settings
DETAIL:  max_connections = 80 is a lower setting than on the primary server, where its value was 100.
LOG:  recovery has paused
DETAIL:  If recovery is unpaused, the server will shut down.
HINT:  You can then restart the server after making the necessary configuration changes.

此时,需要更新待机状态下的设置,并重启实例,然后才能继续恢复。如果备用不是热备用,那么当它遇到不兼容的参数更改时,它将立即关闭而不暂停,因为保持它没有任何价值。

重要的是,管理员要为其选择适当的设置最大值_备用物品_档案文件_延迟最大值_备用物品_流动_延迟.最佳选择因业务优先级而异。例如,如果服务器的主要任务是作为高可用性服务器,那么您将需要低延迟设置,甚至可能是零,尽管这是一个非常激进的设置。如果备用服务器被指定为决策支持查询的附加服务器,那么可以将最大延迟值设置为多小时,甚至-1,这意味着永远等待查询完成。

写入主设备上的事务状态“提示位”不会被记录,因此备用设备上的数据可能会在备用设备上再次写入提示。因此,即使所有用户都是只读的,备用服务器仍将执行磁盘写入;数据值本身不会发生任何更改。用户仍然会编写大型排序临时文件,并重新生成relcache info文件,因此在热备用模式下,数据库的任何部分都不是真正的只读。还请注意,即使事务在本地是只读的,也可以使用dblink模块写入远程数据库,以及使用PL函数在数据库之外执行其他操作。

恢复模式下不接受以下类型的管理命令:

  • 数据定义语言(DDL):例如。,创建索引

  • 特权和所有权:授予, 撤销, 重新分配

  • 维护命令:分析, 真空, , 重新索引

    再次请注意,在主服务器上的“只读”模式事务期间,实际上允许使用其中一些命令。

    因此,您无法创建仅存在于备用计算机上的其他索引,也无法创建仅存在于备用计算机上的统计信息。如果需要这些管理命令,它们应该在主服务器上执行,最终这些更改将传播到备用服务器。

pg_取消_后端()pg_终止_后端()将用于用户后端,但不用于执行恢复的启动过程。pg_统计活动不将恢复事务显示为活动。因此准备好的在恢复过程中总是空的。如果您希望解决有疑问的准备交易,请查看准备好的在主服务器上,并发出命令,在主服务器上解决事务,或在恢复结束后解决事务。

pg_锁将显示由后端持有的锁,正常情况下。pg_锁还显示了一个由启动进程管理的虚拟事务,它拥有所有独家配饰由恢复重放的交易持有。请注意,启动过程不会获取用于更改数据库的锁,因此不会获取其他锁独家配饰不要出现在pg_锁用于启动过程;他们只是被假定存在。

Nagios插件检查_pgsql将起作用,因为它检查的简单信息是存在的。支票_postgres监控脚本也可以工作,尽管一些报告的值可能会给出不同或令人困惑的结果。例如,上次真空时间将不会保持,因为待机状态下不会出现真空。主设备上运行的真空系统仍然会将其更改发送到备用设备。

WAL文件控制命令在恢复期间不起作用,例如。,pg_启动_备份, pg_开关_墙

可动态加载的模块可以工作,包括pg_stat_语句.

建议锁在恢复中正常工作,包括死锁检测。请注意,通知锁从未被WAL记录,因此主服务器或备用服务器上的通知锁不可能与WAL replay冲突。也不可能在主设备上获得咨询锁,并让其在备用设备上启动类似的咨询锁。建议锁仅与获取它们的服务器相关。

基于触发器的复制系统(如Slony、Londiste和Bucardo)根本不会在备用服务器上运行,不过只要不将更改发送到备用服务器应用,它们就可以在主服务器上愉快地运行。WAL replay不基于触发器,因此您无法从待机状态中继到任何需要额外数据库写入或依赖触发器使用的系统。

无法分配新的OID,尽管一些UUID生成器可能仍然可以工作,只要它们不依赖于向数据库写入新状态。

目前,在只读事务期间不允许创建临时表,因此在某些情况下,现有脚本无法正确运行。这一限制可能会在以后的版本中放宽。这既是一个SQL标准遵从性问题,也是一个技术问题。

删除表空间只有在表空间为空时才能成功。一些备用用户可能正在通过他们的临时表空间参数如果表空间中有临时文件,则会取消所有活动查询,以确保删除临时文件,从而可以删除表空间并继续播放。

跑步删除数据库改变数据库。。。设置表空间在主服务器上,将生成一个WAL条目,该条目将导致连接到备用服务器上该数据库的所有用户被强制断开连接。无论设置的是什么,此操作都会立即发生最大待机时间流延迟.注意改变数据库。。。改名不会断开用户连接,这在大多数情况下会被忽略,但在某些情况下,如果它在某种程度上依赖于数据库名称,则可能会导致程序混乱。

在正常(非恢复)模式下,如果删除用户放弃角色对于具有登录功能的角色,当该用户仍处于连接状态时,连接的用户不会发生任何事情-他们仍处于连接状态。但是,用户无法重新连接。这种行为也适用于恢复,因此删除用户在主设备上,不会断开该用户在备用设备上的连接。

统计数据采集器在恢复期间处于活动状态。所有扫描、读取、块、索引使用等都将在待机状态下正常记录。重放的动作不会在主屏幕上复制其效果,因此重放插入不会增加pg的Inserts列_斯达_使用者_桌子。统计文件在恢复开始时被删除,因此主数据和备用数据将有所不同;这被认为是一个特性,而不是一个bug。

自动真空在恢复过程中不处于活动状态。它将在恢复结束时正常启动。

检查点进程和后台写入程序进程在恢复期间处于活动状态。检查点进程将执行重启点(类似于主服务器上的检查点),后台写入程序进程将执行正常的块清理活动。这可能包括更新存储在备用服务器上的提示位信息。这个检查站命令在恢复期间被接受,但它会执行重新启动点而不是新的检查点。

# 27.4.4.热备用参数参考

上文中提到了各种参数第27.4.2节第27.4.3节.

关于主要参数沃尔_数量真空_推迟_清理_年龄可以使用。最大值_备用物品_档案文件_延迟最大值_备用物品_流动_延迟如果在主屏幕上设置,则不起作用。

在待机状态下,参数热的_备用物品, 最大值_备用物品_档案文件_延迟最大值_备用物品_流动_延迟可以使用。真空_推迟_清理_年龄只要服务器仍处于待机模式,则不起作用,但如果待机模式变为主模式,则会变得相关。

# 27.4.5.警告

热备用有几个限制。这些问题可能会在未来的版本中得到解决:

  • 在拍摄快照之前,需要完全了解正在运行的事务。使用大量子事务(当前大于64)的事务将延迟只读连接的启动,直到运行时间最长的写事务完成。如果出现这种情况,将向服务器日志发送解释性消息。

  • 备用查询的有效起始点是在主服务器上的每个检查点生成的。如果在主设备处于关闭状态时关闭备用设备,则在主设备启动之前,可能无法重新进入热备用,以便在WAL日志中生成更多的起始点。这种情况在最常见的可能发生的情况下不是问题。通常,如果主设备关闭且不再可用,这可能是由于严重故障,需要将备用设备转换为新的主设备。在主设备被故意拆除的情况下,协调以确保备用设备顺利成为新的主设备也是标准程序。

  • 在复苏结束时,独家配饰由准备好的事务持有将需要两倍于正常数量的锁表条目。如果您计划运行大量通常需要独家配饰,或者你计划进行一项需要花费很多时间的大型交易独家配饰,建议您选择一个更大的值每个事务的最大锁数,可能是主服务器上参数值的两倍。如果你设置的话,你根本不需要考虑这个问题。max_准备的_事务是0.

  • 可序列化事务隔离级别在热备用中尚不可用。(见第13.2.3节第13.4.1节详细信息。)尝试在热备用模式下将事务设置为可序列化隔离级别将生成错误。