2.4 数据库集群：主从部署与它的能力边界

一句话判断

数据库集群是 1Panel 数据库模块的“终点”，但不是“银弹”。它解决的是“读扩展”和“数据冗余”两个问题，不解决“自动故障切换”。买之前先想清楚：你要的是高可用，还是只是想要一份实时副本？

先把版本边界说清楚

数据库集群位于 高级功能 → 数据库集群，仅专业版和企业版可用，需要三样东西同时到位：

前提 说明
有效许可证 专业版或企业版，价格以官网为准
节点管理能力 集群跑在多节点上，先会管节点（见 4.2 节）
数据库集群权限 企业版里普通用户需要单独授权

支持的三种数据库：MySQL、PostgreSQL、Redis。MongoDB 不支持集群——官方文档里写得很明白，别去面板上找第四个标签。

集群能做什么、不能做什么

这一节最重要的话先说在前面，官方文档的原话值得贴出来：

数据库复制状态正常不等同于已经具备自动故障切换能力。

翻译成大白话：主库挂了，从库不会自动顶上。 应用连的还是主库的地址，主库挂了你得手动切。

你想要的 集群能给吗 说明
读写分离，把读压力分摊出去 ✅ 能 应用层自己把读请求指向从库
数据冗余，主库盘坏了从库还有数据 ✅ 能 副本是实时的（有延迟）
主库挂了自动切换、业务无感 ❌ 不能 没有自动故障切换，需人工操作
负载均衡数据库连接 ❌ 不能 不带连接池和转发能力
自动备份 ❌ 不直接提供 备份还是走 2.3 节那套流程

这表得先看明白再掏钱。 很多人以为“上了集群就高可用了”，结果主库宕机时发现应用还指着主库的 IP，从库好好的就是没用上。

使用前提：官方的五条清单

创建集群前，官方列了五个前置条件，逐条过一遍：

  1. 已在节点管理中添加并检查目标节点 —— 集群是跨节点的，至少两台机器；
  2. 源节点和目标节点之间网络互通 —— 内网互通是硬要求，跨公网做复制延迟会教你做人；
  3. 应用商店可用，目标节点磁盘和内存足够 —— 从库是应用商店装出来的实例；
  4. 数据库端口未被占用，防火墙允许集群内部通信 —— 复制端口两台机器都要通；
  5. 已完成业务数据备份 —— 创建集群会动数据库配置。

第 4 条是最常翻车的。 防火墙这件事在 2.1 节讲过“两道门”的逻辑，这里同理：节点之间互相访问数据库端口，防火墙和云安全组都要放行。很多人两台机器都装好了，复制一直起不来，最后发现是安全组没开内网端口。

创建集群：五步走

页面按数据库类型提供独立标签（MySQL / PostgreSQL / Redis），操作步骤一致：

  1. 选择对应数据库的标签；
  2. 点击 添加集群，填写集群名称；
  3. 选择安装节点，配置主节点参数；
  4. 提交任务，在任务日志中确认安装完成；
  5. 在已有集群中添加从节点，等待初始化和复制状态正常。

第 4 步不要省。 创建是后台任务，任务日志里确认“安装完成、状态正常”了再往下加从节点。装到一半失败留下来的半成品，清理起来比重新装还麻烦。

第 5 步的“复制状态正常”是关键字段。 页面会展示集群节点、角色（主/从）、状态和复制信息——以后这个页面就是你判断集群健康度的第一站。 复制延迟突然变大，往往早于业务报错。

日常管理

集群页面的管理动作不多，但每个都有讲究：

操作 要注意什么
同步状态 手动刷新复制状态，怀疑延迟时先点它
添加节点 加从节点，不影响主库
删除节点 页面会检查关联的应用安装，是否同时删除应用和数据以确认对话框为准

删除节点是最危险的操作。 确认对话框会问你要不要连同应用和数据一起删——删除前先想清楚这个节点上跑着什么。官方的措辞是“以确认对话框为准”，意思是不同的场景选项不同，看清楚再点，别养成无脑点确定的肌肉记忆。

故障切换：手动切换的检查清单

既然没有自动切换，那主库真挂了该怎么办？官方给出的建议是：执行主从切换、删除主节点或恢复备份前，应先确认三件事：

确认项 为什么
业务连接方式 应用现在连的哪个地址，切换后要改哪些配置
复制延迟 从库的数据是不是已经追平，差多少
回滚方案 切错了怎么切回去

一个可复用的手动切换流程：

主库故障切换流程
  1. 确认主库确实不可用（不是网络抖动）
  2. 查看集群页面复制状态，确认从库已追平数据
  3. 停止业务写入（或接受这段时间的写丢失）
  4. 提升从库为新主库（通过集群页面操作）
  5. 修改应用连接地址，指向新主库
  6. 重启或重连应用，验证读写正常
  7. 旧主库修复后，作为从库重新加入集群

第 3 步是很多团队跳过的。 如果从库有延迟、还没追平，你直接切，那点延迟的数据就永久丢了。“先停写、再切换”是保守但正确的做法。

什么情况该上集群

给你一张决策表，对照着选：

场景 建议
单台机器、数据量不大 不用集群，2.3 节的备份流程就够了
读请求量大、写不多（内容站、报表） 上集群，应用层做读写分离
对数据安全要求极高、能接受手动切换 上集群当实时副本，配合定期备份
要求故障自动切换、业务不能停 1Panel 集群满足不了，看云厂商的高可用数据库
只是想做异地容灾 先评估“资源同步”（4.2 节）+ 备份下载，成本更低

最后一行经常被忽略。 很多人想要的其实只是“数据在另一个地方存一份”，这时候 1Panel 的备份下载到本地、或者推到对象存储，比搭一套集群便宜得多。集群的核心价值是“实时的副本”，你愿意为“实时”这两个字付多少，自己算。

三种数据库的集群差异

虽然是同一套页面，但三种库的复制机制不同，排错时方向也不一样：

数据库 复制方式 排错关键词
MySQL 基于位点/GTID 的异步或半同步复制 SHOW SLAVE STATUS、Seconds_Behind_Master
PostgreSQL 流复制（WAL 日志传送） 复制槽、WAL 堆积
Redis 主从同步 + 哨兵可选 INFO replication、offset 对比

一个共同点：异步复制都有延迟。 而且延迟不是固定值——主库写入高峰时延迟会拉大，网络抖动时也会。看集群页面的复制信息时，要学会判断“正常波动”和“持续扩大”的区别：稳定在 100ms 附近是正常的，从 100ms 一路涨到 10s 就要介入了。

Redis 集群有个额外提醒：Redis 的复制和 2.2 节讲的持久化是两个维度。集群解决的是“另一台机器上有一份副本”，持久化解决的是“这台机器重启后数据还在”。两者不能互相替代。

一个真实的评估案例

某公司官网 + 后台系统，MySQL 单库跑了三年，数据量 20G，日 PV 五万左右。技术负责人想买专业版上集群，理由是“怕数据库挂了公司就完了”。

坐下来算账：

方案 成本 收益
上集群（两台节点 + 专业版） 多一台服务器 + 订阅费 读分摊、实时副本，但挂了还得手动切
定时备份 + 备份下载 接近零 数据不丢，恢复要花几十分钟
云厂商高可用 RDS 数据库月费 自动切换，省心

最后的结论：业务对“恢复几十分钟”完全可接受，真实瓶颈从来不是数据库性能而是缓存命中率。他们选了方案二，加上 2.3 节那套备份演练流程，至今没出过事。

这个案例想说明的不是一个标准答案，而是评估的思路：先量化“真正的风险是什么”，再选方案，而不是看见“集群”两个字就觉得高级。

复制延迟排查思路

集群跑起来之后，最常见的问题就是延迟。简单的排查顺序：

复制延迟排查
  1. 集群页面看复制状态和延迟数值
  2. 确认网络：节点之间 ping 延迟、带宽
  3. 确认从库负载：CPU、IO 是不是被打满
  4. 确认大事务：主库一次性写入过多，从库追不上
  5. 确认版本：主从版本差异导致复制异常

第 4 条值得注意：半夜跑批处理、大批量 DELETE、大表加索引这类操作，都会在主库产生一个“巨型事务”，从库要花很久才能追平。这类操作尽量分批做，或者安排在业务低谷。

不上集群的替代方案

如果算完账发现不值，社区版也有完整的组合拳：

需求 社区版方案
数据不丢 定时备份（计划任务）+ 备份下载到本地
跨机器管理已有数据库 远程实例纳管（2.1 节）
读写分离 应用层接 MySQL Router / ProxySQL 之类的中间件，面板外解决
故障快速恢复 2.3 节的灾难恢复流程，定期演练

这套组合覆盖了 80% 的“我以为需要集群”的场景。

本节要点

  • 数据库集群仅专业版/企业版，支持 MySQL、PostgreSQL、Redis，MongoDB 不支持；
  • 使用前提五条：节点、网络、资源、端口、备份，防火墙放行最常翻车；
  • 集群解决读扩展和数据冗余，不提供自动故障切换；
  • 删除节点以确认对话框为准，先看清楚上面跑着什么；
  • 手动切换三确认：连接方式、复制延迟、回滚方案，先停写再切换；
  • 只想要容灾的话，备份 + 远程实例可能比集群更划算。

更完整的集群参数说明见 《1Panel 官方文档：功能手册》 的“数据库集群”一节，本书讲的是决策，官方文档讲的是操作。

下一章：数据库聊到这，该换个赛道了——第 3 章我们聊 1Panel 的另一面：AI 能力实战，从模型管理开始。