做数据库迁移最怕的不是数据搬不过去而是搬过去之后应用起不来。最近我完整跟完了一个 MySQL 到电科金仓KingbaseES下称金仓的迁移项目从结构评估、数据搬运到应用切换、性能调优前后踩了不少坑也总结出一套能直接复用的打法。这篇笔记不画饼只讲真实项目里遇到的东西哪些环节能用工具省事哪些必须人工改写哪些报错你迟早会碰到。适合正在做国产化替代的 DBA、后端开发以及所有准备把 MySQL 业务迁到金仓的团队。整个项目背景大概是这样的业务系统是 Java Spring Boot 技术栈ORM 用的 MyBatis连接池用的 Druid源库是 MySQL 5.7接近两千张表总数据量在 TB 级别其中有几十张大表单表过亿行的也有两三张。目标库是电科金仓要求业务不停太久切换窗口只有四小时。这个条件决定了我们不能靠“导出 SQL 再导入”这种粗暴方式硬来必须提前把兼容性、数据校验、回退方案都设计清楚。后面我把整个过程拆成五个阶段来写每个阶段都附上当时踩坑后的最终解法希望能给后面做同类迁移的人省点时间。1. 迁移前不要急着动手先看懂金仓与 MySQL 的差异逻辑1.1 金仓是什么迁移的本质是什么电科金仓KingbaseES是国内主流的国产关系型数据库产品长期在党政、金融、能源、电信等领域落地整体兼容 PostgreSQL 生态同时对外提供 MySQL、Oracle 等常见数据库的兼容特性。很多人第一次接触它会下意识觉得“既然兼容 MySQL那把库搬过去就行了”。这个想法很危险。兼容不等于同构MySQL 和 PostgreSQL 体系在数据类型、SQL 语法、存储引擎、事务特性上的差异是根深蒂固的金仓做的兼容只是让大部分常规 SQL 能跑但边界以外的写法一样会报错。我更愿意把这次迁移的本质理解为“换一套 SQL 解释器”。数据是死的怎么读、怎么写、怎么约束、怎么优化完全由数据库的解析和执行逻辑决定。举个生活化的例子搬家不是把箱子搬进新房子就结束你还得看新家的门够不够宽、插座在哪个位置、家具摆不摆得进去。MySQL 里的表结构、存储过程、SQL 写法就是这些“家具”金仓就是“新房”能不能顺利住进去取决于你提前做了多少适配。所以迁移项目的第一个阶段不应该是一上来就拉数据而是先做差异分析。我当时花了整整两天把项目的表结构、存储过程、SQL 日志、ORM 映射文件全部过了一遍列出一份兼容性风险清单。后面所有的工作量评估、工具选型、人员分工都是从这份清单推导出来的。没有这一步后面一定会被各种莫名其妙的报错打乱节奏。1.2 迁移方案选型一次停机迁移还是增量同步迁移方案没有银弹完全取决于业务容忍度和数据规模。我们当时评估了两条路线。第一条是停机迁移。在约定窗口内停应用、导数据、验证、切换好处是流程简单回退就是恢复原库坏处是窗口不够用时非常被动。第二条是在线迁移加增量同步源库继续跑业务工具持续把增量变更同步到金仓切换时短暂停写做最终追平和切换。这条路线对工具要求高但能把业务中断时间压到分钟级。判断标准其实就三条数据量多大、停机窗口多长、团队对工具的熟练度。我们数据量在 TB 级窗口只有四小时走纯停机迁移风险太高最后选了“全量迁移先行 增量同步追平 窗口内切换”的组合方案。操作顺序是先做一次全量数据迁移同时开启增量同步验证阶段持续对比两边的数据一致性到了正式切换窗口停写入等增量位点追平再做切换。这样既保证大白天的业务不受影响窗口内要做的事情也收敛到“校验 切换”两件事。这里必须多说一句增量同步只是手段不是目的。如果业务允许停两小时数据量也不大我反而建议用最简单的一次性停机迁移少引入一个同步工具就少一类故障源。1.3 迁移前的对象清单与风险盘点动手之前我建议先做一张“迁移对象全景表”把源库所有对象类型列清楚。我们当时的盘点表大概长这样对象类型检查项风险等级备注表数量、数据量、字符集、存储引擎高InnoDB 为主MyISAM 需要额外关注锁行为索引索引类型、索引长度、列排序规则高MySQL 的索引长度限制与 PG 体系不同视图是否依赖特定函数中涉及自定义函数时容易翻车存储过程数量、复杂度、依赖关系极高MySQL 过程语法与 PG/金仓差异大触发器触发时机、触发表、逻辑高迁移后经常出现“不触发”或重复触发定时任务调度方式中需要重新在金仓侧建成调度任务分区表分区类型、分区键表达式中MySQL 和 PG 语法差异明显自增列AUTO_INCREMENT 用到的所有表高金仓使用序列或 IDENTITY 实现这张表的价值在于让你在开工前就知道“雷区在哪里”。我们项目里存储过程是最重的负担旧系统有上百个存储过程里面有大量的游标、动态 SQL、异常处理这类对象基本不可能靠工具自动翻译只能手工重写。另外一个容易忽略的点是字符集MySQL 的 utf8mb4 和金仓的 UTF8 看起来都是“UTF-8”但排序规则、索引长度单位、客户端连接的编码设置都有差异最好在验证阶段就拿真实中文数据做一遍读写测试。2. 语法兼容性的边界这些差异决定了你要改写多少 SQL2.1 数据类型差异对照与处理数据类型是结构迁移的地基地基打歪了后面数据导入、应用查询都会出问题。MySQL 的类型体系跟 PG 体系差距不小尤其是无符号整数、自增列、JSON、ENUM 这些特性。我整理了一份自己项目里实际用到的类型对照表可以给读者参考MySQL 类型金仓建议类型注意事项INT / BIGINTINTEGER / BIGINT去掉显示宽度如 INT(11) 改成 INTEGERINT UNSIGNEDBIGINT 或 NUMERIC无符号范围超过有符号需要评估是否扩位TINYINT(1)SMALLINT 或 BOOLEAN看业务是当布尔用还是当数字用VARCHAR(n)VARCHAR(n)注意字符数和字节数的索引长度差异DATETIMETIMESTAMP注意默认值、时区行为不同TIMESTAMPTIMESTAMP建议显式设置 TIME ZONE 相关参数TEXT / LONGTEXTTEXT / CLOB大字段读取方式需在应用层验证BLOBBYTEA驱动参数、流式读取方式需调整JSONJSONB操作符完全不同应用 SQL 必须改ENUM / SETVARCHAR CHECK建议改造为字典表或 CHECK 约束DECIMALNUMERIC一般直接对应注意精度检查处理策略上结构迁移工具能把建表语句转成金仓方言但工具只解决“能不能建出来”不解决“语义对不对”。举例来说MySQL 的 INT UNSIGNED 在迁移工具里可能被映射成 NUMERIC 或 BIGINT看起来没报错但如果应用里原来往这个字段塞负数的时候依赖 MySQL 的报错兜底迁移后行为就变了。这种隐藏差异必须在 code review 阶段逐字段确认。另外MySQL 的 ENUM 类型在金仓里往往没有直接对应项工具可能帮你转成 VARCHAR。从功能角度没问题但从约束角度就弱化了原来传一个不在枚举里的值MySQL 会报错或警告改成 VARCHAR 后就静默接受了。稳妥的做法是额外加 CHECK 约束或者干脆做成字典表外键。2.2 DDL 与 SQL 语法差异实例这个部分是整个迁移里工作量最集中的地方。不是所有 SQL 都要改但典型场景几乎都会命中。先说自增列。MySQL 写起来极其自然CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(64) NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这在金仓里要改成序列或者 IDENTITY 列。用 IDENTITY 最简单直接CREATE TABLE users ( id INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, name VARCHAR(64) NOT NULL );注意 GENERATED BY DEFAULT 和 GENERATED ALWAYS 的区别。如果原来的应用会在 INSERT 语句里显式指定自增列的值一定要用 BY DEFAULT否则插入会报错。这个细节我们第一次迁移就踩了某个数据修复脚本一直都带着 ID 值插入结果在金仓上直接失败。分页语法也是重灾区。MySQL 的LIMIT m, n表示跳过 m 行取 n 行金仓以及整个 PG 系语法是LIMIT n OFFSET m。MyBatis 里类似写法非常多!-- MySQL 写法 -- SELECT * FROM orders ORDER BY create_time DESC LIMIT #{offset}, #{pageSize} !-- 金仓写法 -- SELECT * FROM orders ORDER BY create_time DESC LIMIT #{pageSize} OFFSET #{offset}看起来只是换个位置但如果项目里大量使用 PageHelper 这类分页插件插件底层生成的方言 SQL 也得跟着换否则分页结果可能对不上甚至直接语法报错。INSERT ... ON DUPLICATE KEY UPDATE是另一个高发点。MySQL 用户特别喜欢这种“存在即更新不存在即插入”的写法但金仓不认这个语法。改造时有几个方向如果只是“存在就跳过”可以用INSERT ... ON CONFLICT DO NOTHING如果要“存在就更新某个字段”PG 系的ON CONFLICT (uk_col) DO UPDATE SET ...可以替代如果冲突判断逻辑特别复杂我建议拆成先 SELECT 再 UPDATE/INSERT虽然多一条语句但业务逻辑最清晰。金仓对 ON CONFLICT 的支持情况要以实际版本为准所以迁移前一定要用一条简单的冲突插入语句去目标库做冒烟测试。字符串和时间函数的差异也很容易埋雷。我们项目里遇到最多的几个是GROUP_CONCAT在 PG 系里对应string_aggIFNULL对应COALESCEDATE_FORMAT通常要改成to_charDATE_ADD(now(), INTERVAL 1 DAY)要改成now() INTERVAL 1 day。这些函数名不熟的话报错都看不懂比如function date_format(timestamp without time zone, unknown) does not exist看到这种提示第一反应应该是去函数对照表里查而不是去猜。2.3 索引、约束与分区表差异索引和约束在三层迁移里优先级很高因为它们在数据导入阶段直接影响导入速度和数据完整性。MySQL 的索引定义里经常带 USING BTREE这个在金仓里不是问题能兼容就兼容不能兼容的地方工具会去掉。真正麻烦的是索引长度限制。MySQL 在 utf8mb4 下InnoDB 的索引前缀长度限制是 3072 字节早期版本是 767 字节所以有些大 varchar 列的索引会写成INDEX idx_name (name(50))这种前缀索引。PG 系体系对索引长度的处理和 MySQL 不一样工具转换时不一定能自动处理这种前缀索引我们当时的做法是能改字段长度的改字段长度不能改的评估是否用表达式索引或者干脆去掉这列索引靠应用层查询优化兜底。外键命名也要注意。MySQL 允许外键约束名在库内唯一即可金仓更接近 PG 的规则约束名在某些场景下的可见范围不一样导致工具转换时可能产生重名。这种问题通常在结构迁移时报错才暴露处理办法就是批量重命名规则统一成表名_列名_fk这种格式。分区表方面MySQL 的 RANGE 分区可以直接在 CREATE TABLE 语句里定义分区子句而 PG 体系金仓整体也沿袭这个思路更推荐声明式分区-- MySQL 风格 CREATE TABLE logs ( id INT, created_at DATE ) PARTITION BY RANGE (YEAR(created_at)) ( PARTITION p2023 VALUES LESS THAN (2024), PARTITION p2024 VALUES LESS THAN (2025) ); -- 金仓更推荐的方式 CREATE TABLE logs ( id INT, created_at DATE ) PARTITION BY RANGE (created_at); CREATE TABLE logs_p2023 PARTITION OF logs FOR VALUES FROM (2023-01-01) TO (2024-01-01);还有一个很容易忽略的点MySQL 的 FULLTEXT 全文索引和 SPATIAL 空间索引在金仓里基本没有直接对应实现。我们项目里有一张表用了 FULLTEXT最后改造方向是简单场景用金仓的全文检索能力重写复杂场景建议把检索需求外置。空间索引这种更不建议硬迁要么改造成应用层用经纬度范围计算要么单独引空间计算组件。3. 迁移实操从结构、数据到应用三层突围3.1 迁移工具链与整体流程工具的选择直接决定项目是“有条不紊”还是“到处救火”。金仓官方提供了数据库迁移评估和同步的工具市面上的通用 ETL 工具也能用但我的建议是评估和结构迁移优先用官方工具因为它们对自家数据库的方言最熟数据迁移可以结合官方工具和自研脚本大表部分用能控制并发和批次的方案。我们最终的流程分成四步第一步用评估工具扫描源库生成兼容性评估报告第二步用迁移工具批量转换表结构然后人工 review 差异第三步全量数据迁移加增量同步期间做多轮数据校验第四步应用层改造和切换演练。每个步骤之间都有明确的完成标准和输出物不达标不进下一阶段。这一步的价值在后期体现得非常明显切换当天我们只花了不到两小时完成全部工作剩下时间都在做性能抽查和备份验证基本没有慌乱。3.2 结构迁移先建表再建索引最后建约束结构迁移看着简单实际上有一个顺序问题。我们第一次尝试时用工具把 MySQL 的建表语句一次性转换到金仓包括所有索引、外键、检查约束结果大表结构创建特别慢还不断报外键依赖错误。后来调整成三步走先只建表和字段不建任何索引和约束再批量建主键、唯一键和普通索引最后建外键和 CHECK 约束。理由很简单PG 体系在建表时带一堆索引约束等于每个索引都要写一遍数据大表会非常慢而外键如果依赖的父表还没建好或者数据还没导完校验会失败。分批建的好处是可以清晰看到每类对象的报错不至于所有问题挤在一起难以定位。结构迁移完成后我强烈建议做一次“影子库对比”把同一套建表语句分别放到一个临时 MySQL 和金仓上查询 information_schema 或系统目录逐表对比字段个数、字段类型、默认值、可空性。我们靠这个对比找出了一百多处工具转换错误绝大多数是 default 值表达式和类型宽度问题。这个动作虽然费时间但比上线后让业务方发现问题划算得多。3.3 数据迁移大表要分片小表要并行数据迁移是大头TB 级量级下不可能一条一条搬。我们实际用了组合方案。第一种是官方迁移工具直连迁移适合中小表配置好源库和目标库连接选择映射关系工具自动完成。第二种是导出导入方案对于官方工具处理不好的大表先用 mysqldump 导出为文本再清理掉 MySQL 特有的语法用金仓的导入工具加载# 导出时跳过建表语句只导数据使用完整插入并统一字符集 mysqldump -h源库 -u用户 -p密码 --no-create-info --complete-insert \ --skip-comments --skip-add-locks --default-character-setutf8mb4 \ 数据库名 表名 表名.sql # 文本里通常会残留反引号、ENGINE 等 MySQL 特有内容先做文本清理 sed -i s///g 表名.sql但说实话纯 sed 清理很容易翻车因为数据本身可能包含特殊字符。我们当时对大表专门写了一个类似 DataX 的同步任务按主键范围分片每一片一个线程分批提交限速控制。这样既保证了并发又避免大事务把目标库撑爆。导入时还有个技巧关闭目标表索引和约束导完成后再重建速度能快好几倍。数据校验不能只靠 count我们做了三层校验第一层全表 count 对比确认行数一致第二层关键表的聚合值对比比如 SUM 指定列、MAX 时间第三层抽样表的逐行 checksum 对比。抽样表优先选业务核心表和数据字典表因为这两类表最容易暴露字符集、精度、时间偏移问题。3.4 JDBC 驱动、连接池与 ORM 适配应用层改造是“搬过去之后应用能跑起来”的关键。拿 Java 项目来说第一步就是换驱动。# 原 MySQL 配置 spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver spring.datasource.urljdbc:mysql://192.168.1.10:3306/appdb?useSSLfalsecharacterEncodingutf8serverTimezoneAsia/Shanghai # 迁移到金仓后 spring.datasource.driver-class-namecom.kingbase8.Driver spring.datasource.urljdbc:kingbase8://192.168.1.20:54321/appdb这里有个坑原来 MySQL URL 后面带的一大堆参数比如useSSL、serverTimezone、rewriteBatchedStatements金仓驱动不认识直接放在 URL 里会报Unsupported connection property。所以迁移时要把这些参数全部去掉字符集和时区统一在数据库侧或服务端参数里配置。连接池也要跟着调。Druid 的validationQuery原来是SELECT 1这个金仓支持但如果你配了别的验证语句就要注意方言兼容。更隐蔽的是 Druid 的 SQL 防火墙插件 wall它内置的 MySQL 语法白名单可能不认识 PG 风格的 SQL导致正常查询被拦截。我们当时直接先关掉了 wall filter等业务验证通过后再按需开放。HikariCP 相对省心一些需要重点检查的是connection-init-sql、schema这些配置项。MyBatis 的 XML 映射文件里有大量 SQL 需要过一遍。除了前面说的分页语法还有几个高频点useGeneratedKeys拿到自增主键的配置要检查是否兼容动态 SQL 里用了 MySQL 专有函数的需要替换如果映射文件里直接写NOW()金仓支持但如果写SYSDATE()就要改成CURRENT_TIMESTAMP或now()。我们当时的做法是写一个脚本扫描 XML 里的函数名和关键字先机器挑出可疑点再交给开发人工确认比纯人工逐文件翻效率高一个量级。4. 常见问题与排查技巧实录4.1 连接层的经典报错应用切换后第一个报错往往不是 SQL 问题而是连接问题。最常见的是No suitable driver found for jdbc:kingbase8://...。这个错误九成是驱动 JAR 没打进应用或者 URL 前缀跟驱动注册名不匹配。排查顺序是先确认com.kingbase8.Driver这个类在依赖里存在再确认 URL 前缀是jdbc:kingbase8://然后用一个最简单的 JDBC 测试类直连数据库把问题收敛在应用还是环境。还有一个很微妙的报错连接池启动成功了但执行第一条 SQL 就报function xxx does not exist或者字符集相关的异常。这通常是驱动版本和服务器版本不一致导致的。金仓的不同小版本之间协议或元数据查询方式可能有变化所以应用侧驱动版本一定要和目标库版本配套不要想当然用最新的。这类问题特别像“玄学”其实查一下版本兼容矩阵就能定位。4.2 SQL 执行与对象迁移报错我们把迁移过程中高频出现的 SQL 层报错整理成了一个速查表这里分享最有代表性的几个。第一个是反引号报错。MySQL 写惯了的人建表、写 SQL 都喜欢带反引号金仓不认识直接报syntax error at or near 。解决办法就是全局清理反引号。第二个是ON DUPLICATE KEY UPDATE语法不支持这个前面说过用ON CONFLICT改写。第三个是字符串函数不存在比如FIND_IN_SET这个函数 PG 系没有直接对应需要改成position(, || ? || , in , || col || ,) 0 这类写法或者由应用层处理。存储过程的报错是最让人头疼的。MySQL 存储过程喜欢用DECLARE ... CURSOR FOR、IF ... THEN ... END IF金仓的过程语言更接近 PL/pgSQL变量声明的位置、异常处理方式都不同。一个正常情况下几百行的存储过程重写之后可能要拆成多个函数还要重新设计事务边界。我的建议是遇到复杂存储过程先不要急着翻译先看业务逻辑能不能搬到应用层用 Java 或 Python 实现往往比在数据库里写过程更容易维护。如果必须留在数据库里就用 PL/pgSQL 重写逐段验证别指望一次写完直接跑通。4.3 迁移后性能问题定位与解决数据过去了应用起来了不代表事情结束了。性能问题往往是压垮迁移的最后一根稻草。我们当时遇到的最大问题是同一套 SQL在 MySQL 上走索引毫秒级返回到了金仓上变成全表扫描大表查询直接超时。第一个原因是统计信息缺失或过期。PG 体系默认会自动收集统计信息但大批量导入之后自动收集的触发频率可能跟不上导致优化器拿到的是“空表”的统计值选错了执行计划。解决办法简单粗暴对迁移的核心表手动执行ANALYZE甚至可以连续跑两次让统计信息稳定下来。第二个原因是隐式转换。最常见的情况是字段类型是 VARCHARSQL 条件里传了数字或者两边字符集排序规则不一致导致索引失效。排查时用执行计划看有没有Filter而不是Index Scan基本就能确认。还有 LIMIT 深分页问题MySQL 和 PG 一样都有这个问题但金仓上表现更明显LIMIT 100000, 10这种深翻页会把前十万行都翻一遍优化方向是改成基于游标的 seek 分页用WHERE id ? ORDER BY id LIMIT 10替代。慢 SQL 定位要靠工具。金仓沿袭 PG 生态的思路我们可以打开慢查询日志或者查询统计视图按总耗时排序找出 TOP SQL。我们当时专门写了一个定时任务抓取慢 SQL 并自动发送到群里连续跑了两天就摸清了主要瓶颈某张核心大表的 JOIN 条件字段类型不一致以及某个报表 SQL 用了函数包裹索引列导致函数索引没走到。4.4 数据一致性问题的排查数据迁移后最常见的一致性问题有三个中文乱码、时间偏移、精度丢失。中文乱码的根源基本都在字符集。我们的做法是在迁移前先做一次端到端验证挑一张含中文的大表从 MySQL 导出、搬到金仓、再查出用十六进制对比中文内容确保数据从源头到目标库全程一致。注意客户端连接参数也要统一如果你用命令行工具连金仓客户端编码和服务端不一致显示乱码不代表数据本身错这时候要检查客户端编码设置。时间偏移问题集中在DATETIME和TIMESTAMP的换算上有时候差值正好是 8 小时去检查时区和 JDBC URL 参数即可。精度问题多半是 FLOAT/DOUBLE 迁移成 DECIMAL 后位数不对或者反过来解决方案是迁移前把需要精确计算的字段统一设计成 NUMERIC并明确小数位数。5. 切换与验收怎么才算真正迁移成功5.1 切换前验证清单我们切换前整理了一份验证清单每一项都有明确的方法和通过标准。这里挑几条供参考验证项方法通过标准功能测试全部核心流程走一遍无阻断性缺陷数据一致性全表 count 核心表 checksum与源库完全一致性能基准对 TOP 50 SQL 做回放耗时在业务容忍范围内并发压测模拟高峰流量打金仓连接数、CPU、IO 正常备份恢复做一次逻辑备份和恢复演练恢复后数据完整回退方案记录回退步骤验证回退脚本能在窗口内回退清单有一条原则宁可标准严一点也别把风险带到切换后。尤其是备份恢复演练这个最容易被忽视一旦切过去之后发现数据有问题要回退如果备份方案本身没验证过那才是大事故。5.2 回退方案与切换窗口切换窗口开始前我们保留了 MySQL 环境整整一周没有立刻销毁。切换动作本身分三步停应用写入、等增量同步追平、把应用连接切到金仓。回退方案就是反着来保存切换时刻的增量位点一旦金仓侧验证不过立刻切回 MySQL再用同步工具反向追平数据。理论上回退一定是有损的因为两边可能各有新增数据实际执行时要提前跟业务方对齐“可接受丢失范围”。这里有个实操技巧正式切换前一定要做至少一次“全流程演练”。演练时故意制造几个故障比如让某个服务启动失败、让某张表数据校验不过看看团队的反应和预案是否可靠。演练暴露出来的问题比正式环境上的事故要好处理一百倍。5.3 迁移后的运维要点切到金仓之后运维方式要跟着数据库形态变。金仓整体接近 PG 体系所以很多习惯要改备份逻辑用逻辑备份工具思路类似pg_dump/pg_restore大批量数据变更后要手动做ANALYZE有大量更新删除的表要关注版本膨胀问题必要时要执行清理和维护操作。MySQL 的SHOW PROCESSLIST、SHOW ENGINE INNODB STATUS那套排查习惯到金仓上要换成查系统视图、看统计信息、抓慢 SQL 的新思路。监控指标也要重新梳理。重点看连接数、活跃会话、缓存命中率、磁盘 IO 延迟、慢 SQL 数量。我们切换后前两周每天早会都过一遍这些指标发现慢 SQL 阈值就自动告警及时处理了两类问题一类是统计信息过期导致的执行计划漂移一类是应用里残留的 MySQL 方言 SQL。这些问题如果放着不管积累到后面就是稳定性大坑。5.4 我踩过的几个深坑最后分享几个我个人的深坑体会可能比前文所有技术细节都值钱。第一不要太相信迁移工具。工具能帮你完成七成工作剩下三成必须靠人工 review特别是存储过程、触发器、默认值表达式、字符集相关配置。我们前期吃了这个亏导致结构迁移返工了两天。第二低估了 MySQL 方言的渗透范围。原以为 SQL 都写在 MyBatis 的 XML 里结果发现还藏在定时任务脚本、数据修复脚本、运营后台的动态查询里这类场景最容易被遗漏。第三没有做充分的“影子验证”。我们应该在迁移全量数据的第二天就用真实流量在金仓上跑一遍只读请求而不是等到切换当天再验证那样发现问题已经晚了。项目收尾那天我在复盘会上说了一句话成功的迁移不是切换那一刻不出错而是出错的时候你能在十分钟内定位问题、半小时内回退或者修复。这套从评估、迁移、验证到切换的方法论就是在给你争取这十分钟和半小时。希望这篇笔记能帮你少踩几个坑真到要上手的时候心里有底。
