国产数据库到底行不行？看金仓 KES 如何助力 CRM 系统在线扩容

2022 年 2 月 21 日 20:00 点

正在项目现场支持的我突然接到客户 C 经理的电话，本以为是沟通确认下一次常规数据库运维巡检的时间，但电话那头传来的消息却令人不安。C 经理是 X 企业 CRM 系统的业务管理人员，X 企业 CRM 系统（简称 X 项目）采用了金仓 KingbaseES V8R6 一主一备读写分离集群架构，业务系统自 2021 年 1 月上线以来，一直运行稳定，从未出过差错。但自从上周 X 企业陆续上线了一些新的业务模块后，飞速增长的业务需求使得业务高峰期集群压力急剧增大，业务访问效率大幅降低，业务高峰期甚至出现了访问失败的现象！对于 X 企业而言，CRM 系统是业务的桥梁。访问失败等问题如不能及时解决，将给公司带来难以估量的损失。因此，C 经理希望我尽快赶赴现场支持，定位问题并优化系统。情况紧急，我当即将手上的工作交接给其他同事，着手项目支援的前期准备工作，并通知同事 Z 次日一起去现场支持。

2022 年 2 月 22 日早 8 点

速度 | 分析利器，迅速定位

晨光熹微，我和 Z 抵达现场，在与 C 经理就系统现状简单沟通交流之后, 就迅速和其他业务开发人员、运维人员一起定位问题。根据业务人员反馈，上周陆续上线的这些业务模块主要以信息查询为主，新的业务模块投入使用后，在业务高峰期间并发的访问量非常高，集群主机的 CPU 在业务高峰期的负载峰值也在不断攀升（主机节点 CPU 负载经常达到 90% 以上），导致系统访问性能下降，严重影响了业务的正常访问。在收集了各业务层反应的问题、初步了解系统性能下降的大致原因后，我们凭借多年来的现场支持经验，决定借助 KingbaseES 性能分析利器 KWR，定位具体的性能问题。

性能分析利器 Kingbase Auto WorkloadRepertories

TIPS：KWR 是 KingbaseES 自动负载信息库（Kingbase Auto Workload Repertories），它通过周期性自动记录性能统计相关的快照，分析出 KES 的操作系统运行环境、数据库时间组成、等待事件和 TOP SQL 等性能指标，为数据库性能调优提供指导。

鉴于该项目在集群部署后和业务上线之初就已经完成了 KWR 工具的配置，此次可以直接运行 KWR 工具，快速获取 KWR 分析报告。

步骤 1：数据库主机业务负载分析通过对 KWR 报告中 DB time 的分析，我们了解到了当前数据库的负载情况：DB time =CPU time + Wait time（非空闲等待，非后台进程）KWR 报告显示，此时采样期间的 DB time 远大于 Elasped 的时间，说明此时数据库的负载比较大。

KWR 报告 CPU time 分析

KWR 报告 CPU time 分析 并且通过系统命令检测到当前高峰期 cpu 的负载确实达到了百分之 90 以上。

业务高峰期主机节点 CPU 压力 鉴于此，我们决定进一步通过 Wait Events、TopSQL 来确定 DB time 的具体消耗。

步骤 2：统计和分析高峰期的 SQL

通过 KWR，对在业务高峰期间影响数据库性能的 SQL 进行统计和分析，找出业务高峰期引起数据库性能下降的具体 SQL 语句。

TOP SQL 信息

获取的 KWR 报告中显示，消耗 CPU 资源较多的 SQL 多为 Select 查询语句。此外，我们还发现这些 SQL 语句结构并不复杂，通过对一些慢查询的 SQL 执行计划分析，绝大部分 SQL 的执行计划都比较合理，这些 SQL 在业务低峰时间段测试，其查询响应时间都是毫秒级，基本排除 SQL 语句编写较差引起慢查询，从而导致的性能问题。

小结

通过 KWR 的各种分析，初步结论为：业务峰值期间 CPU 负载高，是近期业务模块的并发访问量急剧增加所导致。目前一主一备的两个节点，主机已经无法承担当前的业务对数据库的访问压力，需要对数据库集群主机进行扩容。

安全 | 全面测试，保障运行

集群扩容方案分析

问题定位清晰之后，接下来就是和业务组讨论集群扩容的具体方式。

集群扩容方式

一般而言，集群扩容可采用两种方式：

垂直扩容 / Scale up：对于物理主机来讲就是提升单台主机的硬件配置（CPU、Memory、Disk 等）。

水平扩展 / Scale out：通过添加节点扩展集群的负载能力。

TIPS：垂直扩容可以采取主备切换的方式，先对备库进行硬件升级，然后做主备切换，再升级原主库主机的硬件，客户端通过集群 VIP 地址访问数据库，不会影响业务的正常访问。但对于物理主机来说，CPU 和 Memory 等资源都存在最大容量限制，超过限制就无法再提升其配置和性能。

水平扩容可以通过增加主机的方式来动态适应业务的需求，尤其是对"写少读多"的业务。理论上水平扩容可以无限扩容，解决了垂直扩容的限制问题

KingbaseES V8R6 读写分离集群通过 jdbc 驱动对客户端的应用进行判断，并遵守相应分发原则来执行读写分离。水平扩容在增加了新的备用节点后，可以将更多对数据库只读的压力分担到多个备库节点上。

本次项目上线的业务，其数据库访问多以 Select 查询为主，由于集群配置了读写分离，对于 Select 的查询可以通过更多的只读节点（备库）进行分担，并且添加新节点都是在线方式，不会影响业务的正常运行。综合前面对业务特点的分析，显而易见，对于当前的 X 项目，在线水平扩容是最佳选择。即使未来 X 企业发展战略发生变化，业务模块访问量下降，还可以在线缩容，缩减集群节点主机的数量并移作他用，不会造成任何资源的浪费。

因此，通过水平扩展增加备库节点的方式来提升此集群的负载能力，解决性能瓶颈，从经济效益和技术可行性来看，都是一个比较好的方案。水平扩容后的集群架构，将从原来的一主一备集群架构扩展为一主两备集群架构，通过新增的备库节点，分担更多的只读查询，分担集群的负载压力。

水平扩容后的读写分离的集群架构

在线扩容操作方式

KingbaseES V8R6 读写分离集群在线水平扩容有两种方式，通过图形化的工具在线添加新节点，或通过"repmgr standby clone"工具以命令行的方式执行新节点添加。

图形化扩容和命令行扩容的对比表

对于生产环境来讲，如果数据库数据量大，通过图形化的工具在线添加新节点会增加主库的网络 I / O 压力。所以我们此次采用字符命令行的方式部署扩容，在降低主库网络 I / O 压力的同时，对新节点的克隆进行定制（如指定数据存储路径、从指定的节点克隆等）。确定了扩容方案后，接下来就需要确定等待新服务器到位期间的保障方案，以及测试环境模拟扩容。

2022 年 2 月 22 日 20:00 点

保障业务运行的临时方案

然而，扩容方案验证和硬件采购还需要两周的时间。如何降低系统负荷，让用户业务系统安全度过这两周的空窗期，是当下急需考虑的问题。

对于降低系统负荷，通常有以下三种方式：

1）业务的性能优化，包括应用层面业务逻辑的优化，以及数据库层面 SQL 运行效率的优化；

2）暂停部分非必要的应用，确保关键应用运行；

3）调整批处理定时任务运行时段，错峰运行。

方案 1，对于 SQL 性能的优化。由于前期我们已经帮客户进行了大量的优化工作，从 KWR 报告的 TOPSQL 看，目前已无优化的余地。而业务层面的逻辑优化，需要涉及应用的大改造，远水解不了近渴。方案 2，暂停部分非必要的应用。C 经理将此方案汇报给上级领导后，遭到否决，因为用户要求所有业务必须可访问。

那么，只有第三种方案可选了。刻不容缓，我们紧急查看了服务器资源利用率的历史曲线图，发现业务的运行高峰在早上 9 点到晚上 21 点之间，而其他时间 CPU 利用率不到白天高峰的一半。如果部分批处理定时任务能够调整到晚上运行，就可以降低白天的 CPU 负荷。我们立即梳理了主节点上操作系统与数据库定时任务，与客户逐个分析每个任务的关键性。幸运的是客户与业务部门沟通后，答应临时降低部分定时任务的白天运行频率，转而在晚上运行。事不宜迟，我们立即调整定时任务，观察实际效果。确认白天时段总体 CPU 有 5% 左右的下降，CPU 曲线也更平滑了，调整取得了立竿见影的效果。又是一个通宵达旦，但业务系统运行暂时得到了保障，令我们暂缓了一口气。接下来还要继续加紧验证测试扩容方案，毕竟调整批处理定时任务只是权宜之计。

2022 年 2 月 24 日 8:00 点

集群水平扩容业务模拟压测

为了确定最终方案的可行性，我们先在测试环境下进行集群的扩容测试。在当前一主一备的测试环境下，采用命令行方式扩容，增加一个新的备库节点。扩容前后分别通过 jmeter 工具模拟业务对集群压测，以验证方案的正确性。测试环境使用命令行扩容，扩容完成总共耗时不到三小时。扩容期间，监控集群运行正常，业务模块可以正常访问。根据回退测试，在扩容期间，在线删除新的备库节点对原集群运行不造成任何影响。通过 jmeter 工具对集群进行性能压测，主要采用 Select 查询语句测试数据库负载，为了能更好的体现测试效果，我们采用了简单的 SQL 查询语句，分别在不同线程数下，对数据库 QPS 的测试。结果显示，测试环境的集群扩容为一主两备的架构后，通过新的备库节点分担只读查询的访问，QPS 相对于扩容前得到了有效的提升，完全满足了当前业务的需求。

测试完成后，我们便与 C 经理一起向领导汇报了包含临时应急处置措施和扩容压测的完整解决方案。X 企业相关领导对我们的方案和效率表示高度认可，最终拍板采用集群水平扩展的方案，来解决当前业务增长产生的性能问题。在原来一主一备的基础上增加一个新的备库节点，构建一主二备的集群架构。接下来就是等新的服务器到场后，在生产环境上实施在线扩容方案。

2022 年 3 月 11 日 8:00 点

可靠 | 在线扩容，专业服务

扩容服务器的硬件网络环境准备就绪，万事俱备。生成环境扩容操作需要有一定经验的技术人员来完成，所以由我亲自操作，同事 Z 从旁监控，双重保险。为减轻对 X 公司当前业务的影响，按照原有的计划于周六的凌晨 12 点，在业务低峰期正式开始在线扩容。白天继续做一些环境准备工作。

2022 年 3 月 12 日 0:00 点

凌晨 12 点准时开始在线扩容。做好数据备份工作后，正式开始操作扩容。

操作步骤如下：

1）配置新节点的系统环境（如网络、ssh 互信、内核资源管理、防火墙配置等）。

2）从已有的节点（备库）上传集群相关目录（除了 data 目录）外，到新的节点。

3）修改新备节点下的 repmgr.conf 配置，指定节点 ip、节点名称、数据存储路径等。

4）在原主库下创建复制槽（replication slots）。

5）在新的备节点执行备库克隆 (-h：指定已有备库节点的 ip)

6）启动新备库数据库服务，注册新的备库到集群完成克隆。

此次生产数据 600G 以上，完成在线扩容实施共花费两个半个小时。在扩容期间，监控生产业务的运行，没有发现生产业务访问和业务的故障问题。凌晨 2 点半，本次集群在线扩容操作顺利完成。扩容结束后，系统运维人员对业务系统的所有模块进行了功能测试，所有业务模块运转正常。功能全部正常，接下来就是等待业务高峰期的系统性能检验。转眼凌晨 5 点半，但我们困意全无。为保险起见，我还是决定对扩容后集群环境先做一个性能压力测试。再次通过 jmeter 工具对集群进行性能压测，测试结果显示，在线扩容构建一主两备的集群架构后，访问性能得到极大的提升，一主两备的架构完全可以承载当前及未来一段时间的业务压力。旭日东升，压测完成后已经早上 7 点，我们正式下班，准备接受下周一正式业务高峰期的检验。

2022 年 3 月 14 日 9:00 点

星期一到了，我们在高峰期间进行性能监控，集群主机节点 CPU 的负载一直都在低位运行，完全达到了扩容前的预期结果，业务访问的效率得到了有效的提升。本次 KingbaseES 读写分离集群在线水平扩容圆满结束。项目扩容顺利完成，终于如释重负。激动并欣慰，作为金仓人，为国产化信息事业建设又出了一份力。C 经理代表业务组对我们金仓数据库的技术服务响应速度和解决问题的能力，表示充分肯定和感谢。保障客户的业务系统数据库正常运行是我们的责任，以后需要再接再厉，为数据库国产化事业添砖加瓦。

结语

本次项目依靠金仓的性能分析利器 KWR、稳定运行的 KingbaseES 集群，以及专业的金仓技术服务团队，通过 KWR 分析能快速定位到问题，金仓 KingbaseES 数据库集群支持在线平滑扩容，所以经过金仓技术工程师分析、测试和操作，迅速解决了业务运行性能瓶颈问题。KingbaseES V8R6 读写分离集群的在线扩容功能，可以实现在线平滑扩容，在不影响企业业务的前提下快速解决企业面临的性能瓶颈问题。并且在企业前期业务需求较少的情况下，只需要投入少量资金，构建最基本集群架构，以满足当前的业务需求，在后期业务需求增大的情况下，只需要按需增加集群的节点，不会造成前期资金大量投入的浪费，提升企业的投入产出比，获取更好的经济效益。

金仓数据库专业的技术服务团队及时响应客户的在线扩容需求，为您提供速度、安全、可靠的技术服务，坚持 7*24 小时为客户保驾护航。