《高可用读写分离集群实战》系列一从单机到高可用第一次部署读写分离集群我踩了不少坑 本文不是官方文档翻译而是一次完整部署读写分离集群时整理下来的学习笔记希望能给第一次接触高可用数据库的同学一些参考。前言前段时间公司准备把一个业务系统升级。领导只提了两个要求。数据库不能停。查询不能越来越慢。刚开始我还觉得这不是很简单吗搭一套主备集群数据库坏了自动切换不就解决了吗结果真正部署以后才发现高可用和读写分离其实是两件既相关又完全不同的事情。很多项目虽然已经做了主备但所有查询还是压在主库上备库几乎一直闲着。随着业务越来越大CPU、IO、连接数不断上涨即使数据库没有故障性能也开始出现瓶颈。后来重新规划了读写分离架构把查询压力分散到备库以后数据库资源利用率明显好了很多。这篇文章我准备结合自己的部署过程把整个搭建流程整理一下。 本文主要内容为什么很多系统做了主备还是慢高可用和读写分离到底有什么区别一个标准读写分离集群长什么样部署之前需要准备什么第一次部署最容易踩哪些坑 为什么很多项目做了主备性能还是没有提升刚接触数据库集群的时候我最大的误区就是只要有主备就是高性能。后来才发现完全不是。很多公司的架构其实都是这样。业务系统 │ 主数据库 │ 备数据库数据库确实能够自动同步。主库坏了也能切换。但是……所有查询还是访问主库。备库除了同步数据几乎什么事情都没做。换句话说CPU还是主库的。IO还是主库的。连接数还是主库的。备库只是保险。它提升的是可靠性而不是吞吐能力。直到后来接触读写分离以后我才真正理解为什么很多互联网系统都采用这种方案。 什么是真正的读写分离真正的读写分离更像下面这样。Application │ JDBC 读写分离驱动 │ ┌──────────────┐ │ VIP │ └──────────────┘ │ ┌──────────────┐ │ Primary 主库 │ └──────────────┘ │ Streaming Replication │ ┌──────────────┐ │ Standby 备库 │ └──────────────┘简单来说写请求全部进入主库。查询请求自动发送到备库。如果备库有多台还可以进一步分担查询压力。整个业务几乎不用修改SQL。JDBC驱动负责完成路由。第一次看到这里的时候我还专门写了一个小Demo验证。连续执行几百条SELECT以后再去查看两个节点的连接数发现查询请求已经开始均匀落到备库。这种感觉还是挺有意思的。 我的理解高可用解决的是不能停读写分离解决的是跑得快很多文章都会把这两个概念放在一起讲。其实我觉得可以分开理解。高可用关注的是✅ 数据不能丢。✅ 主库故障能够切换。✅ 业务尽快恢复。而读写分离关注的是✅ 查询压力分散。✅ 主库压力降低。✅ 整体吞吐能力提高。两者配合起来才是真正意义上的生产集群。 正式安装之前我建议先做这几件事情这里也是我第一次部署踩坑最多的位置。很多人一拿到安装包就开始执行脚本。其实真正花时间的反而是前期规划。我现在都会提前整理下面几个信息。第一节点规划建议至少准备两台服务器。node1 Primary 10.12.11.192node2 Standby 10.12.11.193如果业务比较重要可以后面继续增加备用节点。不过第一次学习两台已经足够。第二VIP规划这里很多人都会忽略。VIP其实就是业务访问数据库时统一连接的地址。以后主库切换。VIP也会自动漂移。应用始终连接同一个地址。不用修改配置。第一次看到这个设计的时候我觉得还是挺巧妙的。第三网络一定提前确认这里真踩过坑。我第一次部署的时候。SSH互信没有配置完成。结果cluster_install.sh一直执行失败。后来重新检查发现。两台机器虽然能够ping通。但是root登录限制了SSH。所以部署脚本一直卡在那里。后来重新配置互信以后十几分钟就完成部署了。如果提前检查网络其实完全可以避免。⚙️ 环境准备这里官方要求其实已经比较完整。我一般只检查几个重点。✔ 节点时间一致✔ SSH互信正常✔ 防火墙端口放通✔ 磁盘空间充足✔ kingbase用户提前创建例如useradd-u2000kingbasepasswdkingbase创建完成以后再统一授权目录。这样后面安装基本不会因为权限报错。 一键部署开始真正开始安装以后反而没有那么复杂。把软件包上传到主节点。进入目录。cd/home/kingbase/software先执行互信脚本。shtrust_cluster.sh确认所有节点互信完成以后。再开始部署。shcluster_install.sh这里建议不要急着关闭窗口。脚本会自动完成软件安装初始化数据库创建集群注册节点配置流复制启动服务整个过程基本都是自动完成。 怎么确认部署成功安装结束以后。我一般第一件事情不是登录数据库。而是查看整个集群状态。cd/home/kingbase/cluster/install/kingbase/bin ./repmgr cluster show如果看到类似下面结果。ID Name Role 1 node1 primary 2 node2 standby说明主备已经建立完成。当然。这里不要急着结束。我一般都会继续做下面两个验证。第一。停止主库。看看备库能不能自动升主。第二。执行大量查询。观察是否真正发生读写分离。因为很多时候。集群虽然已经部署成功。真正的问题反而出现在业务接入阶段。⚠️ 我觉得最容易忽略的一件事情很多教程做到这里就结束了。其实真正上线之前。最好做一次故障演练。例如主库关闭以后多久切换VIP有没有漂移JDBC有没有自动重连查询还能不能正常执行这些才是真正决定高可用是否成功的地方。纸面上的Running不代表业务真的不会中断。 写在最后写到这里整个读写分离集群其实已经能够部署完成了。如果只是为了学习到这里已经足够。但如果准备上线生产我更关心下面几个问题。✔ 主备同步有没有延迟✔ 查询是否真正进入备库✔ 主库故障切换多久完成✔ VIP是否自动漂移✔ JDBC是否真正实现读写分离这些也是我后面几篇准备继续分享的内容。下一篇我们就来看一个大家最关心的问题如果主库突然宕机整个数据库集群到底经历了什么备库又是怎样一步步接管业务的
《高可用读写分离集群实战》系列（一）
《高可用读写分离集群实战》系列一从单机到高可用第一次部署读写分离集群我踩了不少坑 本文不是官方文档翻译而是一次完整部署读写分离集群时整理下来的学习笔记希望能给第一次接触高可用数据库的同学一些参考。前言前段时间公司准备把一个业务系统升级。领导只提了两个要求。数据库不能停。查询不能越来越慢。刚开始我还觉得这不是很简单吗搭一套主备集群数据库坏了自动切换不就解决了吗结果真正部署以后才发现高可用和读写分离其实是两件既相关又完全不同的事情。很多项目虽然已经做了主备但所有查询还是压在主库上备库几乎一直闲着。随着业务越来越大CPU、IO、连接数不断上涨即使数据库没有故障性能也开始出现瓶颈。后来重新规划了读写分离架构把查询压力分散到备库以后数据库资源利用率明显好了很多。这篇文章我准备结合自己的部署过程把整个搭建流程整理一下。 本文主要内容为什么很多系统做了主备还是慢高可用和读写分离到底有什么区别一个标准读写分离集群长什么样部署之前需要准备什么第一次部署最容易踩哪些坑 为什么很多项目做了主备性能还是没有提升刚接触数据库集群的时候我最大的误区就是只要有主备就是高性能。后来才发现完全不是。很多公司的架构其实都是这样。业务系统 │ 主数据库 │ 备数据库数据库确实能够自动同步。主库坏了也能切换。但是……所有查询还是访问主库。备库除了同步数据几乎什么事情都没做。换句话说CPU还是主库的。IO还是主库的。连接数还是主库的。备库只是保险。它提升的是可靠性而不是吞吐能力。直到后来接触读写分离以后我才真正理解为什么很多互联网系统都采用这种方案。 什么是真正的读写分离真正的读写分离更像下面这样。Application │ JDBC 读写分离驱动 │ ┌──────────────┐ │ VIP │ └──────────────┘ │ ┌──────────────┐ │ Primary 主库 │ └──────────────┘ │ Streaming Replication │ ┌──────────────┐ │ Standby 备库 │ └──────────────┘简单来说写请求全部进入主库。查询请求自动发送到备库。如果备库有多台还可以进一步分担查询压力。整个业务几乎不用修改SQL。JDBC驱动负责完成路由。第一次看到这里的时候我还专门写了一个小Demo验证。连续执行几百条SELECT以后再去查看两个节点的连接数发现查询请求已经开始均匀落到备库。这种感觉还是挺有意思的。 我的理解高可用解决的是不能停读写分离解决的是跑得快很多文章都会把这两个概念放在一起讲。其实我觉得可以分开理解。高可用关注的是✅ 数据不能丢。✅ 主库故障能够切换。✅ 业务尽快恢复。而读写分离关注的是✅ 查询压力分散。✅ 主库压力降低。✅ 整体吞吐能力提高。两者配合起来才是真正意义上的生产集群。 正式安装之前我建议先做这几件事情这里也是我第一次部署踩坑最多的位置。很多人一拿到安装包就开始执行脚本。其实真正花时间的反而是前期规划。我现在都会提前整理下面几个信息。第一节点规划建议至少准备两台服务器。node1 Primary 10.12.11.192node2 Standby 10.12.11.193如果业务比较重要可以后面继续增加备用节点。不过第一次学习两台已经足够。第二VIP规划这里很多人都会忽略。VIP其实就是业务访问数据库时统一连接的地址。以后主库切换。VIP也会自动漂移。应用始终连接同一个地址。不用修改配置。第一次看到这个设计的时候我觉得还是挺巧妙的。第三网络一定提前确认这里真踩过坑。我第一次部署的时候。SSH互信没有配置完成。结果cluster_install.sh一直执行失败。后来重新检查发现。两台机器虽然能够ping通。但是root登录限制了SSH。所以部署脚本一直卡在那里。后来重新配置互信以后十几分钟就完成部署了。如果提前检查网络其实完全可以避免。⚙️ 环境准备这里官方要求其实已经比较完整。我一般只检查几个重点。✔ 节点时间一致✔ SSH互信正常✔ 防火墙端口放通✔ 磁盘空间充足✔ kingbase用户提前创建例如useradd-u2000kingbasepasswdkingbase创建完成以后再统一授权目录。这样后面安装基本不会因为权限报错。 一键部署开始真正开始安装以后反而没有那么复杂。把软件包上传到主节点。进入目录。cd/home/kingbase/software先执行互信脚本。shtrust_cluster.sh确认所有节点互信完成以后。再开始部署。shcluster_install.sh这里建议不要急着关闭窗口。脚本会自动完成软件安装初始化数据库创建集群注册节点配置流复制启动服务整个过程基本都是自动完成。 怎么确认部署成功安装结束以后。我一般第一件事情不是登录数据库。而是查看整个集群状态。cd/home/kingbase/cluster/install/kingbase/bin ./repmgr cluster show如果看到类似下面结果。ID Name Role 1 node1 primary 2 node2 standby说明主备已经建立完成。当然。这里不要急着结束。我一般都会继续做下面两个验证。第一。停止主库。看看备库能不能自动升主。第二。执行大量查询。观察是否真正发生读写分离。因为很多时候。集群虽然已经部署成功。真正的问题反而出现在业务接入阶段。⚠️ 我觉得最容易忽略的一件事情很多教程做到这里就结束了。其实真正上线之前。最好做一次故障演练。例如主库关闭以后多久切换VIP有没有漂移JDBC有没有自动重连查询还能不能正常执行这些才是真正决定高可用是否成功的地方。纸面上的Running不代表业务真的不会中断。 写在最后写到这里整个读写分离集群其实已经能够部署完成了。如果只是为了学习到这里已经足够。但如果准备上线生产我更关心下面几个问题。✔ 主备同步有没有延迟✔ 查询是否真正进入备库✔ 主库故障切换多久完成✔ VIP是否自动漂移✔ JDBC是否真正实现读写分离这些也是我后面几篇准备继续分享的内容。下一篇我们就来看一个大家最关心的问题如果主库突然宕机整个数据库集群到底经历了什么备库又是怎样一步步接管业务的
