数据库迁移工具从单机作业走向云端协同

@toc

我头一回把数据库迁移工具用在这种大型替换项目里的时候，我第一个感觉到的不是它转换得有多快。而是什么呢？是"信息怎么老在丢"。评估的人呢，在一张表里记对象数量。采集的人呢，把脚本全扔在自己电脑上。开发的人，就在群聊里面发那些转换失败的 SQL。DBA 呢，只能等到了晚上再一块儿来回答问题。你看，每个人都在干活，但是项目里面就是没有形成一条能追得下去的链路。这是一个问题。那为什么会这样呢？原因就在于大家各干各的，没串起来。

也就是因为这样，我才算重新去理解了 KDMS 到底在干吗。以前那种老式的单机版工具，你拿来搞点小规模、边界很清楚的任务，那是没问题的。但是在信创项目里面，情况就不一样了。什么叫信创项目的情况呢？就是源库有很多个，要分很多批次，而且是一大帮人一起参与。这时候，迁移工具它就不能光管导入导出了。它还得负责把评估啊、采集啊、转换啊还有后面的支持给组织起来。KDMS 搞的这个"云+端+服务"架构，其实就是把这三个角色给拆开，然后又用一条线连起来。云端嘛，就管迁移评估和项目上的管理。端侧呢，就跑到客户现场去采数据。服务那边，就是让 DBA 在线给你提供支持。它这个架构的价值在哪呢？不在于说它把所有活儿都塞进了一个界面里。而在于，它让你走的每一步，都有记录留下来，都有具体的人负责，而且后面还有跟进的动作。

一、单机版迁移工具为什么容易遇到协同瓶颈

单机工具它不是说不能用。它的问题在于什么呢？在于它的边界，跟大型项目的组织方式对不上号。工具装在某个人的电脑上，那配置文件啊、扫描出来的结果啊、转换的日志啊，也就全跟着这台电脑走了。项目刚开始的时候，可能也就一个工程师在搞。遇到问题，他直接把日志打开看一眼就处理了。但是呢，当项目变大了，变成好几个源库、好几个目标库，还有好几个实施小组一起干的时候。事情就不是那么回事了。

第一个问题，就是评估的口径对不上。不同的人，用的脚本版本可能都不一样。扫同一个东西，可能给出来的分类就不一样。有的人呢，他就只统计表啊、索引啊、存储过程。有的人呢，他还会把应用代码、定时任务还有报表的 SQL 都给算进去。最后你一看算出来的工作量，那根本不是项目真正的工作量。那是什么呢？那就是每个人自己经验凑在一起的一个数字罢了。

第二个问题，就是采上来的结果没法及时地传回去。生产环境啊，通常来说是不允许你把完整的数据直接拉到个人电脑上去分析的。端上采完之后，你得脱敏啊，压缩啊，还得按权限传上去。如果这时候你还是靠人工去拷文件。那版本冲突啊，东西漏了啊，这种事几乎就没法避免。某个源库昨天明明刚采过，今天它里面加了新对象了。但是你的项目表里面，显示的还是昨天那个老结果。这种"看着像是干完了"的状态，其实是最危险的。

第三个问题，就是出了问题没有闭环。转换要是失败了，开发得知道源对象是什么、目标对象是什么、哪句 SQL 报错了，还有建议怎么处理。DBA 呢，得看到怎么复现这个问题，影响范围有多大。项目经理得知道这玩意儿会不会把切换给卡住。但是单机工具呢，它往往仅仅只能留下一份错误日志。它没法把分派问题啊、回复问题啊、验证问题啊给串成一条线。

我会把迁移项目里面要协同的东西，给整理成下面这四类： 这张表看着挺普通的吧。但是呢，它把一句"我已经查过了"，变成了一种"别人能拿过去重新查"的东西。大型项目里面真正缺的，往往就是这种能把活儿交出去的能力。

二、KDMS 的"云+端+服务"分别解决什么问题

1. 云：把评估从一份报告变成项目底账

在 KDMS 这个架构里面，云端主要干的事儿就是迁移评估。它不会直接去连客户现场的数据库。它是干嘛的呢？它是等着接收端上采上来的那些结构化结果。然后对这些对象去分类啊，做兼容性分析啊，估算一下工作量。最后生成一份迁移评估的报告出来。

对于这个报告呢，我个人其实更看重里面的"问题明细"。而不是最后那个所谓的自动化率有多高。一个真正有用的评估结果，它起码得能回答出这几个问题来。有多少表啊，多少视图啊，多少索引、函数和存储过程。哪些东西是可以直接转过去的。哪些语法必须得人工去看一眼。哪些问题其实是应用层那边惹出来的。每一类问题，打算让谁去处理，放在哪一个批次去处理。这样的话，这个评估报告，它就不再只是投标那时候用来凑数的一个估算材料了。它就变成了你真正去实施的时候，手里的一本任务底账。

云端呢，还特别适合拿来搞版本管理。源库你重新采了一次之后，系统就能把这两次的结果拿来做对比。它能分得清哪些是"新加的对象"，哪些是"已经修好的问题"，还有哪些是"一直拖着没解决的问题"。这样一来呢，项目经理就不用对着好几个 Excel 文件去瞎猜进度了。开发的人也能清楚地知道，自己现在手里改的到底是哪一版的对象。

2. 端：在现场完成数据采集，而不是搬走生产数据

端侧呢，其实就是部署在客户环境里的一个采集软件。它要干的活儿就是去连源数据库。然后把对象定义啊、依赖关系啊、配置啊、还有应用的 SQL 这些评估需要的东西给弄下来。接着呢，再按照项目定好的规则把结果传上去。如果是对着生产环境的话，我一般会把端侧的权限设成只读。给连上去的那个账号设好它能访问的范围，设好超时时间，还有并发数不能超过多少。而且，采数据的这个过程，我会让它全记在审计日志里面。

还有一点要搞清楚，端侧采集，它并不等于把业务数据全量给复制一份过来。迁移评估刚开始看的是什么？看的是元数据，还有平时是怎么访问的。只有到了那种明确授权了的验证环节，你才需要去抽一点样本数据出来。你把"采评估信息"和"搬业务数据"这两件事给分开。这么做的好处是，生产环境的压力会小很多。而且，敏感数据离开客户现场的风险也能降低不少。

下面这段 SQL 呢，是我平时用来核对采集结果的一个示意。它其实仅仅是表达一个检查的思路。真正到项目里，字段叫什么、视图叫什么，你还是得去看你用的那个版本的手册。

SELECT object_type,
       COUNT(*) AS object_count,
       SUM(CASE WHEN compatibility_status = 'NEED_REVIEW'
                THEN 1 ELSE 0 END) AS review_count
FROM migration_inventory
WHERE project_id = :project_id
GROUP BY object_type
ORDER BY object_type;

我会把跑出来的查询结果，跟端侧日志里记的扫描数量放在一起交叉对一下。接着呢，再随便抽几个对象出来，看看它的定义全不全。数量对上了，并不代表里面内容就是全的。所以抽样这一步，你是省不掉的。

3. 服务：把 DBA 经验变成在线可复用的支持

服务这边呢，就是让 DBA 或者是迁移专家在线上参与进来。它要解决的一个问题就是："工具把问题找出来了，那接下来谁来拍板呢？"转换引擎它能告诉你，某个语法它不兼容。但是它没法替业务团队去决定，这东西到底应该改写成什么语义。采集端它能报出来一个依赖关系。但是它也没法替项目去决定，到底是先迁哪一批。

在线服务最关键的一点，就是把回答给绑在问题单上。而不是说在聊天软件里扯几句就算完了。每一条给出去的建议，都得关联上源对象是什么、目标对象是什么、是哪个版本的、验证结果怎么样。在这个问题关掉之前，实施的人得重新去跑一下转换，或者测一下 SQL。服务的人得去确认这个结果对不对。然后平台再把关闭的时间给记下来。这么一点点攒下来的处理记录，等下一次碰到差不多的对象，你直接拿过来用就行了。

三、三者怎样形成一条闭环链路

flowchart LR A[云端创建项目与评估规则] --> B[端侧连接源库采集] B --> C[云端生成对象与SQL清单] C --> D[团队分派转换和改造任务] D --> E[端侧执行样本迁移与校验] E --> F[服务侧DBA在线复核] F --> G{验证通过?} G -- 否 --> D G -- 是 --> H[形成批次报告并进入切换]

我一般会把这个项目给拆成六个批次。也就是"评估、样本、全量、增量、切换、观察"。评估这个批次呢，就只管确认对象和风险。样本批次，去验映射规则对不对。全量批次，去处理那些历史数据。增量批次，去验持续同步有没有问题。切换批次，去控停机的时间窗口。观察批次，就把回退的条件给记下来。每一个批次，都得在云端把输入的东西、输出的东西还有最后的结论给留住。这样就不会出现后面阶段把前面阶段的东西给盖掉的情况了。

如果是好几个人一起干呢，还得把权限和职责给写明白。项目管理员，他负责建任务和建批次。采集的人，他只能去管端侧的连接。开发的人，就去处理应用的 SQL 和转换的脚本。DBA 呢，就负责审核给出去的建议。验收的人，就看报告和校验的结果。把权限分这层，并不是说非要给流程添堵。而是为了防止出现谁都能去改关键结论的这种情况。

四、一次实际可执行的 KDMS 项目准备清单

在真正去采数据之前呢，我会先去搞五项准备工作。

第一个呢，就是得把源库和应用的清单给建起来。除了数据库实例，你还得把应用叫什么、怎么连的、批处理作业有哪些、报表平台是哪个、谁负责的，全给登记上。因为很多兼容性的问题，最后其实是出在应用连接和定时任务上的。而不是出在表结构上面。

第二个，定好采集的时间窗口和账号权限。采数据这个活儿，你得躲开业务最忙的那个峰值。连上去的那个账号，一定要用最小权限。而且网络啊、驱动啊、防火墙策略啊，这些你得提前去验一验。如果端侧连都连不上，那你云端报告做得再漂亮，那也是白搭，没有意义。

第三个，把评估的标签给定义好。比如说，你把对象打上"自动转换"、"规则转换"、"人工重构"、"暂不迁移"这样的标签。而且你还得规定好，每个标签你得拿什么东西来当验收的证据。标签定得越清楚，后面分活儿的时候就越顺畅。

第四个，把有代表性的样本给备好。选样本的时候，你不能光挑那种最简单的表。你得把大表啊、复杂的视图啊、关键的存储过程啊、典型的报表 SQL 啊，还有那些边界数据都给覆盖进去。样本越贴近你生产的情况，后面到了全量阶段，不确定的东西就越少。

第五个，把问题关掉的标准给约好。一个问题，它绝对不是"有人在群里回过话了"就算关掉了。它得同时满足几个条件才行。得有处理的方案，得有修改的记录，还得有回归跑出来的结果。而且还得明确说清楚，这玩意儿到底影不影响切换的窗口。

五、协同架构的边界与客观看法

搞了"云+端+服务"，它并不会自己就把迁移的风险给变没。如果说源库的权限本来就乱七八糟的，应用连个日志都没有，业务那边也说不清口径。那不管你用什么工具，最后算出来的评估肯定都是不全的。而且自动转换它也是有边界的。碰到那种牵扯到业务语义的、有外部接口的，还有特别复杂的存储过程。这些东西，还是得靠开发和 DBA 坐在一起商量着来判断。

还有一点，我也不会觉得说用云端管项目，就是把敏感数据给传到云端去了。在真去部署之前，你得搞清楚数据到底是存在哪的，传输的时候有没有加密，脱敏的策略是什么，账号权限怎么分，还有审计有什么要求。对于那种压根就不能出网的环境，你就得按产品支持的那种方式，搞离线部署或者隔离部署。然后让安全团队的人来确认过才行。

你要去理解金仓数据库还有 KingbaseES 的价值，就得把它放在这种完整的工程链路里面来看。它想干的事情，不光是为了证明说这个数据库能把数据收进来。而是说，它想让评估的结果啊、迁移的脚本啊、校验的记录啊，还有上线时候的支持，都能让团队里的人一起拿来用。KDMS 就是通过云端的底账、现场的采集，再加上 DBA 的服务，把这几个环节给串起来了。这种玩法呢，就特别适合那种好多人一起干、得分批次迁，而且还得一直盯着进度的大型替换项目。

六、我对数据库迁移工具的四个判断

第一个嘛，我就看它能不能把应用层也给管起来。别光盯着表和索引导进去的速度有多快。

第二个，看它出来的评估结果，能不能把工作量啊、风险啊、谁负责啊这些东西给量化了。别就给一句轻飘飘的"兼容"就完事了。

第三个，看好几个人一起干的时候，它能不能把版本啊、日志啊、验收的证据啊给留住。这项目能不能顺顺当当交接给别人。

第四个，看出了问题的时候，有没有人能在线上给你支招，还有有没有一条真能跑得通的回退路子。

说到底，数据库迁移工具它伺候的，其实是一项工程。KDMS 搞的这个"云+端+服务"的思路，就是让工具从原来那一堆单机脚本的集合，变成了一个团队可以一起用的项目平台。对于大型信创项目来说，迁移成功，它不光是说目标库上线了就完了。它更意味着说，你用的这套方法，事后是可以拿来复盘的，是可以被审计的。而且在下一次做项目的时候，你还能接着用。

七、把协同结果留成可复查数据

为了不让云端协同最后又变成另一份没人看的"大 Excel"。我会在任务台账里面，给它们保留最起码的结构化字段。下面这个建表的语句呢，它其实仅仅是表达一种管理的思路。在真实项目里，你可以把它对应到 KDMS 里面的任务啊、批次啊还有问题对象上去。

CREATE TABLE migration_task_log (
    task_id          BIGINT PRIMARY KEY,
    batch_no         VARCHAR(32) NOT NULL,
    source_object    VARCHAR(256) NOT NULL,
    task_type        VARCHAR(32) NOT NULL,
    owner_name       VARCHAR(64) NOT NULL,
    status           VARCHAR(16) NOT NULL,
    source_version   VARCHAR(32) NOT NULL,
    updated_at       TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    evidence_uri     VARCHAR(512)
);

SELECT batch_no,
       status,
       COUNT(*) AS task_count,
       COUNT(evidence_uri) AS task_with_evidence
FROM migration_task_log
WHERE source_version = :source_version
GROUP BY batch_no, status
ORDER BY batch_no, status;

evidence_uri 这个字段呢，它可以指向你的转换日志，也可以指向回归的结果，或者是审批的记录。那些没有证据的"已完成"任务，就会被单独给挑出来。这时候项目经理就不用光看那个颜色去猜进度了。

等端侧又重新采了一次之后呢，我还会去跑一次对象数量的差异检查。得先把没采全的问题给揪出来，然后咱们再去聊转换率有多高：

SELECT object_type,
       source_count,
       collected_count,
       source_count - collected_count AS missing_count
FROM migration_inventory_snapshot
WHERE snapshot_id = :snapshot_id
  AND source_count <> collected_count
ORDER BY missing_count DESC;

这个检查啊，它没法替代你去抽样看对象，也没法替代你去做依赖分析。但是呢，它能把那些最明显的断点，尽可能早地给你暴露出来。