再过去多年的工作中，数据库迁移是我作为dba的重要工作之一。做过dba的朋友都知道，这是一项高风险低回报的事情，做好了别人觉得理所应当，做不好轻则挨骂重则丢工作。以至于我无论何时何地，只要涉及到生产环境的数据库迁移总是战战兢兢，生怕遇到各种问题。然而，这些东西永远是作为一个dba所绕不过去的，也是对我们个人能力和经验的重要提升和考验手段。我很想在此刻，给大家分享些我自己对数据库迁移的心得。
实际上“为什么迁移”这个问题不仅仅是技术问题，还有很多技术以外的原因。我对此做了如下总结：
技术原因
技术原因往往是由一个企业的it部门所发起，通常是因为基础设施、数据库、应用软件本身的某些问题而开始的迁移。这类迁移好处是迁移的目的性比较明确，能否解决问题也是更容易预判到的。但是难就难在让业务们去理解，为什么要迁移，甚至很多时候，业务部门是反对的。迁移成功了还好，失败的时候就会不可避免地陷入："xxx好好的，你把它换掉干什么你告诉我？脸都不要了”的境地。
如果再次细分，还可以再分出几个子原因来：
原因1，eol（end of life）
任何软硬件，都是有自己的服役周期的，往往到了一定年限，为了保障业务的连续性并降低风险，基础设施部门会主动发起迁移。
一个硬件服务器或者一套存储，往往用几年就到了故障频出的时候，这时候如果再迁移就很被动，所以往往it部门会选择提前开始计划迁移，例如以前我所在金融企业，生产环境的武器到第四年就要开始制定迁移计划，五年之内必须强行下线，做不到的话是要扣it部门的kpi。
而操作系统的更新换代，也是很常见的，甚至有时候还有一些黑天鹅事件，比如前两年centos不再提供更新，就迫使很多企业需要去寻找centos的替代版本。如果用的是windows服务器，也必须要考虑每隔几年将微软不再支持的版本替换成还在服役的版本。
数据库版本的更迭，常常出现在一些老系统中，比如曾经的oracle11.2.0.4，其服役跨度超过了10年，可是到了oracle不再提供官方支持的那天，大家也不得不要去考虑要不要迁移到12c、19c或者更高的版本。
当然，还有一些比较冷门的因素，比如某个人离职了。以前工作过的一个企业，有一位驻场的老师傅，维护着90年代版本的一套老数据库，随着他即将退休，这套上古版本的数据库也将陷入无人会运维的尴尬境地，考虑再三，我们还是决定在他退休之前迁移到了新版本中。
原因2，应用系统变化
这部分往往是应用系统部门发起较多，基础设施部门评估之后响应。相对来说，还是在it部门内部，沟通与风险都还容易评估和量化。
一些老旧的系统，往往会出现一个尴尬境地，当年的开发商公司已经没法提供服务，或者人员更迭或者倒闭或者被收购或者转型，只能另起炉灶重新开发。而当年用的数据库可能也已经不再适合当下的场景，需要重新评估，将旧数据迁移到新环境。
也有的时候，会出现同一个软件开发商，产品线发生了重大更迭，整个技术栈变了，随之带来的就是使用的数据库版本或品牌发生变化。以我过去的经验，这种情况相对还好，因为软件开发商回去评估迁移的各种问题，与dba沟通。
也有可能是系统架构发生了变化，以前是集中式现在变成分布式，过去的数据库类型已经没法满足现在的应用程序需求，只有替换一个更合适的，这时候迁移不可避免。
当然，也有可能是上下游系统发生了变化，尤其是在一些边缘系统中会发生。核心系统的数据库变了，为了更好地与其对接，也要更换外围数据库的种类或版本，确保业务能够持续高效进行。
原因3，基础设施变化
过去几年里，以公有云为代表的基础设施变化和发展有目共睹，在运维和成本的优势面前，很多企业都面临着基础设施的巨大变化，这也对数据库迁移产生了新的要求。
大企业往往喜欢用混合云，既有私有云又有公有云。数据库上云，既有私有云也有公有云，这种情况下就必须要迁移。而我们都知道，不是每种数据库都能平滑迁移到云上的，基础设施的巨大差异一定会带来很多不同之处，这就使得数据库迁移是一个大难题。
小企业有的直接把托管机房替掉，所有的服务全都上公有云，有时候还不只一家云服务商，一个数据库实例可能拆分到好几个云厂商的服务器上，又要保证兼容性、性能和稳定性。这也让很多dba头大。
当然，这几年还有其他趋势，就是下云，前一阵子一个朋友跟我说，他跳槽了，去了一家制造业巨头当项目负责人。项目就做一件事，把各路公有云的系统都迁回到自己的私有云，预算好几个亿。就为了整个企业的系统和数据是自主可控的。
非技术原因
如果说技术原因是来自于it部门，那么业务原因往往就是it部门无法决策的，只能被动地去接受。甚至很多时候，迁移不一定是降本增效，反而会带来更多无穷的麻烦。甚至我遇到过业务部门负责人拍着胸脯说“全公司没有人比我更懂xxx数据库”。胳膊拧不过大腿，作为纯粹的成本部门，it部门在强势的业务部门面前是没有多少议价权的，尤其是那些出预算大头的业务部门。
顶着压力跟进吧，大概有这么几个子原因：
原因1，业务变化
一个企业要生存发展 ，肯定是在动态变化中的，业务的定位随时随地都可能变，那么服务于业务的系统也需要随之变化。
比如某个时刻，因为某个突然而来的变化，业务量开始暴涨，原有的资源配置已经无法支撑，应用系统和数据库都需要扩容。限制于基础设施和数据库本身架构，可能无法有效扩展资源，只能迁移到新的硬件或者新的数据库中，这就使得数据库迁移在所难免。
反过来，也有可能某个业务因为边缘化，以后不会再有太多业务，而资源分配还是在高成本的硬件上，为了降低成本，把它迁移到成本更低的硬件或者数据库中，也是常有的事情。
平衡好心态，数据库是给业务系统服务的，业务系统是给业务服务的，跟着业务变化而做的数据库迁移是正常的。
原因2，成本原因
十几年前轰轰烈烈的去ioe，很大程度上是因为一些企业投入了太多的成本在这方面。但是也需要明确的是，不是每家企业都有这个能力搞去ioe，技术储备和人员编制限制了多数企业的去ioe能力。
很多传统行业的it部门一共也没几个编制，摊到数据库头上甚至没有，选择最稳定可靠的产品才是最优解。而稳定可靠的产品就可能带来高成本的问题。当然，这其中还是有一些企业做到了更加精细化管理，哪些系统重要性不强，业务量不大可以迁移到开源，哪些系统注定无法摆脱成熟的商业数据库。中间能够节省出来的成本还是很可观的。而这一过程同样会遇到数据库迁移的需求。
除了软硬件成本，人员的成本也是一个问题。之前公司的一个子公司业务量越来越大，我们顶多只能帮忙保障可用性，于是打算招一个全职dba来做。但是这些系统在不同时期建设，用的数据库五花八门，招聘面试了一些候选人，没有一个能把所有数据库都熟悉，搞不好要招两个人。最后我们领导和他们领导开会，大家对现有的数据库做了分析，最后发现，一些边缘系统的数据库，其实都可以迁移平替，能把数据库的种类缩减一下，这样一来，只招一个dba即可。
原因3，信创
贸易战以来的这几年，信创是任何中国的it从业者都无法回避的。而数据库也是信创的重点项目之一，从20年开始，我在工作岗位上就在和一些国产数据库打交道，也在尝试把一些不怎么重要的系统迁移过去。
这样的场景在未来几年，在一些国资企业，只会越来越多。甚至听说有些企业已经下达了明确指标，几年之内将国外的数据库替掉百分之多少，使用国产数据库的比例不得低于多少等等。这对于我们数据库从业者来说，是一个幸福的也伴随着阵痛的过程。谁能在这一过程中学习到更多新数据库的使用和迁移技巧，无疑会给后续的工作带来更多的空间。
有关迁移的内容，我想通过三篇文章来写完，第一篇为什么迁移写到这里也接近尾声。因为个人经历所限，肯定存在着以偏概全的情况，如果有不完整不准确之处，还望指正。