《高可用读写分离集群实战》系列（一）

从单机到高可用：第一次部署读写分离集群，我踩了不少坑

🚀 本文不是官方文档翻译，而是一次完整部署读写分离集群时整理下来的学习笔记，希望能给第一次接触高可用数据库的同学一些参考。

前言

前段时间，公司准备把一个业务系统升级。

领导只提了两个要求。

数据库不能停。
查询不能越来越慢。

刚开始我还觉得，这不是很简单吗？

搭一套主备集群，数据库坏了自动切换，不就解决了吗？

结果真正部署以后才发现，高可用 和读写分离其实是两件既相关又完全不同的事情。

很多项目虽然已经做了主备，但所有查询还是压在主库上，备库几乎一直"闲着"。

随着业务越来越大，CPU、IO、连接数不断上涨，即使数据库没有故障，性能也开始出现瓶颈。

后来重新规划了读写分离架构，把查询压力分散到备库以后，数据库资源利用率明显好了很多。

这篇文章，我准备结合自己的部署过程，把整个搭建流程整理一下。

📌 本文主要内容：

为什么很多系统做了主备还是慢？
高可用和读写分离到底有什么区别？
一个标准读写分离集群长什么样？
部署之前需要准备什么？
第一次部署最容易踩哪些坑？

🤔 为什么很多项目做了主备，性能还是没有提升？

刚接触数据库集群的时候，我最大的误区就是：

只要有主备，就是高性能。

后来才发现完全不是。

很多公司的架构其实都是这样。

markdown 复制代码

业务系统

      │

    主数据库

      │

    备数据库

数据库确实能够自动同步。

主库坏了也能切换。

但是......

所有查询还是访问主库。

备库除了同步数据，几乎什么事情都没做。

换句话说：

CPU还是主库的。

IO还是主库的。

连接数还是主库的。

备库只是"保险"。

它提升的是可靠性，而不是吞吐能力。

直到后来接触读写分离以后，我才真正理解为什么很多互联网系统都采用这种方案。

🚀 什么是真正的读写分离？

真正的读写分离，更像下面这样。

markdown 复制代码

                   Application

                        │

              JDBC 读写分离驱动

                        │

                ┌──────────────┐
                │     VIP      │
                └──────────────┘

                        │

                ┌──────────────┐
                │ Primary 主库  │
                └──────────────┘
                        │
                Streaming Replication
                        │
                ┌──────────────┐
                │ Standby 备库  │
                └──────────────┘

简单来说：

写请求全部进入主库。

查询请求自动发送到备库。

如果备库有多台，还可以进一步分担查询压力。

整个业务几乎不用修改SQL。

JDBC驱动负责完成路由。

第一次看到这里的时候，我还专门写了一个小Demo验证。

连续执行几百条SELECT以后，再去查看两个节点的连接数，发现查询请求已经开始均匀落到备库。

这种感觉还是挺有意思的。

💡 我的理解：高可用解决的是"不能停"，读写分离解决的是"跑得快"

很多文章都会把这两个概念放在一起讲。

其实我觉得可以分开理解。

高可用关注的是：

✅ 数据不能丢。

✅ 主库故障能够切换。

✅ 业务尽快恢复。

而读写分离关注的是：

✅ 查询压力分散。

✅ 主库压力降低。

✅ 整体吞吐能力提高。

两者配合起来，才是真正意义上的生产集群。

📌 正式安装之前，我建议先做这几件事情

这里也是我第一次部署踩坑最多的位置。

很多人一拿到安装包就开始执行脚本。

其实真正花时间的反而是前期规划。

我现在都会提前整理下面几个信息。

第一：节点规划

建议至少准备两台服务器。

sql 复制代码

node1

Primary

10.12.11.192

复制代码

node2

Standby

10.12.11.193

如果业务比较重要，可以后面继续增加备用节点。

不过第一次学习，两台已经足够。

第二：VIP规划

这里很多人都会忽略。

VIP其实就是业务访问数据库时统一连接的地址。

以后主库切换。

VIP也会自动漂移。

应用始终连接同一个地址。

不用修改配置。

第一次看到这个设计的时候，我觉得还是挺巧妙的。

第三：网络一定提前确认

这里真踩过坑。

我第一次部署的时候。

SSH互信没有配置完成。

结果cluster_install.sh一直执行失败。

后来重新检查发现。

两台机器虽然能够ping通。

但是root登录限制了SSH。

所以部署脚本一直卡在那里。

后来重新配置互信以后，十几分钟就完成部署了。

如果提前检查网络，其实完全可以避免。

⚙️ 环境准备

这里官方要求其实已经比较完整。

我一般只检查几个重点。

✔ 节点时间一致

✔ SSH互信正常

✔ 防火墙端口放通

✔ 磁盘空间充足

✔ kingbase用户提前创建

例如：

bash 复制代码

useradd -u 2000 kingbase

passwd kingbase

创建完成以后，再统一授权目录。

这样后面安装基本不会因为权限报错。

🚀 一键部署开始

真正开始安装以后，反而没有那么复杂。

把软件包上传到主节点。

进入目录。

bash 复制代码

cd /home/kingbase/software

先执行互信脚本。

bash 复制代码

sh trust_cluster.sh

确认所有节点互信完成以后。

再开始部署。

bash 复制代码

sh cluster_install.sh

这里建议不要急着关闭窗口。

脚本会自动完成：

软件安装
初始化数据库
创建集群
注册节点
配置流复制
启动服务

整个过程基本都是自动完成。

🔍 怎么确认部署成功？

安装结束以后。

我一般第一件事情不是登录数据库。

而是查看整个集群状态。

bash 复制代码

cd /home/kingbase/cluster/install/kingbase/bin

./repmgr cluster show

如果看到类似下面结果。

sql 复制代码

ID   Name    Role

1    node1   primary

2    node2   standby

说明主备已经建立完成。

当然。

这里不要急着结束。

我一般都会继续做下面两个验证。

第一。

停止主库。

看看备库能不能自动升主。

第二。

执行大量查询。

观察是否真正发生读写分离。

因为很多时候。

集群虽然已经部署成功。

真正的问题反而出现在业务接入阶段。

⚠️ 我觉得最容易忽略的一件事情

很多教程做到这里就结束了。

其实真正上线之前。

最好做一次故障演练。

例如：

主库关闭以后多久切换？
VIP有没有漂移？
JDBC有没有自动重连？
查询还能不能正常执行？

这些才是真正决定高可用是否成功的地方。

纸面上的Running，不代表业务真的不会中断。

🎯 写在最后

写到这里，整个读写分离集群其实已经能够部署完成了。

如果只是为了学习，到这里已经足够。

但如果准备上线生产，我更关心下面几个问题。

✔ 主备同步有没有延迟？

✔ 查询是否真正进入备库？

✔ 主库故障切换多久完成？

✔ VIP是否自动漂移？

✔ JDBC是否真正实现读写分离？

这些，也是我后面几篇准备继续分享的内容。

下一篇，我们就来看一个大家最关心的问题：