为什么迁移日志很重要生产迁移最怕的不是慢而是不知道发生了什么。常见问题是接口一直没返回是还在跑还是卡死 源库慢还是目标库慢 迁了多少 还剩多少 哪个客户、哪个表、哪个区间慢 失败前最后成功到哪里如果日志只有一行migration failed那基本无法快速定位。迁移日志必须按生产排障来设计。日志前缀要稳定建议所有迁移性能日志使用统一前缀。例如EMRC MIG PERF后面再接具体阶段src_rt_page src_alarm_page src_rt_dry_stat dst_rt_stage dst_alarm_stage dst_msg_batch dst_msg_dedup_delete dst_msg_dedup_update这样线上可以直接过滤tail-n1000-fuiot-pro2026-08-13.0.log\|grep-EEMRC MIG PERF|EMRC migration稳定前缀比日志内容写得漂亮更重要。每条日志要包含哪些字段迁移性能日志至少包含客户 businessAccount 阶段 step 批次范围 本批读取行数 本批写入行数 影响行数 耗时 cost例如源库告警分页日志src_alarm_page baInterapas1 tableas_water_alarm fromId7500000 toId8000000 rows31901 events31901 cost46166ms这条日志能看出哪个客户 哪张源表 哪个主键区间 查了多少行 拆出了多少事件 源库耗时多少再配合目标库写入日志dst_alarm_stage rows1000 affected1000 cost303ms就能判断瓶颈在源库查询而不是目标库写入。dry-run 也要有进度日志很多迁移系统只在 execute 打日志dry-run 静默执行。这在生产上不够。dry-run 往往也会扫源库大表如果没有进度日志用户会误以为接口卡死。建议 dry-run 每隔固定数量打印src_rt_dry_stat progress baInterapas1 meters750/1039 batchMeters10 rtRows9490 freezeRows0 cost9731ms字段含义meters750/1039已经统计 750 块表总共 1039 块 batchMeters10本批统计 10 块表 rtRows9490本批实时行数 freezeRows0本批冻结展开数 cost9731ms本批耗时这样即使 dry-run 很慢也能证明它还在正常推进。慢批次要单独打印普通进度日志用于确认任务还活着。慢批次日志用于定位性能问题。例如src_rt_dry_batch slow baInterapas1 batchMeters10 rtRows24219 freezeRows0 cost25267ms建议设置一个慢日志阈值例如超过 5 秒打印 slow阈值不是绝对的要结合生产库性能和数据规模调整。慢日志的价值在于后续可以拿具体表计、具体区间去源库做执行计划分析。进度日志和性能日志要分工迁移系统通常有两类日志。第一类是进度日志EMRC migration progress: stepREALTIME_MIG, 90325/472477, 19.12%它回答整体跑到哪里了 完成百分比多少 当前阶段是什么第二类是性能日志EMRC MIG PERF dst_msg_batch baYAHSO from... to... rows71604 cost47254ms它回答慢在哪里 本批数据量多少 源库和目标库各耗时多少两类日志不能互相替代。日志要便于 grep生产上多数时候不是打开日志平台而是在服务器上直接看tail-fxxx.log|grep...所以日志关键字要简单、稳定。推荐grep-EEMRC migration|src_rt_dry|src_alarm_page|dst_alarm_stage|dst_msg_batch不要把关键字段写成复杂自然语言。例如不要只写alarm migration is processing应该写src_alarm_page baxxx tablexxx fromIdxxx toIdxxx rowsxxx costxxx补偿接口也要打日志补偿接口经常被忽略。但补偿接口更需要日志因为它通常直接修改历史数据。例如实时去重补偿dst_msg_dedup_delete baYAHSO rows10207 cost30455ms dst_msg_dedup_update baYAHSO rows90325 cost222987ms这两条日志能证明删除了多少重复记录 更新了多少旧 ID 执行耗时多少 是否按指定客户执行补偿接口没有日志生产上不应该直接跑。失败日志要保留关键上下文失败日志至少要包含客户 阶段 当前 step 异常摘要 progressId例如EMRC realtime async migration failed, progressIdxxx Duplicate entry xxx for key mig_emrc_realtime_data.PRIMARY这类日志能快速判断是中间表重复 目标表主键冲突 源库 SQL 超时 数据类型异常 NPE失败日志不要只吞异常也不要只返回前端。总结生产迁移日志设计的目标不是“多打印”而是“可判断”。一套合格日志应该能回答任务是否还在跑 跑到哪个阶段 源库慢还是目标库慢 本批处理了多少 失败前最后成功在哪里 补偿接口改了多少数据日志设计好了生产迁移才从黑盒变成可观察的工程过程。