我重生了
重生到了在甲方做DBA的第一天
前世的我，运维技艺平庸，欠缺应变能力。
往昔，企业规模尚小，经济实用的单机数据库足以驱动业务前行，为彼时之选，既经济又灵活。
然而，随着企业版图与业务复杂度的双重扩张，单机数据库的短板日益凸显：历经长久运行，用户量剧增，数据库读写需求井喷，响应迟缓，用户体验大打折扣。
我孤军奋战，“单”战心惊（意指单机模式下我一人战斗到心脏报警）维持数据库的日常运行。
终因一“单”之失（意指单机下故障导致业务中断和数据丢失，个人KPI亦随之崩塌，本打工人无能狂怒的状态），满盘皆输。
领导对我的能力持保留态度，绩效评定为D。
我在工位加班时迷迷糊糊睡着了，再一睁眼，竟然回到了在甲方做DBA的第一天。重来一世，我誓要改写命运！
因为我在耳边听到了【金仓数据库】呼唤~
“我已为你准备了单机在线扩集群功能，告别单机瓶颈，轻松拥抱高可用，请尽情使用吧！”
单机扩集群策略如何选？简单
单机向集群的转变是应对业务增长和技术挑战的自然选择，单机扩展成集群后，不仅能增强系统的处理能力、稳定性和可用性，还能提高资源的利用效率和整体业务的灵活性。
单机扩展成集群的策略有多种。金仓数据库就提供了数据迁移、离线扩展与在线扩展三种单机扩集群的方式，让我可以根据业务需求、资源可用性、成本预算和技术支持等因素进行综合考虑。
单机扩集群架构图
那么，我司的系统适合什么方式呢？
为了确定最适合我司的扩展方式，我紧急召唤来金仓工程师出谋划策（金仓数据库不仅功能完善，服务效率和质量也是杠杠的，此处应有点赞！）
他们结合我司的数据库表现，从业务类型、资源、架构和停机时间等方面进行了全面分析：
1
业务类型分析
分析发现我司系统读写占比约7:3，读业务占比较大。
2
资源分析
通过性能监控工具监控系统资源、CPU、内存、磁盘I/O等，发现由于处理大量的SQL查询和事务，导致CPU使用率居高不下。
3
架构分析
当前使用的是单机数据库，如果单机数据库出现问题，整个系统都会受到影响。
4
停机时间分析
按客户需求，数据库避免停机时间过长，影响业务，需快速解决此问题。
通过对业务和资源的分析，结合当前单机架构无法通过简单的硬件升级来提升性能。
最终，金仓工程师提出使用主备集群（读写分离）的方案来扩展单机数据库，将读操作分散到多个节点上，以减轻主服务器的压力。同时，结合我司对停机时间的需求，提出使用已有数据库在线快速升级集群方案，在扩容的过程中，确保业务零中断。
业务无感，快速实施？易如反掌
在线扩展方式操作简单，能更好地保护系统连续性，特别适用于在面对高负载、大数据处理和业务连续性需求时快速升级现有基础设施的状况。这和我司的需求非常匹配，我双手点赞并要求尽快实施。
实施过程也异常的快速、流畅且顺利。
具体的实施步骤如下：
调整已有单机数据库配置
确认当前单机数据库路径与相关配置是否符合扩展集群要求，不符合做对应修改。修改完相关配置的单机数据库路径为：/home/kingbase/KES/db/data
创建主数据库
本次实施使用GUI部署工具来扩展集群，首先创建主数据库。打开部署工具，使用已有单机数据库创建集群主机节点：
配置集群参数，选择已有data路径
添加节点信息
注册主节点
创建备数据库
主数据库创建完成后，可继续在线创建备数据库。
添加节点信息
注册备节点
检查验收
部署完成后检查集群状态，集群状态正常。
在部署过程中，我们对业务进行了全程监控，确保在线扩展过程对业务无影响。
部署完成后，新的集群数据库表现出色，不仅能够处理更大的数据负载和更高的并发请求，还显著提升了系统响应速度和吞吐量。同时，它还能够动态调整资源分配，优化资源使用效率，避免单点过载，提高了服务的连续性和可靠性。
至此，我的难题得到完美解决。
从“单”战心惊到同舟共“集”（集群模式下计算节点可以共享资源，提升整体的资源利用率），金仓单机数据库在线扩展集群，让我深刻体会到了技术带来的力量。
不仅在线扩展过程简单易操作，业务无感；集群模式下，系统资源的利用效率和整体业务的灵活性都得到了飞速提升。
这令我感“集”不尽（形容我对集群技术所带来的性能飞跃与极致易用性满怀无比的感激之情）
而我也可以有更多的时间放到数据库的学习上，拥有从选型到部署升级到运维管理的全栈技能。
Oh，甲方生活就像我的人生，易如反掌！
这爽文男主的美梦终究还是醒了。
没有重启按钮让我回到在甲方做DBA的第一天，但是金仓数据库的强大功能是真的。
把握现在即刻使用，从此刻开始亦是我们的新生。
单机数据库在线扩展成集群，从单打独斗到同舟共“集”。告别单机瓶颈，轻松拥抱高可用！
你也来试试看～
来源：产品研发中心
