详解DB数据迁移

详解DB数据迁移

什么是数据迁移

简单讲：将数据从一个地方转移到另外一个地方，或者是从一个应用程序移动到另一个应用程序，实现对原有数据的复制。

复杂讲：不仅仅是将数据从一个地方移动到另一个地方。这里需要考虑业务定义、架构变更、应用改造、数据一致性等诸多方面问题。在实际迁移工作中，需要结合业务方方面面，做好合理规划及实施，否则很可能会导致迁移结果达不到预期，浪费人力。

迁移目的

迁移的目的有：数据库成本、性能、空间、技术演进、业务需求、软硬件更换升级以及其他原因

成本

现有数据库成本过高，因而考虑至低成本方案。这里需要关注几点：

迁移后方案的总体成本，不仅要考虑初期采购成本，也要考虑后期维护及商业方案中过了初始几年后的持有成本。

迁移方案本身的成本，这里包括经济、时间、人力、风险成本等多种因素。

如实施失败时，必要的回退成本，包括因此而产生的对业务的影响所到来的经济损失。

性能

现有数据库不能满足性能要求，这里需要考虑几个问题：

性能要求是否合理？是常态化需求，还是偶然高峰？未来业务增长对性能的要求多大？

是否可在业务侧、应用侧，通过必要的改造、升级满足性能要求（毕竟前端的改造代价，比后端要小的多）？

是否可在原有数据平台上通过Scale Up或者Scale Out来解决性能问题？毕竟更换底层的平台的代价很大。

空间

现有方案不能满足容量要求，这里需要考虑几个问题：

• 当前存量数据，是否可通过清理、转储、归档等手段，来减少现有容量？（水平拆分）
• 现有数据是否是同质的，即是否可通过分拆，划分出独立单元来承载业务？（垂直拆分）
• 现有存量使用及未来增量情况，这些对于未来选型都很重要。

技术演进

随着企业自身的技术发展，对于后端数据平台的要求不断变化。例如数据中台、微服务等兴起，作为数据载体也需求有所变化

业务需求

业务发展变化，也对于支撑平台的需求不断变化

软硬件更换升级

软件，技术更替、版本迭代；特别是硬件，有着明显的周期性特点。企业定期都会避免升级替换类诉求。

其他原因

…

业务场景分析

在着手迁移之前，需要对现有业务做了全面的梳理，重点是将其对数据载体的要求整理清楚。

• 是什么数据？
• 数据结构是什么样子的？ 结构化/非结构化
• 数据特征：单体对象的最大规模（行、列），数据特征（结构化 or 非结构化）、数据类型， 主键、数据增长

迁移需求分析

硬件环境

业务系统使用的资源情况（CPU、MEM、STORAGE等）这些信息，一方面可用来为迁移后的技术选型做一定参考；另一方面在迁移阶段也需做好对现有环境影响的评估。

网络环境

业务系统的网络配置和网络隔离情况，包括组网逻辑、带宽、隔离情况。这些对迁移实施，有着一定影响。

操作系统

业务系统使用的操作系统，是Linux还是Windows，是32位还是64位，其使用的文件系统是什么？

安全策略

业务系统的特殊安全要求，例如开放哪些端口、访问权限。

应用系统

应用系统是采用商用的还是自研的，使用什么开发语言、版本是什么，接入类型（JDBC、ODBC等）？是否有专有的开发工具开发？是否使用了非标准接口？

性能指标

QPS、TPS、延迟要求

迁移难点

停机时间

• 平滑迁移：要求操作过程的全程可控。不仅要对正常流程的可控，还要做到在异常情况下的可控，保证即使出现各种异常，还能够正常时间内完成迁移或者回退。特点：复杂，难度较大

• 离线迁移：停止写入数据，迁移完成再提供服务。特点：简单，可控

数据校验

• 一致性校验:避免由于误操作导致新旧数据库不一致
• 在整个数据迁移过程中，采用的迁移方式多种多样。由于误操作或者迁移方案缺陷极有可能导致数据库数据的不一致。在迁移的过程中，应该制定严格的数据验证过程。在迁移前后，要有充分的准备。避免由于误操作导致数据库的数据库准确性问题
• 如果数据不一致，抽出标记不一致的数据定位问题
• 几种方法：
  

如何发现不一致数据

• 新旧数据库数据实时比较：当请求来时，新旧库都查询，以旧库数据为准做比较
• 增加日志和不一致数据入库
• 抽出不一致数据定位问题

性能保证

一般建议在正式迁移之前，进行预迁移在全量数据环境下的模拟压力测试，验证性能表现，进行正式迁移时耗时评估

迁移过程：事前篇

方案调研

数据迁移通用模式

• 平滑迁移
  *

• 离线迁移
  

数据存储

分布式数据库TiDB

• 高可用、数据强一致、可扩展
• 无单点故障
• 数据一定多副本
• TiDB、TiKV无状态，可水平扩展
• 海量数据且要求高吞吐
• 通过水平扩展TiKV达到存储海量数据
• 通过更多的TiDB Server达到更高的吞吐
• 适用于实时数据分析、数据汇集、二次加工

分表方案调研

数据分表方案: Range、Hash

将一张大表数据通过某种路由算法将数据尽可能的均匀分配到 N 张小表中

分表数量和KEY

• 分表数量：至少需要保证分好之后的小表在业务发展的几年之内都不会出现单表数据量过大（比如达到公司建议单表<500w）
• 分表KEY：需要根据业务自身特点确定
  • 查询语句必带条件，主键
  • 注意：需要考虑主键是否有业务含义

规划阶段

总体规划

对迁移的整体规划，包括需要的人力资源，数据库资源，工作的耗时估计

资源规划

对新存储的存储能力要求，性能要求

迁移规划

制定详细周密的迁移计划，包括整个后面“准备+迁移+验证+上线”的全流程。细节要详细到每一操作步骤，要求全部脚本化，不能临时敲命令处理。所有步骤的预期结果，需要明示。在出现之前未评估结果时，需启动应急流程处理。此外，一定不要忽视回退计划。

测试规划

在迁移中的每一阶段，都要制定测试计划，做到步步可验证。这里的测试可从系统级、数据级、应用级、业务级多方面去考察，保证最后结果的正确性。

验收规划

在迁移完成之后，需要有个标志性的环节，就是“验收”。这代表着本次迁移工作是否成功，可否将业务正式切换过来。一般建议，在系统上线后，一段时间之后再考虑。但需要在之前制定一个标准。

方案讨论

对规划阶段作出的方案进行讨论，尽量在方案讨论的时候把问题发现，避免在迁移时才发现问题。

准备阶段

• 硬件环境
• 提前申请数据库
• 提前创建表
• 业务准备
• 业务端做好必要的准备，例如挂公告等，为正式迁移做好准备。

测试阶段

业务测试

在开发完成后，首选需要进行的业务测试，即功能性验证。可采取全量回归的方式，尽量做到覆盖全部。重点关注异常，并定位是否是有迁移数据异常导致。

性能测试

基于之前指定的性能指标，对迁移后的环境进行性能测试。这里最好是能有一组基线数据方便对比，可在预迁移的环境准备基线。这样新环境的种种性能指标，是可以很容易评估是否有异常。（对数据库）
完成迁移脚本之后，需要对迁移脚本也需要进行性能测试。
问题修复

在测试完成后，难免出现问题，需要在此阶段快速修复。

性能优化

对于不满足性能要求的，做性能优化。

迁移过程：事中篇

迁移阶段

数据迁移

数据迁移包括全量和增量数据迁移。全量迁移一次性迁移完成，增量靠双写完成。
在完成数据迁移之后，一般会和原有的数据平台并行运行一段时间，一方面是为了和原有平台进行业务和数据的比对，确保业务的正确性和连续性；另一方面，应用改造迁移是一个循序渐进的过程，在所有应用迁移完成前，原有数据平台还是要承担正常的业务访问。

数据验证

一般的做法是通过类似灰度发布的过程，开始的时候同时往两个平台写入数据，但只有原有数据平台对外提供业务访问，每天通过数据校验作业，比较两个平台的数据一致性。经过一段时间，确认数据没有问题后，再把对外访问的流量切换到新的数据平台，再经过一段时间撤除原有平台上的作业。

数据对比：

• 对比数据量，即分别统计出数据表的条数，然后进行比对。如果条数匹配，就认为两边数据是一致的。这种方法的优点是效率很高，缺点是不能完全保证数据的一致性。
• 对比数据条数加上关键字段校验，但需要提前定义出关键字段。也可以采取对全表做md5的方式，但这种方式只适合离线方式，且效率不高。
• 对比全量全字段：简单粗暴，在对校验没有时间要求的情况下，可以用这种方式
  

问题整理

整理出在迁移中遇到的问题和以后需要注意的事项

验证阶段

业务测试

迁移完成后，首选需要进行的业务测试，即功能性验证。可采取全量回归的方式，尽量做到覆盖全部。重点关注异常，并定位是否是有迁移数据异常导致。

性能测试

基于之前指定的性能指标，对迁移后的环境进行性能测试。这里最好是能有一组基线数据方便对比，可在预迁移的环境准备基线。这样新环境的种种性能指标，是可以很容易评估是否有异常。

问题修复

迁移过程后，难免出现问题，需要在此阶段快速修复。

性能优化

对于不满足性能要求的，可在线做性能优化。

迁移过程：事后篇

迁移最后，需要针对此次迁移做个概括性的盘点。针对新系统的表现，与之前的预期进行对比评估。对仍然存在的遗留问题，需要重点关注。

文档参考

• 高并发系列:存储优化之也许可能是史上最详尽的分库分表文章之一
• MySQL分库分表方案
• TiDB 简介