PostgreSQL 高可用数据库的常见搭建方式主要有两种 , 逻辑复制和物理复制 , 上周已经写过了关于在Windows环境搭建PostgreSQL逻辑复制的教程,这周来记录一下 物理复制的搭建方法 。
首先介绍一下逻辑复制和物理复制的一些基本区别:
- 物理复制要求多个实例之间大版本一致,并且操作系统平台一致,如主实例是 Windows环境下的 PostgreSQL15 则 从实例也必须是这个环境和版本,逻辑复制则没有要求 。
- 物理复制是直接传递 WAL归档 文件,在从实例进行重放执行,可以理解为实时的 WAL归档恢复,所以延迟低,性能高 。,
- 逻辑复制可以简单理解为解析了WAL归档文件中的信息,处理成为 标准的SQL语句,传递给存库进行执行,相对于直接传递WAL性能较低 , 延迟高 。
- 物理复制不需要像逻辑复制一些去手动的建立数据库 , 数据表,因为物理复制是直接恢复WAL所以包含了DDL操作,逻辑复制则需要自己进行DDL操作 。
- 逻辑复制更加灵活 , 可以自己指定需要复制的库,从实例,还可以建立其他库用于其他业务,而物理复制则是面向整个实例进行的,从实例和主实例100%一致最多只能进行只读操作 。
如果追求高性能,高一致性的数据库复制备份方案建议采用物理复制的方式 。
搭建物理复制模式的主从订阅首先要调整主实例的 postgresql.conf 文件wal_level = replicasynchronous_commit = remote_apply
文章插图
因为我们采用的 synchronous_commit = remote_apply 是同步复制的模式,该模式可以理解为同步复制,当客户端像主实例提交事务之后 , 需要等 synchronous_standby_names 总配置的节点全部完成 remote_apply 收到数据之后,主实例才会给备库返回事务成功提交的状态,创建好名为 s 的订阅创建之后 , 我们再次打开 主实例的 postgresql.conf 文件进行调整设置synchronous_standby_names = 's'
文章插图
当有多个从实例从主实例同步的时候synchronous_standby_names 还可以采用以下配置模式
- 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三个备机中任意两个备机返回主实例就可以提交 。
- synchronous_standby_names='ANY 2 (*)' 代表所有备机中任意两个备机返回主实例就可以提交 。
- synchronous_standby_names='*' 代表匹配任意主机,也就是任意主机返回就可以提交 。
比如每个 insert 都会经过主实例和备库的这个通信超时过程,所以每个 insert 动作都变成了大约30秒次才能完成,就会导致应用程序很卡 。这时候就相当于主实例在以(很卡的)独立模式运行,这个情况在备库重新上线之后就会恢复正常(如果备库短期之内无法恢复,可以调整主实例的 synchronous_standby_names设置 移除对于s1备库的事务等待验证 , 变为单库运行模式重启实例之后也就不会卡了),但是要注意当主实例脱离备库独立运行时,如果这个时候主实例发生灾难比如硬盘坏掉,则就会产生数据丢失 。所以建议至少有2个从实例来提升保障级别
然后还需要调整主实例的 pg_hba.conf,添加 replication 模式的连接白名单配置 。hostreplicationall0.0.0.0/0scram-sha-256
文章插图
调整配置文件之后记得重启主数据库实例 。
推荐阅读
- Linux下MMDetection环境配置
- 二、.Net Core搭建Ocelot
- MongoDB数据库新手入门
- 一台虚拟机,基于docker搭建大数据HDP集群
- 二 沁恒CH32V003: Ubuntu20.04 MRS和Makefile开发环境配置
- pytorch、paddlepaddle等环境搭建 深度学习环境搭建常用网址、conda/pip命令行整理
- Win环境安装Protobuf 2.0 版本
- 【保姆教程】RuoYi-Radius搭建实现portal认证
- Windows下自动云备份思源笔记到Gitee
- windows启动不了开不了机怎么办(笔记本无法启动windows)