标签：同步 PostgreSQL standby sync 后备 复制 pg 服务器

在PG9.6版本时，只能支持基于优先级的同步备库方式。

在PG10及以后版本中，引入了 synchronous_standby_names 这种基于 Quorum的同步复制优选提交的机制。

同步复制支持一个或者更多个同步后备服务器，事务将会等待，直到所有同步后备服务器都确认收到了它们的数据为止。事务必须等待其回复的同步后备的数量由synchronous_standby_names指定。这个参数还指定一个后备服务器名称及方法（FIRST和ANY）的列表来从列出的后备中选取同步后备。

方法FIRST指定一种基于优先的同步复制并且让事务提交等待，直到它们的WAL记录被复制到基于优先级选中的所要求数量的同步后备上为止。在列表中出现较早的后备被给予较高的优先级，并且将被考虑为同步后备。其他在这个列表中位置靠后的后备服务器表示可能的同步后备。如果任何当前的同步后备由于任何原因断开连接，它将立刻被下一个最高优先级的后备所替代。

基于优先级的多同步后备的synchronous_standby_names示例1：

synchronous_standby_names = 's1, s2'

在这个例子中，s1是同步备库，s2为潜在同步备库，当s1不可用时，s2升级为同步备库

基于优先级的多同步后备的synchronous_standby_names示例2：

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

在这个例子中，如果有四个后备服务器s1、s2、s3和s4在运行，列表前两个后备服务器s1和s2将被选中为同步后备。

主库提交事务时，必须要等s1和s2都接收并写入WAL日志文件才能返回给客户端成功。

s3是一个潜在的同步后备，当s1或s2中的任何一个失效， 它将升级为同步备库。

s4则是一个异步后备因为它的名字不在列表中。

基于Quorum数量的同步复制 示例：

synchronous_standby_names的基于规定数量的多同步后备的例子：

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

在这个例子中，如果有四台后备服务器s1、s2、s3以及s4正在运行，事务提交将会等待来自s1 s2 s3中至少任意两台后备服务器的回复。

s4是一台异步后备，因为它的名字不在该列表中。

后备服务器的同步状态可以使用pg_stat_replication视图查看。

当一台后备服务器第一次附加到主服务器时，它将处于一种还没有正确同步的状态。这被描述为追赶模式。一旦后备服务器和主服务器之间的迟滞第一次变成零，我们就来到了实时的流式状态。在后备服务器被创建之后的很长一段时间内可能都是追赶模式。如果后备服务器被关闭，则追赶周期将被增加，增加量由后备服务器被关闭的时间长度决定。只有当后备服务器到达流式状态后，它才能成为一台同步后备。这种状态可以使用pg_stat_replication视图查看。

注意：

如果在提交正在等待确认时主服务器重启，那些正在等待的事务将在主数据库恢复时被标记为完全提交。没有办法确认所有后备服务器已经收到了在主服务器崩溃时所有还未处理的 WAL 数据。某些事务可能不会在后备服务器上显示为已提交，即使它们在主服务器上显示为已提交。我们提供的保证是：在 WAL 数据已经被所有后备服务器安全地收到之前，应用将不会收到一个事务成功提交的显式确认。

实验部分：

一主两备的流复制实验（集群使用patroni搭建,它会自动构建同步复制节点）：

postgres=# select pid,usename,application_name,client_addr,state,sync_state,sync_priority from pg_stat_replication ;

  pid  |  usename   | application_name |  client_addr  |   state   | sync_state | sync_priority

-------+------------+------------------+---------------+-----------+------------+---------------

 58691 | replicator | pg_node3         | 192.168.2.189 | streaming | sync       |             1

 58712 | replicator | pg_node2         | 192.168.2.188 | streaming | potential  |             1

(2 rows)

说明：

sync       表示同步库

potential  表示潜在同步库

在 patroni 构建的PG流复制集群中，我的配置是已经开启了基于优先级多备库的方式。 因此我们可以任意关闭1个standby节点，但是如果我们关闭全部的standby节点后，会造成主节点的修改阻塞。

下面是我自建的基于Quorum的同步备库演示贴图（因为我在patroni里面没找到哪里配的支持Quorum。。。暂时也懒得找了）：

修改 postgresql.conf 的如下内容：

synchronous_standby_names = 'ANY 2 (pg_node2,pg_node3)'

然后重载pg的配置文件：

pg_ctl reload  

然后在主库查询配置是否生效：

postgres=# show synchronous_standby_names ;

 synchronous_standby_names

---------------------------

 ANY 2 (pg_node2, pg_node3)

(1 row)

这时候，在主库查看到的如下：

postgres=# select pid,usename,application_name,client_addr,state,sync_state,sync_priority from pg_stat_replication ;

  pid  |  usename   | application_name |  client_addr  |   state   | sync_state | sync_priority

-------+------------+------------------+---------------+-----------+------------+---------------

 65373 | replicator | pg_node3         | 192.168.2.189 | streaming | quorum     |             1

 65375 | replicator | pg_node2         | 192.168.2.188 | streaming | quorum     |             1

(2 rows)

图上可以看出，2个standby节点的sync_state都是 quorum的，并且 sync_priority 优先级都是1 (基于Quorum的同步备库 sync_prioriy的值对备库无影响，可忽略)

接着关闭一个同步备库 pg_node2 ，这时候我们去主库插入数据，可看到被阻塞了。

标签：同步,PostgreSQL,standby,sync,后备,复制,pg,服务器
来源： https://blog.51cto.com/lee90/2443944

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。