一、背景在旧系统迁移到新平台的过程中研发和测试经常会遇到一个问题迁移程序需要真实数据验证但又不能频繁直接访问生产库。如果只用少量模拟数据很难覆盖真实环境中的复杂情况例如历史字段不规范字典值和状态值存在历史遗留主档数据和业务数据存在弱关联大表数据量远超开发环境迁移 SQL 在小数据量下正常但在真实规模下暴露性能问题生产持续写入研发直接查询会带来额外风险。因此我们做了一次旧系统生产库到公司测试环境的全量数据复制形成一个供研发、测试和迁移同事共同使用的“测试源库”。这个测试源库的定位不是生产备库也不是正式切换库而是用于迁移程序 dry-run、字段映射验证、数据清洗验证、行数比对和业务口径确认的生产快照库。二、为什么要复制生产数据到测试环境这类工作看起来像 DBA 操作但对迁移项目非常关键。1. 降低生产库访问压力迁移开发阶段大家需要频繁查表结构、查样本数据、跑验证 SQL。如果每个人都直接连生产库会带来查询压力权限管理风险误操作风险网络和安全边界问题。复制一份生产快照到测试环境后研发和测试可以优先使用测试源库减少对生产库的直接依赖。2. 提供稳定的验证基线生产库一直在变化。如果每次验证都直接查生产今天和明天的数据可能不同问题定位会变复杂。测试源库是某个时间点的一致性快照更适合做迁移程序 dry-run字段映射校验数据质量检查迁移前后行数比对核心业务口径验证。3. 暴露真实数据规模下的问题小数据量测试无法暴露很多真实问题。例如大表导出耗时导入性能索引缺失SQL 执行计划异常字段值脏数据历史临时表是否需要迁移超大表是否需要单独处理。使用生产快照后这些问题可以在正式迁移前提前发现。三、本次复制范围本次复制的是旧系统生产库的完整结构和主要业务数据。复制目标包括表结构字段定义索引基础对象主要业务表数据大体量历史数据表核心主档表和业务流水表。处理时做了一个取舍正常业务表迁移结构和数据历史临时表、名称中带有copy含义的临时备份表只保留结构不迁移数据原测试环境已有库不覆盖新建一个独立测试源库承接复制结果。本次复制后的规模大致如下基础表数量约 135 张 迁移数据表数量约 129 张 最大单表数据量约 3,100 万行这个规模足以支撑研发阶段的大部分迁移验证。四、整体复制方案由于测试服务器无法直接访问生产库本次采用“中转导出再导入”的方式。整体链路如下旧系统生产库 - 使用 mysqldump 导出全量快照 - 将 dump 文件传输到测试服务器 - 在测试 MySQL 中创建目标库 - 导入结构和数据 - 做核心表行数校验这是一种比较稳妥、通用、依赖较少的方式。它不要求生产库和测试库之间网络互通也不要求额外部署同步组件。只要能在生产侧导出文件并能把文件传到测试服务器就可以完成。五、关键参数和控制点1. 使用一致性快照导出导出时建议使用mysqldump --single-transaction--quick其中--single-transaction基于事务获取一致性快照适合 InnoDB 表尽量降低对生产写入的影响--quick逐行流式读取结果避免客户端一次性把大结果集加载到内存。这两个参数对大库导出非常关键。2. 先结构后数据对于迁移验证场景建议把结构和数据的导入过程拆开考虑。好处是结构问题可以提前暴露数据导入失败时定位更清楚后续如果只需要重建结构或只重导数据操作更灵活。3. 临时表和历史 copy 表区别处理旧系统里经常会有一些历史临时表例如开发或运维过程中产生的备份表。这些表如果全量迁移数据可能会显著增加导出导入耗时但对迁移验证没有价值。因此可以采用策略保留表结构不迁移数据在文档中明确说明。这比直接忽略表更稳妥因为后续如果有人依赖这些表名至少能看到结构存在。六、执行耗时本次复制完成后整体耗时大致如下阶段耗时说明数据导出约 3 小时 5 分钟主要耗时阶段文件传输约 6 分 28 秒局域网传输较快数据导入约 21 分 20 秒明显快于导出可以看到瓶颈主要在生产库导出阶段。这也符合大多数类似场景的经验生产库远程读取慢大表扫描耗时导出过程受磁盘、网络、数据库负载共同影响测试库本地导入通常更快。后续如果要做类似全量复制建议至少预留 3 到 4 小时窗口并提前确认生产库负载情况。七、核心数据校验导入完成后需要做基础校验。最直接有效的方式是对核心表做行数检查。本次校验的部分核心表规模如下数据类型行数规模实时/历史读数大表约 3,172 万行告警主表约 503 万行设备在线记录约 156 万行抄表记录约 103 万行抄表历史记录约 25 万行告警诊断表约 23 万行表具主档约 1 万行表具参数约 1 万行抄表点位约 2 万行客户主档约 1.3 万行操作员百级部门组织百级区域千级行数校验不能证明数据 100% 正确但可以快速发现明显问题例如大表没有导入某些表被误过滤导入中途失败目标库字符集或 SQL 模式导致部分数据异常临时表处理策略和预期不一致。更严格的校验可以进一步做主键最大值比对关键字段非空率比对按日期分区或时间范围统计核心业务状态分布比对抽样记录字段级比对。八、使用边界这个测试源库适合用于迁移程序开发dry-run字段映射确认数据质量检查主档迁移验证业务流水迁移验证实时数据和告警口径验证测试环境联调。但它不适合用于作为生产实时查询库判断生产库当前最新数据作为正式切换前的最终数据源直接作为 CDC 增量同步起点多人随意写入修改公共数据。这里要特别强调一点测试源库是复制时刻的生产快照不代表生产库当前最新状态。生产库在复制完成后仍会继续产生新数据。如果要验证最新增量需要重新复制或设计增量同步。九、关于增量同步本次复制主要解决“研发和测试阶段有一份稳定全量数据”的问题。它不等同于正式增量同步。如果后续要做生产增量同步需要额外考虑生产库是否开启 binlog增量同步起点如何确定哪些表进入同步范围是否需要按客户、区域或业务范围过滤目标库写入是否幂等删除和更新如何处理失败后如何补偿如何做持续差异校验。所以全量测试库和正式 CDC 是两个阶段的问题。全量测试库解决的是迁移开发、字段映射、清洗规则、数据质量和大数据量性能验证。CDC 解决的是正式切换前后生产增量数据如何持续、准确、可恢复地同步到新系统。十、经验总结这次旧系统生产数据复制到测试环境有几个比较实用的经验。1. 先明确库的定位不要把测试源库定义成“生产备库”。它的定位应该明确为用于迁移开发和验证的生产快照库定位清楚后使用边界也会更清楚。2. 复制前先梳理表范围不要盲目全量搬所有数据。至少要提前确认哪些是核心业务表哪些是大表哪些是历史临时表哪些只需要结构哪些必须保留完整数据。3. 大表要单独关注大表决定导出耗时也最容易影响生产库。建议提前评估行数索引时间范围是否可以分批是否需要单独校验。4. 导入后必须做行数校验只看导入命令成功不够。至少要对核心表做行数统计并记录到文档中作为后续迁移验证的基础。5. 公共测试源库要有使用规范如果多人共用一个测试源库建议约定默认只读不随意清表不随意改公共数据写入验证前先说明需要破坏性测试时复制到个人库。否则测试源库很快会失去可信度。十一、结语旧系统迁移不是一开始就写迁移程序。在真正迁移之前先复制一份可用、稳定、规模接近真实生产的数据源对后续工作非常有帮助。它能让团队提前完成字段映射验证数据质量检查大表性能评估迁移程序 dry-run业务口径校验测试联调准备。从工程角度看这类“生产快照测试源库”是迁移项目中的基础设施。它不一定复杂但非常关键。做得好可以显著减少后续迁移开发和联调中的不确定性。