来源 |公众号 JiekeXu DBA之路(ID: JiekeXu_IT)
如需转载请联系授权 | (个人微信 ID:JiekeXu_DBA)
大家好,我是 JiekeXu,江湖人称“强哥”,荣获 Oracle ACE Pro 称号,墨天轮 MVP,墨天轮年度“墨力之星”,拥有 Oracle 11g OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCP 等众多国产数据库认证证书,今天和大家一起来聊聊 PostgreSQL 高可用方案,欢迎点击最上方蓝字“JiekeXu DBA之路”关注我的微信公众号,然后点击右上方三个点“设为星标”顶,更多干货文章才能第一时间推送,谢谢!
PostgreSQL 作为这两年很火的开源数据库,众多功能大多数以轻量级插件形式提供,好多高可用技术也是通过插件的形式提供。作为开源关系型数据库广受众多开发者的喜爱,前景一片大好,我也网上扒了好几周,查了很多资料,据说 repmgr 和 Patroni 两种高可用方案使用最多,那么今天我们来一起聊聊 PostgreSQL 高可用都有哪些方案。
• keepalived 通过 vrrp 控制 VIP 的漂移,同时它也具有 watch dog 和 health check 这样的功能,可以统一的对外来提供访问模块。
• HAProxy 可以进行底层的健康检查、负载均衡,这也是一种高可用的状态检测和处理逻辑的一种方式。
• 用于连接池管理与代理分发
http://www.pgbouncer.org/install.html
Streaming Replication:主库则在 WAL 日志记录产生时即将它们以流式传送给从服务器而不必等 到 WAL 文件被填充。默认情况下流复制是异步的。
主从架构:在这种架构中,一个主节点处理所有的写操作,并将数据实时复制到一个或多个从节点,从节点可以处理只读请求,提升读性能。可以配置同步与异步模式。
• 实时性:主节点的更改几乎实时地复制到从节点,数据一致性高。 • 读扩展:从节点可以处理只读请求,提高读性能。 • 易于配置:相对简单的配置和管理。
• 数据丢失风险(异步模式):在异步模式下,主节点故障可能导致数据丢失。 • 延迟:在同步模式下,写操作会有额外的延迟。 • 故障转移手动处理:默认情况下,故障转移需要手动处理。
Logical Replication:逻辑复制是一种基于数据对象的复制标识(通常是主键)复制数据对象及其更改的方法。逻辑复制使用一种发布和订阅模型,其中有一个或者更多订阅者订阅一个发布者节点上的一 个或者更多发布,订阅者从它们所订阅的发布拉取数据并且可能后续重新发布这些数据以 允许级联复制或者更复杂的配置。
• 灵活性:可以选择性地复制特定表或数据,适用于数据分片或跨版本升级。 • 异构复制:支持不同版本的 PostgreSQL 之间的数据复制。 • 无停机升级:可以用于无停机升级数据库。
• 配置复杂:配置和管理比流复制复杂。 • 性能开销:逻辑复制的性能开销可能比流复制大,尤其是在大量数据变更时。 • 数据一致性:在高负载下,可能会有数据不一致的风险。
Patroni 是一个基于 Python 的高可用解决方案,利用 etcd、Consul 或 ZooKeeper 或 Kubernetes 等分布式一致性存储实现自动故障转移。
• Patroni 会监控主节点和副本节点的活跃度,并可以更改所有集群成员的配置。它可以处理同步性要求和计划内切换,以及计划外故障转移。Patroni 会自动执行这些复杂的任务。此外,它可以保证始终满足某些条件,以完全排除对您的数据造成不可逆转的损害.每个 PostgreSQL 实例都有一个指定的 Patroni 实例来监视和控制它。
• 复杂性:需要配置和管理多个组件(如 etcd、Consul 或 ZooKeeper)。 • 资源消耗:额外的组件会增加系统资源消耗和运维复杂度。
https://developer.aliyun.com/article/775029
https://patroni.readthedocs.io/en/latest/
repmgr 是 EDB 公司的一个开源工具套件(类似于 MySQL 的 MHA),用于管理 PostgreSQL 服务器集群中的复制和故障转移。它使用工具来增强 PostgreSQL 的内置热备份功能,以设置备用服务器,监控复制以及执行管理任务,例如故障转移或手动切换操作。
repmgr 命令管理 (replication manager),日常操作主要通过 Repmgr 进行操作,功能包括集群状态查看、switchover、克隆备库、失效节点重新加入等。
监控和记录集群复制性能 通过检测主服务器故障并提升最合适的备用服务器来执行故障转移 将有关群集中事件的通知提供给用户定义的脚本,该脚本可以执行诸如通过电子邮件发送警报等任务 repmgrd 根据本地数据库角色不同,其功能也不同:主库:repmgrd仅监控本地数据库,负责自动恢复、同异步切换 备库:repmgrd监控本地数据库和主数据库,负责自动切换、复制槽删除。
• 用来处理集群主库和备库之间可能存在网络拥塞、延迟、路由等问题影响,导致主库还在正常工作,而备库无法联系主库的场景
https://www.repmgr.org/
PAF 是一个基于 Corosync 和 Pacemaker 的高可用方案,提供了自动故障转移和节点监控功能。
• 可靠性:基于成熟的 Corosync 和 Pacemaker 提供高可靠性。
• 自动故障转移:提供自动故障转移和节点监控功能。
• 可扩展性:可以扩展到多个节点。
• 配置复杂:需要配置和管理 Corosync 和 Pacemaker,增加了系统复杂性。
• 资源消耗:额外的组件会增加系统资源消耗。
Pgpool-II 是在 PostgreSQL 服务器和 PostgreSQL 数据库客户端之间工作的中间件,它是在类似于 BSD 和 MIT 的许可证下分发的。
• Pgpool-II 保存与 PostgreSQL 服务器的连接,并在具有相同属性(即用户名、数据库、协议版本)的新连接进来时重用它们。它减少了连接开销,并提高了系统的整体吞吐量。
• Pgpool-II 可以管理多个 PostgreSQL 服务器。使用复制功能可以在 2 个或更多物理磁盘上创建实时备份,以便在磁盘发生故障时可以继续服务而无需停止服务器。
• 如果复制了数据库,则在任何服务器上执行 SELECT 查询将返回相同的结果。Pgpool-II 利用复制功能,通过在多个服务器之间分配 SELECT 查询来减少每个 PostgreSQL 服务器上的负载,从而提高系统的整体吞吐量。充其量,性能的提高与PostgreSQL服务器的数量成正比。负载均衡在大量用户同时执行多个查询的情况下效果最佳。
• 与 PostgreSQL 的最大并发连接数是有限制的,并且在连接这么多之后将被拒绝连接。但是,设置最大连接数会增加资源消耗并影响系统性能。pgpool-II 对最大连接数也有限制,但额外的连接将排队,而不是立即返回错误。
• 看门狗可以协调多个Pgpool-II,创建一个强大的集群系统,避免单点故障或大脑分裂。看门狗可以对其他 pgpool-II 节点执行寿命检查,以检测 Pgpoll-II 的故障。如果活动 Pgpool-II 出现故障,备用 Pgpool-II 可以升级为活动 Pgpool-II,并接管虚拟 IP。
• 在内存中,查询缓存允许保存一对 SELECT 语句及其结果。如果输入相同的 SELECT,则 Pgpool-II 从缓存中返回值。由于不涉及 SQL 解析或对 PostgreSQL 的访问,因此使用内存缓存的速度非常快。另一方面,在某些情况下,它可能比正常路径慢,因为它增加了存储缓存数据的一些开销。
• 连接池:提供连接池功能,提高数据库性能。 • 负载均衡:可以在多个 PostgreSQL 实例之间分发查询请求。 • 自动故障转移:支持自动故障转移和读写分离。
• 复杂性:配置和管理相对复杂。 • 性能开销:在高负载情况下,Pgpool-II 本身可能成为瓶颈。 • 一致性:需要额外处理数据一致性问题。
https://www.pgpool.net/mediawiki/index.php/Documentation
https://www.pgpool.net/mediawiki/index.php/Downloads
Citus 将 PostgreSQL 转变为一个分布式数据库系统,通过数据分片和并行查询处理提高性能和扩展性。结合流复制和自动故障转移,实现高可用性和数据一致性。
• 分布式数据库:将 PostgreSQL 转变为分布式数据库,提升性能和扩展性。 • 高可用性:结合流复制和自动故障转移,实现高可用性和数据一致性。 • 水平扩展:可以通过增加节点来水平扩展数据库。
• 复杂性:配置和管理分布式数据库较为复杂。 • 成本:需要更多硬件资源,成本较高。 • 特定场景:适用于特定的业务场景,如需要大规模数据处理和高并发请求。
优点:多台主机提供读写能力,提高可用性。 缺点:过于复杂,解决写冲突比较困难,数据不一致性的概率增高,有丢失数据风险。强烈建议使用单主复制,不到万不得已的情况下才可使用多主复制方案,因为解决起来十分麻烦,风险很高。 常见的多主复制方案有:BDR(双向复制)、xDB、PostgreSQL-XL、PostgreSQL-XC / PostgreSQL-XC2、Rubyrep、Bucardo。
BDR(双向复制)、xDB、PostgreSQL-XL、PostgreSQL-XC / PostgreSQL-XC2、Rubyrep、Bucardo
Bi-Directional Replication:多节点之间进行双向同步,技术较为成熟,从 PG 9.4 开始提供。属于比较老的技术了,网上近几年都没有相关文章。
BDR 的早期版本是开放源代码,但其最新版本是封闭源代码,这个解决方案最早是由 2ndQuadrant 开发的。
• EnterpriseDB 用 Java 开发了自己的双向复制解决方案,称为 xDB,属于闭源项目,网上资料稀缺。
• 它是 PostgreSQL-XC 的一个分支,目前受 2ndQuadrant 支持。它会落后于社区 PostgreSQL 的版本迭代。据了解,它基于 PostgreSQL 10.6,与 PostgreSQL-12 不兼容。适用于 OLAP ,但不太适合高 TPS。
• PostgreSQL-XC 由EnterpriseDB 和 NTT 开发,它是一个开源的同步复制解决方案,旨在提供可写扩展、同步、对称和透明的 PostgreSQL 集群解决方案。
• 它是阿恩.特莱曼(Arndt Lehmann)开发的异步主/主复制,它声称具有最简单的配置特征,并且可以跨平台(包括Windows)运行。自动设置必要的触发器,日志表等 ;自动发现新添加的表并同步表内容 ;自动重新配置序列,以避免重复的键冲突
• Bucardo 是 End Point 公司的 Jon Jensen 和 Greg Sabino Mullane 开发的基于触发器的复制解决方案。Bucardo 的解决方案已经存在了将近 20 年,但安装和配置很复杂,复制经常中断并且出现错误。对 Perl 5,DBI,DBD :: Pg,DBIx :: Safe 的依赖。
http://www.pgbouncer.org/install.html
https://developer.aliyun.com/article/775029
https://patroni.readthedocs.io/en/latest/
https://www.repmgr.org/
https://www.pgpool.net/mediawiki/index.php/Documentation
https://www.pgpool.net/mediawiki/index.php/Downloads
https://www.modb.pro/db/459891
https://blog.csdn.net/weixin_37692493/article/details/117032458
全文完,希望可以帮到正在阅读的你,如果觉得有帮助,可以分享给你身边的朋友,同事,你关心谁就分享给谁,一起学习共同进步~~~