随着近些年来数据库的变化，正有越来越多的企业面临将传统数据库迁移到开源或新型商业产品上。在这一过程中，会面临诸多问题。这里就将常见的一些问题整理出来，希望能够在数据库选型及评估数据库迁移风险等方面有所帮助。为了描述清晰，我将整个迁移过程划分为几个阶段，其中橙色标识工作为数据库团队来支持。下面将就每个阶段，详细展开说明。
1. 阶段：迁移准备
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1). 迁移规划
在进行迁移之初，首先要对迁移工作做个整体规划，制定好对应的原则方针。例如明确迁移范围、迁移方式、是否可停机、窗口期等等。这些信息是作为后续迁移的指导性原则，迁移方案的制定很多需依靠这一规划。要避免出现快要迁移，发现预期不符合要求的情况，在提前做好必要的规划。此外，除技术因素外，其他如组织、管理、资源等，也在这一阶段一并考虑。迁移是个很复杂的过程，涉及的方方面面很多，尽量在项目之初就有个全面的掌握。
2).业务梳理
要完成数据库迁移，上层的业务系统也是需要考虑的，甚至在某种程度讲，配套的应用迁移更加重要，在后续的迁移过程中占比也更高、难度也更大。因此，在迁移准备阶段，就对涉及的业务有个全面的梳理非常有必要。这里需要梳理的信息，非常宽泛。包括但不限于对业务系统涉及的软硬件环境、与数据库交互、业务系统间调用关系等。后续在做应用系统改造规划中，上述信息非常重要，其有助于评估工作难点、工作量等。这里举个例子，某系统之前使用Oracle，开发采用C语言，在迁移到某国产库时发现，数据库不支持C driver，好不尴尬。
3).方案选型
在做好业务梳理后，就是数据库选型。这一过程也是迁移准备阶段比较耗时的一个工作。如何从众多的数据库产品中选择一款符合自己要求的，要考虑的因素很多。比较推荐的做法，是在公司内部之前就制定出推荐的方案矩阵，根据对数据库能力要求、系统重要程度等，制定一个产品选型矩阵。如果前期有这个基础，就比较简单，只要按图索骥即可。如果没有的话，需要从头完成一系列的工作，包括初始调研、技术评估、数据库评测（功能、非功能、业务等）、适配性评估等。这里强调一个原则就是尽量在方案选型中保持最大的自由度，即不绑定单一厂商，随时保持可替换能力。因此在方案选型中，不能本着业务少改造、迁移最简单、成本最低的方案，而是应选择长期可替代的原则。推荐的做法是选择兼容通用协议的产品，尽量弱化数据库端能力，选择使用标准数据库功能的产品最好。
4).技术培训
在方案选择完毕后，需进行技术培训。这里说的培训，包含对研发、运维等多方面。对研发人员的培训，着重阐述此数据库在架构设计、结构优化、SQL语句等方面与原有数据库的差异。如选择通用性产品，则此处的工作较少，也就是方便进行其他库间的迁移。这里面有个原则就是不迁就研发，该做的必要修改还是要修改。例如，在很多去O工作中，为了尽量减少迁移工作，很多项目选择兼容Oracle语法、甚至存储过程的产品。此类产品确实减少了迁移工作量，但从长远角度来看并不是一个很好的选择。对运维的培训，则侧重如何将这种新的数据库融入到现有的运维体系中。特别是当前很多分布式架构数据库，与传统集中式数据库不同，其对于运维带来的挑战也更大。
2. 阶段：迁移评估
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1).资源评估
做好准备工作后，开始启动之前，根据之前梳理的业务情况、所做的数据库选型等信息，开始做必要的评估工作。这里的评估主要是为了后续迁移改造做好准备。首当其冲的就是资源评估，即完成上述迁移所需资源。这里有个隐藏的工作，就是相关的技术方案需要制定出来，包括数据库及应用端的。毕竟数据库能力不是一对一对等的，因此架构上会有很多调整甚至是重构。但这里所做的评估，相对还是比较粗的，因为很难对资源消耗有个细粒度的描述，做后者的前提是有完整的评测数据为基础。为什么在这个阶段就要做此工作呢？主要是因为很多传统企业是采用预算制，需要提前很长周期做好后续的采购规划。因此将资源评估工作做了前置。
2).应用评估
在这个阶段要完成在数据库选型确定后，应用的评估工作。包括应用方案的调整（甚至重构）、应用的代码修改量、可能潜在的风险等等。这里主要是由应用架构师来完成上述评估。
3).对象评估
完成应用评估后，下面就是数据库评估的。其评估的第一项就是对象评估，即对数据结构的评估。数据库的能力层次不齐，原有的数据结构大概率都无法直接复用了，需要进行必要的调整甚至重新设计。这里有个建议，就是尽量减少数据库端复杂对象的使用，尽量只考虑表及索引的设计，其余包括视图、序列、触发器、存储过程、函数、包等都通过外部的等价设计来完成。这点主要是出于减少对数据库的依赖所提出的，毕竟后面这个功能的实现差距非常大。当然，随之带来的外部等价实现的工作量也需要进行评估。此外，如果是分布式数据库方案，还需要考虑例如分片策略等。这里有个常见的通病，就是将原有设计原封不动地在新环境中落地，然后修改语法不兼容的部分就算是完成这一过程。其带来的后果，往往是上线后问题频出。
4).SQL评估
对象评估之后，开始对SQL语句的评估。较之前的经验，这部分也是较难评估的。比较推荐的做法是抓取源端的全量SQL，根据掌握的目标库的适配能力，做此评估工作。例如之前在去O的工作中，就从下面几个维度来评估SQL，包括了SQL复杂度（多表关联、文本过长等）、Oracle方言语法、特有语法（函数、伪列等）等。这些评估出的SQL，后续都将作为后续修改的依据。这里存在一个难点，就是两种数据库有相同SQL，但处理效果是有差异的情况，这些可能导致非预期的行为，也最好筛选出来。上述可通过简单工具扫描SQL文本完成，例如我之前分享的一个小工具。
3. 阶段：迁移改造
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1).对象改造
对象改造，对数据对象进行改造。有些对象仅做简单的映射修改就可以了，有些则需要大的重构，甚至需要拆分、组合处理。很多对象（特别是复杂对象或重计算类对象），建议从数据库端剥离，在上层等价实现。因此对象改造工作，不仅仅是DBA的工作，也有部分是需要应用研发参与的。针对上述修改工作，特别是一些关键业务表，是需要通过一定手段进行验证测试的。
2).SQL改造
SQL改造，往往是在整个迁移过程中，最为浩大的工作。这主要是由于SQL代码散落在应用各处，需要统一修改。如果使用了OR Mapping工具还好，如果有硬code，改起来还是挺吃力的。目前有很多工具（包括开源的），通过指定源和目标库，输入SQL语句协助完成改造工作。但这种方式，往往也仅仅起到辅助作用，转换后的结果还是需要人工的审核修改工作。要保证语义等价，也要保证执行效率等等。
3).应用改造
配合迁移工作，应用也存在改造的工作量。例如有些在数据库端实现的逻辑，是需要改在应用端实现的；有些应用本身在新数据库架构下就需要进行适配性改造等等。
4).功能测试
在数据库改造（对象 SQL）和应用改造均完成后，还需要一个关键步骤—功能测试。按业务功能拆分，针对每个独立功能，从应用侧角度进行测试验证，来保证上述改造的结果是正确的，性能是符合预期的。此处的功能测试，与后面的上线交割的功能测试不同，更强调是以小的应用单元为测试目标。这样便于随时修改，随时测试。
4. 阶段：迁移数据
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1).迁移方案
改造工作完成后，就进入了迁移数据环节。在迁移之初，最先确定的是迁移方案，这主要取决于对源目标端的数据库、物理环境、迁移窗口、是否并行、是否回退等诸多因素。在大的方面可分为应用侧同步、数据库侧同步、存储侧同步三种方式，各有优势点吧。个人建议，如果能在应用侧处理，尽量在应用侧；其主要原因是与业务结合紧密、同步验证容易、方便并行回退等等。但这种方案的缺点在于，需要应用侧有大量修改工作，无法形成统一标准的方案。一般针对核心、重要的系统，建议采取应用侧同步的方式。针对数据库、存储端同步方案，一般都是较为通用的方案。下文重点讲述数据库同步的方式。
2).结构迁移
结构迁移，是将数据结构的迁移。一般这一过程是可以提前完成的。数据结构确定后，即可完成这一过程。不与后面数据同步放在一起，是为了便于出现问题时的排查分析。
3).全量迁移
如数据规模很大，可将整个过程划分为全量 增量迁移两部分。全量同步，一般是可离线、静态去做，通过备份恢复、导入导出等方式，将绝大部分数据迁移过去。这部分不放在停机窗口中，可提前进行。并在迁移之后，记录一个位点。
4).增量迁移
增量迁移，从全量迁移记录位点开始。根据迁移技术本身，可采取停机或不停机的方式。一般都是通过追log的方式，逐步追齐数据，并短时静默应用，完成数据最终达到一致的状态。
5. 阶段：上线交割
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1).SQL审核
在上线交割之前，还需要完成部分前置工作。SQL审核，是为了保证SQL上线前的运行质量。SQL审核细分，可分为事前、事中、事后审核，这里更多指事前审核部分。即在开发过程中，针对SQL运行情况给予评估判断，来保证上线后的质量可控。一般是通过预定义一组规则，完成对语句的审核。这一过程贯穿在整个开发过程中。
2).数据校验
数据迁移后，在上线前还需要对数据同步后的质量有所判断，这就引入数据校验的初衷。严格来讲，这是数据质量保证的一部分。其作用是对同步两边的数据是否一致做出判断，来整体把握同步质量，也是为后面是否正式切换的判断依据之一。这里存在几个难点，一是海量数据如何快速比对，二是异构条件下数据如何比对，三是两侧数据同步变化时如何比对？目前已经有些产品能够支持较为完整的数据校验功能。个人也是比较建议，在数据迁移后进行对比。虽然这里有些成本，但要比运行一段时间后发现差异而无法回退好的多。
3).功能测试
在正式迁移前，针对迁移后的全量环境做完成的业务功能测试是非常必要的。需要对迁移后的结果有个全局的掌握。一方面可以验证整个迁移过程是否OK，另一方面也可为后续正式迁移提供基线判断标准。
4).性能测试
在功能测试的同时，还需保证迁移后的性能满足预期设定，因此性能测试也必不可少。这里可以使用数据库侧进行性能测试，但更建议是从应用侧完成性能测试，因为后者是从用户视角，更具有说服力。
6. 阶段：运行保障
人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
1).数据库运维
迁移完成，系统上线后就进入到运行保障阶段。从数据库来说，提供的基本能力之一就是基于新数据库架构下的运维能力。对于一个新的选型来说，需要将新品种数据库纳入到整体的运维体系中，这其中涉及的工作不少。一般是需要提前规划完成的。
2).高可用保障
除了日常运维外，高可用被独立出来，主要是这部分重要性很高。新的数据库选型，代表着运行风险更高，如何保证高可用值得关注。一般是建议提前规划好高可用方案（而不是上线后），并进行周全的高可用切换测试。甚至上线后，可应保证一定频率的切换演练，做到有备无患。
3).运行优化
迁移后上线运行，运行效率值得关注。新的数据库选型，对稳定性运行会带来一定调整。作为运行保障的一部分，建立其完备的运行优化能力非常必要，包括基本的慢查询、日志、栓锁、会话等诊断工具及对应的处理措施。这一点对于国产库尤为重要，近些年来国产数据库发展迅速，但相较于其内核功能发展，上述周边管理优化能力发展不足，需要提前关注。
4).应急响应
作为最后的保障措施，当出现问题时的应急响应是需要提前规划的。这里更多是流程制度的设定，保证出现问题时及时感知、及时修复，不影响业务。
