PostgreSQL 从库 standby 为何要切断你的“需求”

以上问题是群里面一个“数”友的问题

首先要说的是，这个“数”友的问题是，他们公司使用的是SQL SERVER 由于各种不满（此处省略N多文字），然后他们要换数据库，如果换成PG会如何，他们在从库会有很多的复杂查询的问题。所以才有了这篇文字。

首先要说的PG 是物理复制，所以延迟的问题，只要你基础工作做的好，（网络，硬件环境）延迟的问题和MYSQL的延迟的问题，文字都叫延迟，但实际上不在一个LEVEL。

担心的是另外的一件事情，就是standby 主机是否会在他在从库进行复杂查询的时候，将他的任务终止。要说这个问题还的从 “上上有座庙，庙里的和尚说起”

Hot Standby 是一个参数，是PG里面带有的一个针对复制的参数：

在服务器处于存档恢复或备用模式时连接到服务器并运行只读查询的能力。这对于复制和精确地将备份恢复到所需状态都很有用。术语Hot Standby还指在用户继续运行查询和/或保持连接打开时，服务器从恢复到正常运行的能力。当备用服务器上的hot_standby参数设置为true时，恢复使系统处于一致状态时，它将开始接受连接。所有这些连接都是严格只读的甚至不能编写临时表。

在弄清楚HOT STANDBY这个参数后，我们假定这位同学的公司的PG 是需要打开这个参数的，因为要高可用，因为要对于上面深色的文字有一个保障。 以上为这位同学的需求，可能还有他没有提到或想到的。但我们到此为止。

问题 1 ，希望这位同学的公司的要求，从库查询不是数据强一致

备用服务器上的数据需要一些时间才能从主服务器到达，因此在主服务器和备用服务器之间存在可测量的延迟。因此，几乎同时在主服务器和备用服务器上运行相同的查询可能会返回不同的结果。我们说备用系统上的数据最终与主系统一致。事务的提交记录在备用服务器上重播后，该事务所做的更改将对备用服务器上的任何新快照可见。

问题 2 ， 这也是我想提醒这位同学的一个关键的问题，就是你的从库执行的查询可能在某些因素下被牺牲

1 热更新或与真空相关的更新将删除查询期望可见的内容 2 出现b树删除 3 正在运行的查询与要处理更新所需的锁之间存在锁定问题

用人话来说的意思就是 1 你查询的时候，人家主库那边将你正在查询的内容清除了，你的查询就终止了 2 索引清除了，你的查询就终止了 3 你的查询的内容，人家正在UPDATE 产生锁的问题 （这个是数据库中常见的问题）

所以，在不是很清晰他的需求的状态下，如果他不能满足他的应用的基础（因为SQL SERVER的从库是不会有这个问题），以致他的开发团队对他的选择产生质疑，这就不好了，所以任何事情要讲前提，不要说，那个数据库好，那个数据库都很好，只是你的需求适不适合他。

最后要说的是 锁的情况很难处理，但是如果您只是在备用服务器上运行只读查询，那么在实践中不太可能发生这种情况，因为这些查询将通过MVCC隔离。另外两个并不难遇到。需要理解的基本内容是，主服务器上的任何更新或删除都可能导致备用服务器上的任何查询中断;即使更改与查询正在执行的操作相关，也没有关系。

那问题是，怎么办，任何问题都有妥协的方法

1 调整max_standby_delay 这个参数，对较长的查询进行优化，但代价是保持恢复为当前状态。一旦出现将导致问题(热、真空、B-tree删除等)的更新，将延迟应用到备用服务器。

当然看似是解决了问题，但你如果纵容长查询的无度，则你面临的就是两边数据的差异化和磁盘空间的损失，所以PG 的磁盘空间没有最大，只有更大，磁盘的容量给足，别吝啬。

2 严格的控制你主库的某些可能造成长时间的事务操作，也会环节你上述的一些问题。

任何的一种数据库的选择都代表，你要忠诚与它的最初的设计初衷，违背他的设计，而强行按自己的来，那他必然还以颜色给它的“主人”。