数据库迁移腾讯云：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.0，8.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 周逐项打钩，任何一项"否"，当天不做割接。
markdown
□ 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：割接执行单（阶段四，分钟级窗口内照单执行）
原理：先停写再切流，全程控制在预定窗口内；每一步都有"确认人 + 校验动作 + 超时触发回滚"。
markdown
【T-30min】通知业务方进入只读模式；停定时任务/批处理；DTS 增量延迟压到 ≤ 5s
【T-5min 】确认增量延迟为 0 且稳定（连续观察 5 分钟无增长）
【T0 】停写操作：应用切只读/停写开关；确认源库无新写入（用延迟与连接数双重确认）
【T+1min】DTS 完成最后一次增量追平并停止同步
【T+2min】目标库校验：行数对比（抽样大表）+ 关键业务数据点核对
【T+3min】校验通过 → 应用连接切换到目标库；校验失败 → 按回滚检查单执行（见下）
【T+5min】放开业务流量；业务方冒烟验证核心链路
【T+15min】确认无异常，DTS 链路保留（不删除）进入观察期
【观察期 】双跑核对 2~4 周：目标库数据与源库历史快照比对、报表/对账任务复核6. 交付物 3：回滚检查单（"割接 30 分钟内回滚"靠这张单）
markdown
触发条件：校验失败 / 放开流量后 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 负责把"说清楚"的成本打下来、把"讲明白"的遗漏补上------剩下的判断与拍板，正是你不可替代的部分。