随着近年来数据库的变化，越来越多的公司将传统数据库迁移到开源或新的业务产品中。 在这个过程中，会面临很多问题。 在此，我们希望整理一些常见的问题，对数据库的选定和数据库迁移风险的评估等有所帮助。 为了清楚说明，我们将整个迁移过程分为几个阶段。 橙色徽标工作由数据库团队支持。 以下，对各阶段进行详细说明。
1. 阶段：迁移准备
人生基本上是两件事，解决选择题和问题。 最好的人生，是在每一个关键点，一边选择正确的问题，一边解决好问题。 人生最大的痛苦是正确解答了问题，却选择错了问题，而且还不知道自己选择了错误的问题。 人生最大的遗憾不是你不行，而是你能做到。
1).迁移规划
进行迁移时，首先要对迁移工作制定总体规划，制定应对的原则方针。 例如，明确转移范围、转移方法、能否停机、窗边等。 这些信息是后续过渡的指导原则，许多过渡方案的制定都需要依靠这一修订。 事先制定必要的计划，以免快要转移，或者发现不能达到预期。 除了技术因素外，组织、管理、资源等也将在这个阶段得到考虑。 迁移是一个非常复杂的过程，涉及的所有方面都很多，尽可能从项目一开始就全面掌握。
2).业务梳理
要完成数据库迁移，还必须考虑高层业务系统。 在一定程度上，APP应用程序迁移更为重要，在后续迁移过程中也更占优势，难度也更大。 因此，在过渡准备阶段，需要全面梳理相关业务。 这里需要整理的信息非常广泛。 但是，包括与业务系统相关的硬件和软件环境、数据库的交换、业务系统间的调用关系等。 此后，在进行应用系统改造规划中，上述信息非常重要，有助于评价工作难点、工作量等。 这里举一个例子，一个系统以前使用Oracle，在开发中采用了c语言。 迁移到某国产库时，发现数据库不支持C driver。 我很不好意思。
3).方案选型
整理业务后，选定数据库。 这一过程也是过渡准备阶段需要时间的工作。 在众多数据库产品中如何选择符合自己要求的产品，需要考虑的因素很多。 推荐的做法是在进入公司前制作推荐的提案矩阵，根据对数据库能力的要求、系统的重要程度等制作产品选型矩阵。 前期有了这个基础，比较简单，只需要按照图就行了。 否则，必须从头开始完成一系列工作，包括初步调查、技术评估、数据库评估(功能、非功能、业务等)和适用性评估。 这里强调一个原则，就是尽量在方案选择中保持最大的自由度，即不受单一厂家的限制，随时保持可交换的能力。 因此，在方案选择中，必须选择长期可替代的原则，而不是业务少改造、过渡最简单、成本最低的方案。 建议选择符合常规协议的产品，尽量降低数据库方面的能力，并选择使用标准数据库功能的产品。
4).技术培训
方案选择完成后，需要进行技术培训。 这里说的培训包括研发、运维等多个方面。 在对研发人员的培训中，重点阐述了该数据库在体系结构设计、结构优化、SQL语句等方面与原数据库不同。 选择通用性产品将减少此处的工作，并使其他库之间的迁移更容易。 这就有不转入研发的原则，需要做的修改还是要修改。 例如，在许多到o的工作中，为了最大限度地减少迁移工作，许多项目都选择了与Oracle语法兼容的产品，甚至与存储过程兼容。 这类产品会减少迁移工作量，但从长远来看不是很好的选择。 运维培训重点是如何将新数据库集成到现有运维系统中。 特别是现在，许多分布式体系结构数据库与传统的集中式数据库不同，运输带来的挑战也越来越大。
2. 阶段：迁移评估
人生基本上是两件事，解决选择题和问题。 最好的人生，是在每一个关键点，一边选择正确的问题，一边解决好问题。 人生最大的痛苦是正确解答了问题，却选择错了问题，而且还不知道自己选择了错误的问题。 人生最大的遗憾不是你不行，而是你能做到。
1).资源评估
准备好后，在开始之前，根据以前整理的业务状况、进行的数据库选定等信息，开始必要的评估工作。 这里的评价主要是为后续的过渡改造做准备。 首先是资源评估，即完成上述迁移所需的资源。 这里有隐藏的工作。 需要制定相关的技术方案。 也包括数据库和APP应用程序端的。 毕竟数据库的能力不是一对一对等的，所以体系结构有很多调整和重建。 但是，这里进行的评价比较粗略，对于资源消耗很难用细的粒度进行记述，所以进行后者是以完全的评价数据为前提的。 为什么要在这个阶段做这项工作呢？ 主要是因为很多传统企业都采用预算制，需要制定长周期的后续采购修订计划。 因此，前置了资源评估工作。
2).应用评估
在此阶段，数据库选型确定后，完成APP应用程序的评估工作。 从调整APP应用程序到重构，包括APP应用程序的代码修改量、潜在风险等。 在此主要由APP应用程序架构师进行上述评估。
3).对象评估
完成对APP应用程序的评估后，数据库评估如下： 其评价的第一项是对象评价，也就是数据结构的评价。
数据库的能力层次不齐，原有的数据结构大概率都无法直接复用了，需要进行必要的调整甚至重新设计。这里有个建议，就是尽量减少数据库端复杂对象的使用，尽量只考虑表及索引的设计，其余包括视图、序列、触发器、存储过程、函数、包等都通过外部的等价设计来完成。这点主要是出于减少对数据库的依赖所提出的，毕竟后面这个功能的实现差距非常大。当然，随之带来的外部等价实现的工作量也需要进行评估。此外，如果是分布式数据库方案，还需要考虑例如分片策略等。这里有个常见的通病，就是将原有设计原封不动地在新环境中落地，然后修改语法不兼容的部分就算是完成这一过程。其带来的后果，往往是上线后问题频出。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).应急响应
作为最后的保障措施，当出现问题时的应急响应是需要提前规划的。这里更多是流程制度的设定，保证出现问题时及时感知、及时修复，不影响业务。
韩锋频道：
关注技术、管理、随想。
长按扫码可关注