一文弄懂PostgreSQL流复制

  • 2019 年 12 月 18 日
  • 笔记

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这几个视图查看复制的状态信息。

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