我本人是从2020年开始做国产数据库的替换，彼时赶上华为芯片断供的新闻，和从事芯片的朋友聊起这事。他说了一句话，芯片代工断供，只是大家所看到的最终结果，其实连芯片设计软件都不能自主，说不定还有更多软件是被卡脖子。
说者无心，听者有意。我评估了一下公司手头的数据库，超过一半都是国外的商业数据库。即便是开源的mysql，也有了商业版。如果哪天真到了数据库软件断供那天，不再为中国的企业提供任何服务，我们该怎么办？退回当年大规模用盗版，还是替换成国产数据库？第二天来到公司，我就开始在研究市面上各类国产数据库，也在测试环境开始做一些实验。那段时间同事和领导对我的行为褒贬不一，有的觉得我想法很好，有的觉得我多管闲事。我的理由也很明确，即便现在和我们没有关系，然而刀子砍到自己身上那天真的什么都晚了。后来经过探索和实践，用了一年左右的时间，终于把生产环境的一套oracle替换成了国产数据库，这中间也有很多故事，如果单独写又是一篇长文。从选择到迁移到上线，一个流程下来，让我对国产数据库替换有了实际操作层面的认知。
如果你和两年前的我一样，有这方面的想法，我希望能够通过本文，带来一些启发给你。
part i 换新还是换旧
很多传统企业，尤其是信息化时间比较久的企业，都有大量的老旧系统。因为历史原因，仍然在运行中，有的版本早已经过了支持期限，有的甚至负责开发的公司已经倒闭了。这类老旧系统往往都跑在商业数据库上，依托着商业数据库的稳定以及m6米乐安卓版下载的售后服务，才勉强支撑下去。
这类系统我不建议去替换，除非业务部门牵头，对系统进行重构甚至重新开发。一个新数据库，无论怎么宣传兼容某某数据库，实际真正跑起来，都会有很多你想象不到的坑。老旧的系统在很难找到开发人员的情况下，这些坑靠dba自己是填不上的。强行替换不但会给运维带来很多问题，也会让正常的业务难以为继。这不仅仅只是被人说“xxx跑的好好的，你换掉它干什么？”，而是影响公司业务运营。
对于这类系统，我通常会定期做汇总，xxx系统已经x年没有做过更新，xxx系统原厂也不再提供后续支持，xxx系统数据库版本过低官方已下线等等。提前把相关的风险告知系统负责人或者业务部门，至于是否有预算去改造去替换，不是dba自己能决定的。
与此同时，一些即将立项或者开发进度较为靠前的系统，替换起来就容易很多。这类系统往往可以成为最早的试验田，而这时候兼容xx数据库的优势就发挥出来了。选择一款开发人员在语法和功能上适应更容易的产品，由dba辅助，是可以完成从旧数据库到新数据库的替换工作。这其中如果说服项目经理或者业务部门，需要dba对两种数据库有着较为清晰认知，并且替换的理由也要立得住。切忌为了换而换。
把握住一个大原则，数据库是为应用系统服务的，应用系统是为业务服务的。站在业务的角度，帮助他们降本增效才是最终目的。替换的结果如果达不到，无论新旧数据库，都不要轻易尝试。
part ii 什么样的阶段替换
和成熟的商业数据库或者开源数据库不同的是，绝大多数国产数据库都处在一个告诉发展的阶段。一个大版本更新的周期可能比过往的产品要短，功能的演进性能的提高稳定性的进步，都肉眼可见中发生着。成熟的数据库我们可以按照一锤子买卖的思维去做，安装一个稳定版本，没有大的问题，一直用到这个系统下线，这也就诞生了无数上一部分提及的老旧系统。
然而在替换国产数据库时，这种思维就没法再继续用下去了。稳定阶段还没到来，后续有了大的版本更新，就要做出抉择，是否要升级迭代。这就给了dba一个难题，需要较为准确判断这个数据库产品的生命周期和开发阶段。之前的经验，我会选择先看看各家m6米乐安卓版下载官网或者推送，然后和相关厂商的人去聊一下，你们产品未来两三年年，有什么相关计划？有没有什么大的架构调整或者大的功能变动？
接下来对这些未来可能做的大动作做个评估，会不会对自己未来的数据库管理产生重大影响使得不得不升级。假如我现在使用一个稳定版，如果半年后就必须做升级，那这个时间点，我宁可选择不替换而再等等。每次数据库升级迁移，一定都是要鸡飞狗跳一下，基础设施、应用运维、业务部门都要一起折腾，不是换个磁盘插根内存条那么简单。
在这方面我比较保守，之前替换的时候，先选择了一个稳定版确认了在未来一年内，不会有哪个迭代对系统特别重大的变化后，才选择进行测试，测试环境又用了三个月才进入生产环境。在生产环境刚开始运行的过程中，确实遇到了些许问题，一方面是经验不足，另一方面是产品的某些方面和宣传有出入。经过开发人员的继续开发，平稳跑到现在。
如果你看好的数据库是一个还在急速成长中的产品，那不妨参考一下我的做法。
part iii 替换的一些决定因素
中国的多数企业客户，并不是和互联网大厂一样，有大量的技术人员在支撑。很可能几万人的企业，it部门只有几十人，分摊到各个条线，留给dba的一只手数的过来。有的甚至一个部门只有几个人，还身兼着网管和采购办公电脑的职责。直接采购和二次开发的比重也非常多。
替换多少，怎么替换，一定要和部门的人力配置相关联。假如一个公司就你一个dba，即便是稳定的商业数据库，都让你每天的工作量超负荷，这时候千万不要轻易动替换的念头。因为替换的过程以及后续的运维，将是一个你无法控制的工作量，这其中还包含着你去学习一个新数据库的时间，以及后续犯错填坑的时间。如果反过来，部门里大家职责相对明确，你的工作内容让你游刃有余或者有其他同事可以帮你分担，再去评估替换数据库。对于一些业务量不大，风险和业务部门关系都可控的系统，不妨考虑替换掉一些。
有的系统因为各种产品天生的不足，这类系统可能导致架构上的臃肿，比如常见的mysql hadoop，innodb引擎用来做oltp很不错，但是自身的先天不足，不得不用hadoop来做报表，但是hadoop的长处在于海量数据的存储和离线计算，实时性就差了点意思。如果能有一个产品完成这两样需求，又能精简架构又能提高实时性，何乐而不为。
如果你是在金融行业，或者有着严格的监管要求，一定要提前反复阅读监管文件，并且和公司负责法律合规、信息安全的相关同事进行沟通，逐项核对。确保你要替换的新数据库能够满足每一项监管要求，记住那句话，部分模块合规简称不合规。
还有就是，不要高估自己的学习能力和处理问题的能力。很多资深运维人员，因为经验丰富了，有时候就会产生错觉，面对一个全新的产品，自己也能驾轻就熟趟过去，全然忘记了自己刚入行时候的狼狈景象。然而随着年龄的增长，很可能自己学习新东西的能力已经打了折扣，这时候面对一个新数据库，一定要把自己当成一个门外汉，放低预期。这样在替换的时候，才不至于低估了难度和风险，使得整个项目进度失控。
作为常年和数据库打交道的人，我们都清楚，一个成熟的数据库产品需要时间的磨砺，国产数据库的成长同样也需要我们给予耐心，真正做到自主可控，可能5年可能10年甚至更久。保持一颗接纳并批判的心，去面对国产数据库，做得好我们赞扬，做得差我们指出，才是一个积极地态度。