数据库迁移腾讯云DTS 全量增量割接怎么评估附可直接执行的预检与回滚清单系列第五篇收官篇· 配套阅读第一篇AI 评估全流程、第二篇信息收集模板、第三篇AWS 差异、第四篇物理机上云主题数据库是迁移项目里数据最重、一致性要求最严、停机敏感度最高的一环。本篇把评估输出物收窄成三张可交付清单预检清单迁前→ 割接执行单迁中→ 回滚检查单迁后并给出 DTS 场景的 AI 辅助评估指令。0. 为什么单独为数据库写一篇前面四篇里数据库都只是评估的一部分。但真实项目里它值得单独成文因为三个特性它决定停机窗口应用代码、配置、网络都能重来一次唯独数据库割接那一刻的状态切换决定了业务能停多久、丢不丢数据它的风险是延迟暴露的迁移时看不出问题上线一周后因数据不一致出的故障才致命它最容易被工具论带偏一听到DTS 支持在线迁移、不停服就默认评估工作量很小——实际上 DTS 解决的是数据传输这一环前置检查 切换 校验 回滚预案才占大头。本篇默认主链路为源库阿里云/AWS/自建 IDC→ 腾讯云云数据库MySQL/Redis 等采用 DTS 全量 增量不停机迁移 手动切换。方法论通用产品细节以腾讯云官方文档为准。1. 先建立正确的心智模型DTS 迁移的四个阶段把评估对象从DTS 这个工具切换成一条完整的割接链路工作量才会估得准阶段一 预检与准备前置最长最容易漏 ↓ 阶段二 全量迁移历史数据通常可在线执行 ↓ 阶段三 增量同步追平 binlog源库持续可写 ↓ 阶段四 切换与校验业务停写 → 校验 → 应用切到新库 → 放开流量关键认知只有阶段四的一小段是停机。所谓把停机压到分钟级压的就是阶段四里停写 → 校验 → 切流的时间。所以评估的核心问题不是数据怎么传而是全量要跑多久决定阶段二时长影响排期但不停机增量追平需要多久取决于源库写入压力与通道带宽阶段四那几分钟窗口内校验要快、出问题要能 30 秒内决定回滚。2. 评估输入数据库专项信息表迁移前必填直接复用/扩展第二篇模块 2的口径数据库专项至少要收齐以下字段字段为什么关键反例引擎与精确版本决定 DTS 兼容性与小版本差异“MySQL”不分 5.7/8.08.0 默认认证插件就不同架构主从/分片/只读决定同步链路设计主从不写DTS 只能接主实例数据量与日增量决定全量时长与带宽规划只写总量不写增量排期翻车binlog 保留时长增量追平的前提保留 24h结果全量跑 36h → 直接失败字符集/排序规则/时区切换后行为差异高发区应用按默认假设实际源库是 utf8mb4_unicode_ci账号与权限模型连接串/账号重建工作量有 30 个业务账号逐个要建特殊对象存储过程/触发器/事件/分区表/外键触发器在新库没建写操作静默异常大表/大事务清单全量与增量瓶颈定位有 2TB 单表无专职任务做切割定时任务迁移窗口内的任务冲突每天凌晨有归档任务恰逢割接日备份与恢复验证评估可回退底线“从未做过恢复演练”待停用的旧连接割接后源库误写应用配置没改全双写两头不一致填表守则照抄第二篇允许写未知/待确认不许留空让 AI 脑补。3. 迁移方式评估决策三种场景别搞混场景判断依据推荐做法停机敏感度源库是云数据库/可开 binlog增量可追平DTS 全量增量切换低分钟级源库是小库/可接受短停数据量小、业务窗口友好导出导入 窗口内一次性切换低~中小时级源库老旧/无 binlog/特殊引擎增量不可行业务双写或停服搬运专项设计高评估时用下面这段指令让 AI 帮你逐库归类配合第 2 节信息表基于我提供的数据库专项信息表请对每套数据库给出 1. 迁移方式建议DTS全量增量 / 导出导入 / 需专项方案依据必须引用表中字段 2. 全量迁移时长估算数据量 ÷ 有效传输带宽假设专线带宽 X Mbps含压缩与 校验开销按有效 70% 计给出区间 3. 增量追平可行性binlog 保留时长 vs 全量预计时长是否足够不足的话如何解决 4. 切换窗口建议结合业务允许停机时长给出阶段四的分钟级窗口与校验动作 5. 每项结论标注置信度低置信度项列出需补充的信息。4. 交付物 1迁移前预检清单DTS 场景可直接落地执行用法割接前 1 周逐项打钩任何一项否当天不做割接。□ 1. 源库 binlog 已开启row 模式保留时长 ≥ 全量预计时长 × 1.5 □ 2. 源库账号授权完备DTS 所需账号SELECT/REPLICATION SLAVE 等已创建且最小权限 □ 3. 目标库已创建版本/字符集/排序规则/时区与源库对齐 □ 4. 目标库资源足够磁盘余量 ≥ 源库 1.2 倍性能档位覆盖峰值必要时先升配 □ 5. 大表清单已确认超过 50GB 的表是否有专职方案并行/分片/先导数据 □ 6. 特殊对象已同步存储过程、触发器、事件、分区表、外键逐项核对 □ 7. 业务账号已重建连接串、账号密码、权限、host 白名单全部就绪 □ 8. 字符集/时区专项验证抽样业务数据在目标库查询结果一致 □ 9. 应用连接配置改造单已评审切库开关、配置中心、多环境覆盖 □ 10. 网络链路已打通专线/VPN 到目标库连通性、延迟、带宽实测通过 □ 11. 回滚预案已评审回切脚本、反向同步通道、通讯录谁按哪个按钮已明确 □ 12. 割接窗口已与业务方书面确认含演练窗口与正式窗口 □ 13. 观察与验证脚本已备好行数对比、关键指标 SQL、抽样业务接口 □ 14. 监控告警已配置目标库 CPU/连接数/延迟/主从状态告警提前 3 天生效5. 交付物 2割接执行单阶段四分钟级窗口内照单执行原理先停写再切流全程控制在预定窗口内每一步都有确认人 校验动作 超时触发回滚。【T-30min】通知业务方进入只读模式停定时任务/批处理DTS 增量延迟压到 ≤ 5s 【T-5min 】确认增量延迟为 0 且稳定连续观察 5 分钟无增长 【T0 】停写操作应用切只读/停写开关确认源库无新写入用延迟与连接数双重确认 【T1min】DTS 完成最后一次增量追平并停止同步 【T2min】目标库校验行数对比抽样大表 关键业务数据点核对 【T3min】校验通过 → 应用连接切换到目标库校验失败 → 按回滚检查单执行见下 【T5min】放开业务流量业务方冒烟验证核心链路 【T15min】确认无异常DTS 链路保留不删除进入观察期 【观察期 】双跑核对 2~4 周目标库数据与源库历史快照比对、报表/对账任务复核6. 交付物 3回滚检查单割接 30 分钟内回滚靠这张单触发条件校验失败 / 放开流量后 15 分钟内出现 P0 故障且无法快速修复 □ 1. 通知业务方、研发、DBA 三方同步启动回滚停止放量 □ 2. 切回应用连接切回源库配置开关一键回切预先演练过 □ 3. 数据兜底确认源库全程未停写停写窗口内的写入已核对落库 □ 4. 校验源库关键业务数据点验证正常业务方冒烟通过 □ 5. 记录记录回滚原因、时间线、增量通道断点位置供复盘 □ 6. 决策由项目负责人决定何时重新发起割接通常修复问题后重新走预检 □ 7. 特别提醒回滚不是失败是预案生效观察期内任何回滚都不计入事故7. AI 辅助评估指令让 AI 帮你查全 排雷把前三张清单预检/执行/回滚的框架和你的专项信息表一起丢给 AI做一轮增量检查我已为数据库迁移准备了【专项信息表】与预检/执行/回滚三张清单。 请以资深 DBA 视角帮我做两件事 1. 找遗漏基于信息表指出我的清单还漏了哪些该检查/该执行/该回滚的项 重点方向主从/只读实例的同步链路、字符集与排序规则、大事务与长连接、 事件调度器、只读账号误写、配置中心多环境遗漏、时间戳默认值等 2. 排雷从信息表中挑出你认为最容易在割接当天爆雷的 5 项给出原因与预防动作。 要求每条建议必须能直接落成清单项不要泛泛而谈。特别提醒AI 排雷只做候选数据库割接的最终裁决必须由熟悉源库业务的人拍板——尤其是停写窗口能停多久这类业务问题AI 永远替不了你。8. 数据库迁移工作量估算人日口径含示例区间阶段工作包人日区间主要变量预检专项信息收集与核对1~2/库库数量、特殊对象多少预检目标库创建与参数对齐0.5~1/库规格/版本差异预检特殊对象与账号迁移1~3触发器/事件/账号数量预检回滚预案设计与演练1~2是否首次割接全量DTS 任务配置与全量跑批0.5~1 等待数据量与带宽增量增量追平与延迟压测1~2源库写入压力切换割接演练至少 1 次1~2/次演练 正式割接的彩排切换正式割接 冒烟1当天含夜间窗口观察双跑核对与监控优化2~4观察期跨度三个容易让预算翻倍的因素特殊对象未提前识别排期后补、源库写入高峰撞上增量追平延迟压不下来窗口被吃掉、账号体系复杂30 个账号重建 权限核对。评估时把这三项单独拿出来问别藏在总表里。9. 收官总结五篇方法论闭环把五篇串起来正是一条完整可交付的迁移评估链路第一篇让 AI 帮你在 1 小时内产出评估报告骨架阿里云→腾讯云主流程 Prompt第二篇把源站信息用八大模块收集模板收齐、脱敏、喂给 AI一切评估的地基第三篇AWS 场景的八类组件差异与可平移/需改造/架构决策判定 WBS第四篇物理机/IDC 场景——没有对照表可抄时五张盘点表 路线决策本篇第五篇数据库专项的三张可执行清单预检/割接/回滚 DTS 停机压到分钟级的原理。运维/实施工程师在跨云迁移里的核心竞争力本质就是两件事把系统说清楚盘点与信息组织把风险讲明白分级与预案。AI 负责把说清楚的成本打下来、把讲明白的遗漏补上——剩下的判断与拍板正是你不可替代的部分。