PostgreSQL主从流复制原理及搭建

Postgresql9开始支持流复制（stream replication），作为pg原生的复制技术，有着很好的性能。本文从几个方面全面介绍pg的流复制技术。

主从部署

Postgresql主从部署比较简单，首先你需要安装好主从两个实例，然后进行主备库配置，主要配置可以参考如下步骤：

主库配置：
①创建角色用于同步：
create role replica login replication encrypted password 'replica';
②增加pg_hba配置：
host     all     all     192.168.1.2/32    trust
host	 replication	replica		192.168.1.2/32(从库ip)	md5
③配置postgresql.conf
listen_addresses='*'
archive_mode = on
archive_command = 'test ! -f /postgresarch/%f && cp %p /postgresarch/%f'
synchronous_standby_names='FIRST 1 (s1,s2,s3)'
max_connections从库要大于主库
④重启服务器。

从库配置：
①基础备份：
删除从库data目录
pg_basebackup -h 192.168.1.1 -U replica -D /postgresdata/pginst1/ -X stream -P
②配置从库数据目录recovery.conf
standby_mode = 'on'
primary_conninfo = 'host=192.168.1.1 port=5432 user=replica password=replica application_name=s1'
recovery_target_timeline = 'latest'

同步流程

下面这个图描述了postgresql主从流复制的流程。

主要分为以下几个流程：
①主备数据库启动，备库启动walreceiver进程，wal进程向主库发送连接请求。
②主库收到连接请求后启动walsender进程，并与walreceiver进程建立tcp连接。
③备库walreceiver进程发送最新的wal lsn给主库。
④主库进行lsn对比，定期向备库发送心跳信息来确认备库可用性，并且将没有传递的wal日志进行发送，同时调用SyncRepWaitForLSN()函数来获取锁存器，并且等待备库响应，锁存器的释放时机和主备同步模式的选择有关，同步模式这块内容下面再说。
④备库调用操作系统write()函数将wal写入缓存，然后调用操作系统fsync()函数将wal刷新到磁盘，然后进行wal回放。同时备库向主库返回ack信息，ack信息中包含write_lsn、flush_lsn、replay_lsn，这些信息会发送给主库，用以告知主库当前wal日志在备库的应用位置及状态，相关位置信息可以通过pg_stat_replication视图查看。
⑤如果启用了hot_standby_feedback参数，备库会定期向主库发送xmin信息，用以保证主库不会vacuum掉备库需要的元组信息。关于该参数的详细解释，可以参考我的上一篇文章。

同步模式

Postgresql数据库提供了五种同步模式，相比商业数据库还是很强大的。同步模式主要由synchronous_commit参数控制。下面简单介绍一下五种同步模式的区别。下面这张图很清晰地描述了流复制的几种模式：

off：对于本机wal不用写到磁盘就可以提交，是异步模式，存在数据丢失风险。
local：不管有没有备库只需要保证本机的wal日志刷到磁盘就行。
remote_write：等待主库日志刷新到磁盘，同时日志传递到备库的操作系统缓存中，不需要刷盘就能提交，不能避免操作系统崩溃。
on：如果没有备库，表示wal日志需要刷新到本地的磁盘中才能提交，如果存在同步备库时（synchronous_standby_name不为空），需要等待远程备库也刷新到磁盘主库才能提交。
remote_apply：pg高版本才出来的功能，备库刷盘并且回放成功，事务被标记为可见，用于做负载均衡，读写分离等。

相关参数

wal_level:
wal日志级别，这个参数决定了有多少信息写入wal日志，默认是replica，这种模式支持复制和wal归档，同时支持备库只读查询。
minimal：除了实例crash恢复需要的记录，其他不记录，比如CREATE TABLE AS，CREATE INDEX，CLUSTER，COPY可以跳过，该模式记录的日志信息不足以支持wal归档和流复制。
logic：在replica的基础上增加一些信息以支持逻辑解码，该模式会增大wal日志的数量，尤其是大量的update，delete操作的库。
在9.6之前还有archive和hot_standby模式，映射到现在的replica模式。

synchronous_commit：
五种同步模式选择，前面已经说过。关于生产环境配置我也做过测试，如果单并发插入remote_write和on性能差距十倍，但是高并发的情况下，差距不大，所以刷盘其实是比较消耗性能的操作，生产环境中建议选用remote_write。

synchronous_standby_names：
在主库上配置，备机的复制列表。有下面几种种方式（s1，s2，s3代表备机的application_name，配置在recovery.conf中）：
synchronous_standby_names=‘s1’ 代表s1备机返回就可以提交。
synchronous_standby_names=‘FIRST 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中前两个s1和s2返回主库就可以提交。
synchronous_standby_names=‘ANY 2 (s1,s2,s3)’ 代表s1，s2，s3三个备机中任意两个备机返回主库就可以提交，基于quorum协议。
synchronous_standby_names=’*’ *代表匹配任意主机，也就是任意主机返回就可以提交。

vacuum_defer_cleanup_age:
指定vacuum延迟清理的事务数，即vacuum和vacuum full操作不会立即清理刚刚被删除元组。至于为什么要延迟清理，我的上一篇文章有讲到。

max_wal_senders:
指定wal日志发送进程的最大并发连接数。设为0表示禁用replication，参数必须小于max_connections-superuser_reserved_connections

checkpoint_segments(9.5之前):
自动wal checkpoint间隔时间段内最多产生的wal数量。9.5之前才有这个参数，9.5后废除了这个参数，新增了max_wal_size，改为通过max_wal_size和checkpoint_completion_target共同控制，计算公式为：checkpoint_segments=max_wal_size/(2+checkpoint_completion_target)，所以checkpoint_segments大概为wal_max_size的1/3到1/2。

wal_keep_segments:
设置“pg_xlog”目录下保留事务日志文件的最小数目用于流复制，如果备机停机时间过长导致主库xlog被删除，那么主备关系会失败，但是如果开启了归档，备机可以从归档日志中继续恢复。

min_wal_size:
只要wal日志目录使用空间小于该值，那么旧的wal日志就会循环使用而不是进行删除。这个参数是为了确保足够的wal空间预留给突发情况，比如大的跑批操作。

max_standby_archive_delay、max_standby_streaming_delay、hot_standby_feedback：
控制备机查询冲突的参数，上一篇文章说过，这里不再赘述。

wal_receiver_status_interval：
备机向主机发送相关复制信息的最小频率，包含相关lsn信息，可以通过pg_stat_replication视图查看。

wal_recevier_timeout、wal_recevier_retry_interval：
控制连接超时时间，很好理解，不再赘述。

我们可以通过pg_stat_replication，pg_stat_wal_receiver，pg_current_wal_lsn，pg_last_wal_receive_lsn这几个视图查看复制的状态信息。

总体来说流复制的内容比较简单，本文只是从基础知识层面介绍了流复制的原理与简单配置。

技术永无止境，加油吧。

欢迎关注我的公众号：数据库架构之美