根据2023DTCC专场13，崔鹏老师的PostgreSQL的高可用架构设计与实践.pdf文档整理而成。

1.需求

1.1.数据复制需求

1.1.1.同步复制

1.1.2.异步复制

1.1.3.级联复制

1.1.4.不同集群间的数据同步

1.2.故障转移需求

1.2.1.支持自动故障转移

1.2.2.支持脚本回调

1.3.部署需求

1.3.1.支持k8s，docker等容器化环境部署

1.3.2.满足不同级别项目的快速部署

1.4.其它需求

1.4.1.支持通过pg_rewind自动修复旧主

1.4.2.支持通过watchdog防止脑裂

1.4.3.支持多种方式初始化集群和重建备机

2.方案

2.1.Patroni

2.1.1.介绍

Patroni提供了简单的配置和管理界面， 使得部署和维护PostgreSQL高可用性集群变得容易。 它采用YAML配置文件， 可以快速定义和修改集群配置， 同时提供了命令行工具和RESTful API， 方便管理和监控集群状态。

2.1.2.优点

• 简单易用
• 自动化故障检测和恢复
• 高度可定制
• 社区活跃和可靠性

2.1.3.缺点

• 学习曲线较陡

  对于没有使用过类似工具的用户来说， Patroni可能需要一些时间来学习和理解其配置和管理方式。 尽管Patroni提了详细的文档和示例， 但有一定的技术门槛， 需要一定的经验和知识。

• 依赖外部协调服务

  Patroni使用外部协调服务（如ZooKeeper、 etcd或Consul） 来实现主节点选举和故障检测等功能。 这意味着要部署和配置额外的组件， 并确保它们的可用性和稳定性。如果协调服务发生故障或出现网络问题， 可能会影响到整个集群的正常运行。

• 限制于PostgreSQL

   Patroni专注于管理PostgreSQL数据库集群， 因此对于其他数据库引擎或系统的支持相对有限。 如果需要管理多种不同类型的数据库集群， 可能需要考虑其他适合的工具或解决方案。
  

2.1.4.架构

2.2.Repmgr

2.2.1.介绍

repmgr提供了简洁而直观的命令行工具和API， 使得设置和管理PostgreSQL的主从复制变得容易。它使用INI格式的配置文件， 允许用户快速定义和修改复制拓扑结构， 并提供了多种选项来适应不同的需求和环境。

2.2.2.优点

• 简单易用
• 自动化故障检测和恢复
• 灵活的复制拓扑
• 文档和社区支持

2.2.3.缺点

• 配置复杂性

repmgr的配置相对复杂， 特别是对于新手用户来说可能会有一定的学习曲线。 它需要进行详细的配置和设置， 包括复制节点的身份、 连接信息、 拓扑结构等。 在某些复杂的情况下， 可能需要更深入的了解和调试， 以确保正确
的配置和运行。

• 对网络和存储依赖
• 数据同步延迟
• 限于PostgreSQL

2.2.4.架构

2.3.pgpool+vip

2.3.1.优点

• 简单易用
• 自动化故障检测和恢复

2.3.2.缺点

• 性能损耗较大
• 容易出现脑裂

2.3.3.架构

2.4.stolon

2.4.1.缺点

• 使用案例少资料少暂不做了解

2.5.keepalived+vip

2.5.1优点

部署简单

2.5.2.缺点

基于网络底层协议 不稳定，VIP 容易乱飘 dba需具备网络技能 运维可维护性不高

2.6.方案对比

3.应用连接数据库集群方式

Pgbouncer/Pgpool/Haproxy/VIP/DNS/JDBC或其它语言支持连接层配置多IP地址

3.1.JDBC 配置多IP地址

• jdbc:postgresql://node1,node2,node3/accounting?targetServerType=master
• 订阅etcd中的Leader Key变化
• VIP：同中心提供虚拟机访问方式,patroni的callback脚本

4.数据库实例活动状态检测

pg_isready
pg_ctl staus
pg_controldata
ps - ef |grep postgres
psql - c ‘select 1;’
psql -c 'select count(*) from pg_authid;'
psql -c 'select count(*) from pg_class;'
psql -c 'select count(*) from pg_auth_members;'
psql -c 'select count(*) from pg_database;'
psql -c 'select count(*) from pg_index;'
psql -c 'select count(*) from pg_tablespace;'
psql -c 'select count(*) from pg_namespace;'
psql -c 'select count(*) from pg_attribute;'
psql -c 'select count(*) from pg_depend;'
psql -c 'select count(*) from pg_statistic;'
psql -c 'select count(*) from pg_stat_replication;'

5.脑裂

5.1产生的原因

• 网络问题
• 主备切换异常
• 网络孤岛
• 原节点以主角色加入集群

5.2.处理办法

• 网关
• 仲裁节点
• DCS软件(ETCD/ZK)
• 发生网络隔离时,节点暂停

6.主流连接池对比解析

6.1.PgBouncer

6.1.1.特点

6.1.1.1连接池

Pgbouncer可以维护一个连接池， 将数据库连接复用， 并通过复用连接减少与数据库的建立和断开连接的开销。

6.1.1.2.代理服务器

Pgbouncer作为一个中间层代理， 可以将客户端请求转发给后端的PostgreSQL服务器。 这样可以分担数据库服务器的负载， 并提高系统的并发性能。

6.1.1.3.高性能

Pgbouncer采用异步I/O模型， 具有较低的资源消耗和响应延迟， 可以处理大量的并发连接

6.1.1.4.配置灵活

Pgbouncer的配置非常灵活， 可以根据实际需求进行调整和优化， 包括连接池大小、超时设置、 认证方式等。

6.1.1.5.高可用性

Pgbouncer支持故障检测和自动恢复功能。 当后端的数据库服务器发生故障时，Pgbouncer可以自动将连接切换到其他可用的服务器上， 保持系统的连续可用性。

6.1.2.优点

6.1.2.1.节省资源

通过连接池的使用， Pgbouncer减少了数据库建立和断开连接的开销， 节省了资源和网络带宽

6.1.2.2.提高性能

Pgbouncer通过复用连接和异步I/O模型， 提高了系统的并发处理能力和响应速度。

6.1.2.3.简化连接管理

Pgbouncer管理连接池的创建、 销毁和超时等， 简化了数据库连接的管理和维护工作

6.1.2.4.可靠性

Pgbouncer具有故障检测和恢复功能， 可以自动切换到可用的数据库服务器， 提供高可用性和容错能力。

6.1.3.缺点

6.1.3.1.单点故障

由于Pgbouncer本身是一个中间代理， 如果Pgbouncer出现故障， 可能会导致整个系统无法访问数据库。

6.1.3.2.有限的功能

相对于完整的数据库服务器， Pgbouncer的功能较为有限， 它主要关注连接管理和负载均衡， 并不支持一些数据库特定的功能和扩展。

6.2.pgpool-II

6.2.1.特点

6.2.1.1.连接池

Pgpool可以维护一个连接池， 复用数据库连接， 减少建立和断开连接的开销，并提高性能。

6.2.1.2.负载均衡

Pgpool作为负载均衡器， 可以将客户端请求分发给后端的多个PostgreSQL数据库节点， 平衡负载， 并增加系统的并发处理能力。

6.2.1.3.自动故障检测和切换

Pgpool可以监测后端数据库节点的可用性， 并在某一节点发生故障时自动切换到其他可用节点， 保证系统的高可用性。

6.2.1.4.并行查询

Pgpool可以将一个查询请求分解为多个子查询， 并在后端数据库节点之间并行执行， 提高查询性能和响应时间

6.2.2.优点

6.2.2.1.提高性能

通过连接池和负载均衡机制， Pgpool可以提高系统的并发处理能力和响应速度， 减少数据库的负载压力。

6.2.2.2.高可用性

Pgpool支持故障检测和自动切换功能， 当后端数据库节点发生故障时，Pgpool可以自动将连接切换到其他可用节点， 保证系统的连续可用性。

6.2.2.3.负载均衡

Pgpool可以将客户端请求均匀地分发到多个数据库节点， 平衡负载， 提高系统的扩展性和稳定性。

6.2.2.4.并行查询

Pgpool的并行查询功能可以将查询请求分解为多个子查询， 并在多个节点上并行执行， 加快查询速度。

6.2.3.缺点

6.2.3.1.配置复杂

Pgpool的配置相对复杂， 需要了解和理解PostgreSQL集群的工作原理和参数设置， 以确保正确和最佳的配置

6.2.3.2.单点故障

如果Pgpool本身出现故障或性能瓶颈， 可能会影响整个数据库集群的访问

6.2.3.3.不支持所有PostgreSQL特性

不支持所有PostgreSQL特性： Pgpool并不完全支持所有PostgreSQL的特性和扩展， 某些复杂的操作可能需要直接与数据库节点交互。

6.2.3.4.切换时数据一致性

由于切换时的数据同步延迟， 可能会导致在发生故障切换时部分数据的丢失或不一致

6.3.Apache Tomcat JDBC Pool

6.4.HAProxy

6.4.1.介绍

一个开源的高性能、 可靠的负载均衡器和代理服务器。 它被广泛应用于分布式系统架构中， 可以将网络流量分发到多个后端服务器， 实现负载均衡和高可用性。

6.4.2.特点

6.4.2.1.高性能

HAProxy采用事件驱动的模型和多线程技术， 具有卓越的性能和响应速度， 能够处理大量并发连接和高流量负载。

6.4.2.2.支持多种负载均衡算法

HAProxy支持多种负载均衡算法， 如轮询、 最小连接数、 IP散列等，可以根据需求进行灵活配置。

6.4.2.3.健康检查

HAProxy能够定期检查后端服务器的健康状态， 通过监测服务器的可用性来确保只将请求转发到正常运行的服务器上。

6.4.2.4.SSL/TLS终端处理

HAProxy可以作为SSL/TLS终端进行加密和解密， 提供安全的通信通道，并支持负载均衡和代理功能。

6.4.3.优点

6.4.3.1.高可用性

HAProxy支持热备份和故障自动切换， 当一个或多个后端服务器发生故障时，HAProxy能够自动将请求转发到其他健康的服务器上， 确保系统的连续可用性。

6.4.3.2.灵活的配置

HAProxy的配置文件简单而灵活， 可以通过配置文件进行动态调整和扩展，以适应不同的负载均衡需求。

6.4.3.3.监控和统计

HAProxy提供丰富的监控和统计信息， 可以实时监测负载均衡器和后端服务器的性能指标， 并进行故障排除和性能优化

6.4.3.4.支持WebSocket和HTTP/2

HAProxy支持WebSocket协议和HTTP/2协议， 能够处理现代Web应用的通信需求

6.4.4.缺点

6.4.4.1.单点故障

由于HAProxy本身是一个集中式的负载均衡器， 如果HAProxy发生故障，可能会导致整个系统无法访问。

6.4.4.2.学习成本

HAProxy的配置相对复杂， 需要了解和理解各项配置参数和负载均衡算法，初学者可能需要一些时间来学习和掌握。

6.4.4.3.有限的高级功能

HAProxy的重点是负载均衡和代理， 相对于完整的Web服务器， 它可能缺少某些高级的Web服务功能。

7.备份工具对比解析

7.1.Pgbackrest

7.1.1.介绍

Pgbackrest是一个强大且功能丰富的备份和恢复工具。 它使用基于硬链接的增量备份策略， 提供了高性能和低备份窗口的特点。 Pgbackrest支持并行备份和恢复操作， 并提供了各种配置选项来满足不同需求。

7.1.2.特性

7.1.2.1.技术特性

7.1.2.2.功能特性

7.1.3.优点

Pgbackrest具有出色的性能和并行处理能力， 并提供了高级功能， 如增量备份、 备份完整性校验、 远程复制等。 它的文档和社区支持也相对较好。

7.1.4.缺点

Pgbackrest的配置比较复杂， 对初学者而言可能需要花费一些时间来进行学习和理解。 此外， Pgbackrest的备份文件格式并非与PostgreSQL兼容，因此在恢复时可能需要使用特定的工具进行操作

7.2.pg_probackup

7.2.1.特点

pg_probackup是由Postgres Professional开发的备份和恢复工具。 它支持全量备份和增量备份， 通过使用PostgreSQL内部的技术（如并发控制和热备份） 来实现高性能备份。

7.2.1.1.优点

pg_probackup具有与PostgreSQL高度集成的特点， 可以直接从数据库实例进行备份和恢复。 它支持并行备份和恢复操作， 并提供了管理工具和命令行界面来简化操作。

7.2.1.2.缺点

pg_probackup在某些方面相对较新， 可能在稳定性和成熟度方面略逊一筹。 此外， 它的文档和社区支持相对较少， 可能需要更多自主学习和摸索。

7.3.pg_rman

7.3.1.特点

pg_rman是一个基于归档日志的备份和恢复工具。 它使用PostgreSQL的归档日志来实现备份和增量备份功能， 支持全量和差异备份， 并可与物理备份（如文件级备份） 结合使用。

7.3.1.1.优点

pg_rman相对简单易用， 它的备份文件与PostgreSQL兼容， 恢复时可以直接使用PostgreSQL工具进行操作。 它提供了可靠的备份和恢复机制， 并支持WAL文件的轮转和管理。

7.3.1.2.缺点

pg_rman在并行备份和恢复方面的能力比较有限， 可能无法满足高吞吐量和大规模数据的需求。 此外， pg_rman的社区支持相对较少， 更新和改进的速度可能较慢

7.4.pg_basebackup

7.4.1.特点

7.4.1.1.全量备份

pg_basebackup执行全量备份， 将数据库的所有数据文件复制到目标位置。

7.4.1.2.基于流复制协议

它使用PostgreSQL的流复制协议（Streaming Replication Protocol） 进行备份， 可以实现高效的数据传输

7.4.1.3.支持增量备份

结合归档日志， pg_basebackup可以实现增量备份的功能

7.4.1.4.简单易用

pg_basebackup是PostgreSQL自带的工具， 使用起来相对简单， 不需要额外安装和配置

7.4.2.优点

7.4.2.1.数据一致性

pg_basebackup在备份过程中会自动处理并发操作， 保证备份数据的一致性

7.4.2.2.故障恢复简单

由于备份是全量的， 因此在故障恢复时只需要拷贝备份文件到新的数据库实例即可， 恢复速度较快

7.4.2.3.集成性强

pg_basebackup与PostgreSQL紧密集成， 可以与其他PostgreSQL工具和功能无缝配合使用。

7.4.3.缺点

7.4.3.1.备份窗口较长

由于pg_basebackup是全量备份， 当数据量较大时， 备份过程可能相对耗时， 导致备份窗口较长

7.4.3.2.不支持并行操作

pg_basebackup不支持并行备份操作， 无法充分利用多个CPU核心或网络带宽来提高备份速度。