POSTGRESQL 建立主从节点全流程 与 要不要强一致的问题

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（接近700人左右 1 + 2）。

POSTGRESQL 的物理复制本身成为streaming replication ,流复制，这是POSTGRESQL 数据库进行高可用的一个基础，所以如何搭建POSTGRESQL streaming replicaiton 和 期中的原理是一个DBA 进行POSTGRESQL 相关运行维护中的必要功课。基于最近不少人在问这个问题，所以写了这篇相关的文字。

流复制允许备用服务器保持比基于文件的日志传送更最新的状态。备用服务器连接到主服务器，主服务器在生成WAL记录时将它们传输到备用服务器，而不需要等待WAL文件被填充。

当启动POSTGRESQL的 standby服务器并且primary_conninfo设置正确时，备用服务器将在所有可用的WAL文件后连接到主服务器。如果连接成功建立，您将在备用服务器中看到一个walreceiver进程，在主服务器中看到一个相应的walsender进程。

POSTGRESQL 主库中的walsender

POSTGRESQL 从库中的 walreceiver 

在使用复制中，还有一个问题是关于在使用流复制中是否使用复制槽的问题，复制槽的使用会保留接收方没有接收到的wal日志，但如果从库失效的情况下，wal会填满整个主库的pg_wal分配的空间突破max_slot_wal_keep_size限制。这对于主库的运行安全来说是一个非常重要的风险。

那么流复制/物理复制中的一些特点我们需要了解

1   数据的主节点和从节点之间的一致性，一致性包含了，最终一致性和瞬时一致性，或者说异步复制和同步复制两种模式。

2   性能的损耗，在进行数据的复制的过程中，根据你选择的复制的方式，整体的数据库在处理事务的过程中，都会包含性能的损耗，以及资源的消耗

3   复制中的一些诸如，数据库的版本的问题，数据库的信息复制延迟的问题，数据复制中的中断的问题等等

复制中的具体的工作：

1  确认数据库之间的网络是通讯的，基本应该是在一个网段内部进行

2  主库的pg_hba.conf 的复制设置的是正确的

3  主库具有复制的账号

4  数据库中的配置参数是正确的

1 建立一个复制通讯的账号

create user qy_replic with login Replication password '1234.com';

2 在pg_hba.conf 中建立对应的复制列表

3  创建相关的复制槽

4  在从库中建立数据的主库复制镜像

pg_basebackup --pgdata /pgdata/data --format=p  --write-recovery-conf --checkpoint=fast --label=qy_replica -P -Xs -R  --host=192.168.198.100 --port=5432 --username=qy_replic

5  从库开机后，开始进行连接数据复制基本就建立成功了。

在主库查看复制的情况

那么这就算建立完毕一个完整的复制了吗？我们根据如下的一些问题，来完善相关的流复制的知识。

很多同学提出了如下的问题

1  是否可以在建立异步的复制中，我们想转换成强一致复制的复制方式，也就是 sync_state 转换为 sync的方式。  回答是可以的

以PG14 为例，我们需要针对以下的一些参数进行变换。我们需要做一下的一些工作。顺便回顾一下，前几天群里一个同学的提问，关于为什么他的从库在开启的一致性的情况下，还是有主库COMMIT 事务后，从库没有查询到数据的情况。

这里我们首先需要理解一个参数 synchronous_commit ，这个参数有5个值，OFF , LOCAL ,ON , Remote_write, remote_apply 

OFF 的意思为，不进行任何的等待，事务的commit后可以不确认刷新到磁盘的这个动作。此时这个设置是一个高性能的设置如果你对数据库本身所在的业务有较高的性能你需求，但是你对业务的安全性要求不高的情况下，那么你可以设置为OFF ，虽然我们不推荐你这样。

LOCAL 的意思是事务必须在本地库中落盘后，才能进行事务的commit 后，这是一个单机应该进行配置的并保证数据库安全的一个必选项

ON 的意思在设置了 synchronous_standby_names的情况下，从库需要将事务的记录安全写到磁盘上为止结束

remote_write  的意思是主库COMMIT将等待synchronous_standby_names指定的服务器确认将事务记录写入操作系统

remote_replay 的意思是主库COMMIT将等待，直到synchronous_standby_names指定的服务器确认事务记录已应用到副本的数据库。

所以我们的核心让一个从库变为强一直，

1 synchronous_commit  = on 

2 synchronous_standby_names = *

第一个参数是在主库上进行配置，而第二个部分需要在从库配置自己的cluster_name ,在主库的synchronous_standby_names 写入对应的名字即可将你的异步复制变为同步复制。如果不写名字则可以使用 * 来代表所有的从库均要进行强一致同步。

select * from pg_stat_wal_receiver ;

并且在切换的过程中，是不需要进行重启的，只需要加载信号源即可 .

问题2 在读写分离中是否我应该使用，强一致的方式进行接触的架构设计？

这个问题是上礼拜有一个同学提出的，并且遇到了问题，首先从架构设计的角度，目前支持这样功能的数据库不是太多，并且支持这样强一致的数据库产品也是灵活的，比如MONGODB 可以在一个 INSERT  UPDATE 的语句上加入这个强一致的选项。

但如果我们在我们的核心应用中使用POSTGRESQL 的主从复制的强一致的架构的情况下，会遇到如下问题

1  从库故障，导致整体的应用无法在一段时间内使用，或彻底无法使用的问题，这主要依赖与两个点 PG 的主从的一致的参数设计和应用针对从库失效后的FAIL OVER 的调整。

2  数据库成为架构中容易出现故障问题的制造者，在系统运行中从库的性能会直接影响到整体应用的运行，如从库在进行大量的OLAP的操作影响性能导致主库的事务COMMIT 的效率降低，最终在整体影响应用系统的性能。

3  应用程序设计人员的耻辱，因为一个具有良好架构师和程序人员的情况下，这样蹩脚的数据库架构选型是在是不大可能，所以采用了一个看似可以解决问题的方案，来蹩脚的解决问题。

正确的姿势是，将必须及时进行读取的事务进行封装，只在主库操作，而如果是非即时性的查询，去从库查询，并做好从库查询慢SQL 和长时间无法终结的SQL的监控，必要时进行查杀。

问题 3  经常遇到从库查询中被莫名KILL的情况？

提出这个问题的同学应该还有另一个问题就是莫名的情况下主库操作有卡顿的情况，或者wal 有时候增加无法消减的问题。为什么会产生这样的情况，主要是在从库进行数据查询的情况下，尤其是大SQL的长时间的查询，会导致主库传送来的DML操作等无法在从库进行重放，而在这样的情况下就会产生上述的一些问题

遇到这个问题，可以尝试来设置这个参数来解决问题max_standby_streaming_delay  ,这个参数本身是是针对主库的WAL日志在从库最大等待的应用时间是多少，默认是30秒，也就是如果你从库的查询与主库的WAL日志落库前产生冲突最大可以容忍的时间，这不是你从库最大的可以承受的查询时间，有些理解上的差异就是这么来的，举例有人提出，为什么我一开始的查询运行了29秒就被kill了，但是后面的查询越来越短的被KILL 有的5秒就被KILL 了，不是说30秒吗？

这里再次重申，这个参数的意义是WAL日志在从库落盘最大等待的时间，所以如果之前你阻碍了WAL日志的落盘，那么后面就会导致后面日志落盘的延迟时间越来越短，也就是你的SQL 越来越快的被KILL掉的原因。这里通过 pg_stat_database_conflicts 来去查看备库中当前的数据库在应用wal 日志是否有产生冲突的情况。