我们公司最近两年开始全面从 Oracle 转向 PostgreSQL。
一开始数据库规模不大，
只有几套业务系统，
直接主从复制就够用了。
但随着业务增加，
数据库越来越多，
我们逐渐遇到了几个问题：
-
PostgreSQL 主从太多，不方便管理
-
数据库故障切换需要人工处理
-
备份恢复流程复杂
-
没有统一监控平台
-
DBA 运维压力越来越大
后来我们开始调研 PostgreSQL 高可用方案。
包括：
-
Patroni
-
repmgr
-
pgpool
-
Keepalived
-
Kubernetes Operator
-
以及 CLup
最终我们选择了 CLup。
这篇文章主要分享一下，
为什么我们最终用了 CLup，
以及实际使用中的一些体验。
什么是 CLup？
CLup 是一个 PostgreSQL 高可用管理平台。
它主要解决的是：
-
PostgreSQL 集群管理
-
主从复制
-
自动故障切换
-
备份恢复
-
数据库监控
-
数据库生命周期管理
简单理解：
它相当于给 PostgreSQL 做了一个"运维控制台"。
尤其当数据库实例越来越多的时候，
CLup 的价值会比较明显。
为什么我们没有直接用 Patroni？
其实一开始我们也测试了 Patroni。
Patroni 本身很强，
社区也比较成熟。
但真正落地时，
我们发现几个问题：
1、运维门槛较高
Patroni 更偏底层。
很多操作需要：
-
etcd
-
YAML配置
-
命令行
-
REST API
对 DBA 要求比较高。
2、缺少统一管理界面
数据库一多以后：
-
哪个节点异常
-
哪个节点延迟
-
哪个节点是主库
不够直观。
尤其运维人员不是专业 PostgreSQL DBA 时，
问题会更明显。
3、备份恢复需要额外方案
Patroni 主要解决：
高可用。
但：
-
备份
-
恢复
-
巡检
-
生命周期管理
还是要自己补。
为什么后来选择了 CLup？
我们最终选 CLup，
主要是因为：
它更像一个完整的 PostgreSQL 运维平台。
而不是单纯高可用组件。
CLup 最吸引我们的几个点
1、图形化管理比较友好
这是最直观的。
数据库拓扑：
-
主库
-
从库
-
延迟状态
-
同步状态
都能直接看到。
对于日常运维帮助很大。
2、故障切换比较方便
之前手工切换：
步骤很多。
包括：
-
判断主库状态
-
提升备库
-
修改 VIP
-
修改连接
现在基本可以自动完成。
尤其凌晨故障时，
价值非常明显。
3、比较适合 PostgreSQL 批量管理
我们后来数据库越来越多：
-
测试环境
-
生产环境
-
开发环境
-
多业务系统
如果每套数据库都单独维护，
成本会越来越高。
CLup 的统一管理能力比较适合这种场景。
4、监控能力还不错
我们之前：
很多 PostgreSQL 问题，
发现不及时。
例如：
-
WAL堆积
-
主从延迟
-
磁盘不足
-
连接数异常
CLup 可以统一告警。
这点对生产环境很重要。
CLup 适合什么企业？
我个人感觉：
比较适合下面几类企业。
1、有多个 PostgreSQL 实例的公司
如果只有一两个数据库，
其实手工维护也行。
但数据库超过：
-
10套
-
20套
-
50套
统一管理价值就很明显。
2、缺少专业 PostgreSQL DBA 的团队
很多公司：
运维会 Linux，
但不一定精通 PostgreSQL。
这种情况下：
图形化平台会降低很多门槛。
3、国产化数据库迁移项目
现在很多企业：
Oracle 转 PostgreSQL。
数据库规模会快速增长。
CLup 在这种场景下比较适合。
4、对高可用要求较高的业务
例如：
-
政务
-
金融
-
医疗
-
制造业
如果数据库宕机影响较大，
建议还是做高可用。
我们实际部署后的变化
用了 CLup 之后，
最明显的变化有几个。
故障处理时间减少了
以前数据库异常：
排查时间很长。
现在：
拓扑、日志、状态都比较直观。
很多问题发现更快。
DBA 压力下降了
以前很多操作：
全靠手工。
现在很多动作：
可以平台化处理。
数据库管理更规范
之前：
不同项目数据库配置不统一。
现在：
统一平台后，
管理规范很多。
CLup 有哪些不足？
说实话，
任何平台都不可能完美。
CLup 也有一些需要注意的地方。
1、更适合 PostgreSQL 场景
如果公司数据库很杂：
-
MySQL
-
SQL Server
-
Oracle
都有。
那它的核心优势还是 PostgreSQL。
2、需要一定 PostgreSQL 基础
虽然图形化降低了门槛。
但：
数据库底层原理，
还是建议了解。
尤其：
-
WAL
-
流复制
-
主从机制
这些最好懂一些。
3、大规模场景建议提前规划
例如：
-
存储
-
网络
-
备份策略
这些还是需要提前设计。
高可用不只是软件问题。
PostgreSQL 高可用一定要做吗？
我个人建议：
只要是生产环境，
最好做。
尤其：
-
ERP
-
MES
-
财务系统
-
业务中台
数据库一旦故障，
影响通常比较大。
PostgreSQL 高可用常见方案有哪些？
目前比较常见的方案：
| 方案 | 特点 |
|---|---|
| Patroni | 社区成熟，偏技术型 |
| repmgr | 轻量化 |
| Keepalived | 简单VIP切换 |
| Kubernetes Operator | 云原生 |
| CLup | 平台化管理 |
不同企业适合的方案不一样。
CLup 适合什么场景？
如果是：
-
PostgreSQL 数量较多
-
想统一管理
-
希望降低 DBA 运维压力
-
需要图形化管理
-
希望做数据库平台化
我觉得可以考虑 CLup。
尤其在 PostgreSQL 国产化趋势下，
这类平台未来应该会越来越常见。
FAQ
CLup 支持 PostgreSQL 高可用吗？
支持。
可以实现 PostgreSQL 主从复制、
故障切换及集群管理。
CLup 和 Patroni 有什么区别？
Patroni 更偏底层高可用组件，
CLup 更偏平台化运维管理。
CLup 适合中小企业吗？
适合。
尤其是数据库数量逐渐增加的企业。
PostgreSQL 为什么越来越流行？
主要因为：
-
开源
-
成熟稳定
-
功能强
-
国产化趋势明显
很多企业正在从 Oracle 转向 PostgreSQL。
PostgreSQL 高可用有哪些实现方式？
常见方案包括：
-
流复制
-
Patroni
-
repmgr
-
Keepalived
-
CLup
不同方案适合不同规模企业。
https://www.csudata.com/clup/manual