数据迁移类测试策略

前言

　　前段时间做了一次数据迁移，针对数据迁移类型的测试方法进行了一些了解和总结，以下工具愚公移山和精卫为淘宝开发的工具，已使用于多个产品、项目中，质量有保障。

　　一、工具介绍

　　1、愚公移山

　　概述：

　　数据的动态迁移，可完成数据全量、增量迁移，进行数据比对，保证数据的正确；目前较多运用在数据迁移中，已经被很多团队使用，是很成熟可靠的数据迁移工具

　　适用范围：

　　可支持：支持oracle和mysql，分库分表，实时同步，数据比对

　　不支持：涉及到外部依赖，迁移规则非常复杂的数据

　　性能情况：

　　没有对愚公进行压测，性能情况参考以下的例子

　　例子：迁移一个1000万的表。 16个线程，开启批量写入，半个小时以内完成。

　　影响点：机器的负载，并行的任务数，配置的线程数

　　愚公百科：（不知道可以可以贴！有需要可联系作者）

　　2、精卫工具

　　概述：

　　精卫是一个基于MySQL数据库的数据复制组件，较多运用在数据双写的场景中，是比较成熟的一个数据复制组件

　　解析数据库的binlog文件，A库的所有的数据变更传到B库。binlog:描述数据变更的文件

　　适用范围：

　　同库不同表数据复制、多库多表数据冗余、标准化去O支持、数据变化通知

　　性能情况：

　　性能压测，性能结果满足交易主库同步备库需求

　　例子：主库1000tps，延迟在50sms以内

　二、迁移类测试策略

　　1、概述

　　随着业务需求或数据量增长到一定程度，往往需要进行数据库切换，这里就伴随这数据迁移。

　　关键字： 全量数据迁移，增量数据迁移，分库分表，数据双写，oracle、mysql、hbase…，新老数据兼容，数据订正

　　2、发布方案（迁移方案）

　　两大类：正常发布、停机发布

　　正常发布：可以实现线上业务无缝切换，不影响用户使用，需要保证新老数据兼容，发布过程中的数据写入等。

　　停机发布 : 优点在于可以避免发布过程中的新数据写入，缺点是发布过程中，不能正常提供服务。

　　发布方案的制定是根据具体业务情况制定发布方案，对业务无影响的情况下较常采用停机发布，方便简单。

　　介绍一种无缝对接的正常发布方案

　　A库历史库 mysql分库分表 到 B库新库hbase

　　步骤1、全量dump1：A库数据全量迁移至B库

　　步骤2、打开双写：同时写入到A库历史库和B库新库

　　步骤3、全量dump2：开启双写前的所有差集，将差集灌回B数据库，这里是补充全量dump1期间和开启双写前只写入到A的数据。保证了A、B数据库数据的完全一致，同时已经开启了双写。

　　步骤3’、测试介入，可对A、B库取某一时间段前所有数据进行数据验证。

　　步骤4、停止对A库的写入，发布前端应用，切换至B库新库

　　注意点：

　　1、双写时，B库不存在被写源数据或B库数据状态异常等情况，需要从业务上考虑，是否直接从A库中获取数据并覆盖至B库

　　2、以上步骤中的多次dump和双写有多个写入B库的场景，需要以保证B库和A库一致为原则，如B库的重复写入等情况的处理。

　　3、测试策略

　　在进行数据迁移测试前，需确认的CheckList

　　CheckList

　　1、 哪些表需要迁、哪些表不需要迁；需要迁移的表老库和新库的对应关系是怎样的

　　2、 明确表的关联关系，关联表是否需要迁移，不迁移怎么处理

　　3、 迁移的表中，哪些字段要迁移，哪些不迁移，对应关系是怎样的

　　4、 新表中的字段，老表是不是一定有，如果不一定，怎么处理可能为空的情况，尤其是必填字段的处理

　　5、 迁移前，新表是否为空，不为空是否可能存在数据重复的情况，怎么处理

　　6、 新老表中的字段类型、长度的定义是否一致，可否正确转换

　　7、 需迁移的表数据量为多少

　　8、 开发做了哪些数据迁移正确性的保障

　　针对不同的业务场景需要测试人员设计不同的测试方案，主要都是两个层面的验证，数据层面的数据验证和功能层面的功能验证

　　1、数据验证：使用工具或设计对账程序全量验证

　　a、全量数据验证

　　b、增量数据验证

　　c、抽样数据验证

　　根据业务情况判断需要进行哪一项或几项数据验证

　　工具使用：可以选用目前较成熟的迁移工具：愚公移山， 兼全量数据验证和增量数据验证功能

　　验证方式：若迁移场景不在愚公的适用范围内，全量验证和增量数据验证需要另外设计适用于该场景下的数据验证方案

　　可采用的一些验证方式：考虑根据不同数据的存储方式，数据量的大小

　　a、关系数据库，直接新老数据库中jdbc方式获取数据，一条条进行对比，新老数据存在规则转换的情况需要在对账程序中同时进行规则判断。

　　b、全量或抽样dump历史库和新库两份文件进行对比，数据库非常大的时候推荐使用hadoop

　2、功能验证：主要是抽样数据的功能测试

　　a、功能测试：对历史数据常见的操作方式为，在历史库准备一批历史数据，准备什么样的历史数据依赖于具体业务的数据情况，通过迁移程序将历史数据迁移至新库后，验证这批数据的存储和功能展现。新数据的验证则以新增功能的方式进行测试。

　　b、自动化测试：API自动化+页面自动化：只有数据迁移没有上层业务变更的情况下，如果已经存在自动化脚本，采用自动化脚本可以快速回归，重点在DAO层的方法。

　　以下情况需要特别设计用例进行功能验证

　　1、 老表字段进行类型或长度等转换迁移至新表

　　2、 老表中可能为空的字段，新表中直接为空或默认一个初始值

　　3、 老表数据通过特殊处理转换为新表中的值

　　4、 需要进行数据订正的字段

　　数据双写

　　数据双写往往伴随着数据迁移进行，精卫工具能很好的支持数据复制，并进行数据比对。

　　在精卫工具的试用范围外的数据双写，一般是应用中加入双写代码，这里也需要涉及数据比对程序，类似于数据迁移的比对程序；

　　可采用的验证方式：

　　1、根据数据双写的实时性的特性， 在不影响应用功能、性能的情况下，可以考虑在双写代码中加入验证程序，即每完成一次双写，即对插入的新老数据进行数据比对。

　　2、枚举所有涉及双写的场景，逐个场景进行功能验证

　　3、以全量的方式进行数据比对，数据双写进行到一定程度，能确保所有需要双写的场景都已经进行过，那么，对双写的两张表的数据截取gmt_modify时间为某一时间段以前的所有数据进行比对，约等于迁移的全量数据验证。

　　其他关注点：

　　1、 考虑id预留空间：+**，需要足够大，保证没有主键冲突

　　2、 关注sql性能：分库分表，尤其是跨库查询时需要关注性能情况，数据量比较大的情况下，可以考虑走搜索