文章目录项目背景先简单说两句重头戏45TB日增量下的全链路并行同步割接那一夜项目收尾和之后的事最后说两句掏心窝子的兼容是对前人努力的尊重是确保业务平稳过渡的基石然而这仅仅是故事的起点上半篇光顾着吐槽和讲KDMS评估了这篇往下说聊聊报告拿到手之后一个迁移项目到底是怎么一步步落地的。先交代下背景还是拿我最熟的那个运营商的项目说吧。这个项目规模在我做过的单子里算大的而且时间紧典型的又想马儿跑又想马儿不吃草。但也正因为难做整个流程跑得比较完整拿出来讲比较有说服力。项目背景先简单说两句客户是某省运营商的资源中心管的是全省的网络资源数据——基站啊、光缆啊、机房啊、设备端口啊这些全在这个库里。你们可以想象一下这个数据量级一个省的通信网络资产几千万条记录都是少的。源端是Oracle老库跑了很多年业务系统7×24小时不能停。日均数据增量我记得当时测下来是45TB左右。对你没看错日增量45TB不是总量。这数据量让我头都大了。客户的要求很明确一不能长时间停机二数据不能丢不能错三迁完性能不能拉胯。这三条任何一条出问题都是生产事故。进场之后第一步不用说老规矩KDMS采集评估。这个过程上篇讲过了就不重复直接说评估出来的结果怎么用。KDTS 迁移任务配置示意 ───────────────────────────── 源端Oracle / 192.168.x.x:1521/ORCL 目标端KingbaseES / 10.x.x.x:54321/resource_db 迁移对象☑表 ☑索引 ☑约束 ☑序列 ☑视图 ☐存储过程单独处理 迁移方式只迁结构 / 结构数据 并发线程数8 失败处理记录日志并继续 ─────────────────────────────结构迁移的成功率一般很高我们几个项目基本都在99%以上但每次我都会核对几个东西字段类型映射对不对、字符集有没有坑、自增列/序列的初始值对不对、外键约束建全了没。字符集这个事情单独说一句太容易踩坑了。源库如果是ZHS16GBK目标库用UTF8迁移过程中字符集转换是自动的大部分中文没问题但生僻字、特殊符号偶尔会出乱码或者长度溢出——GBK里一个汉字两个字节UTF8里三个字节你要是有个字段定义成VARCHAR2(10)里面存了五个汉字GBK正好10字节转UTF8要15字节目标库字段如果按字节长度算直接插不进去。所以我习惯把存中文的字段按字符语义定义或者干脆长度留足余量-- 稳妥的写法按字符算长度CREATETABLEt_customer(idINTEGER,nameVARCHAR(50CHAR));这种细节评估报告有时候会提醒有时候不会全靠自己记性好。我反正是吃过亏的现在逢人就念叨。重头戏45TB日增量下的全链路并行同步结构搭好了存量数据也好处理KDTS直接全量拉过去虽然量大但不复杂跑就是了跑慢一点而已。真正要命的是增量——你全量迁移总要花时间吧这几天里源库业务不停新产生的数据怎么办靠KFS。KFS就是金仓那套异构数据同步的东西逻辑日志解析那套机制从源库的redo日志里把变更捞出来实时搬到目标库。原理我不展开网上资料很多重点说说这个项目里最折磨人的部分——性能。全链路并行拆开之后大概是这么个结构KFS 全链路并行架构简化版 ───────────────────────────────────── 源端Oracle │ ▼ [日志读取] ── 多线程并行解析 │ ├── 按表/事务分组分发到多个通道 │ ▼ [网络传输] ── 多通道并发传输支持压缩 │ ▼ [目标端入库] ── 多事务并行应用 │ 有依赖的保序无依赖的并发 ▼ 目标库 KingbaseES ─────────────────────────────────────这里头技术上最难的是最后一环——并行入库。你想啊事务之间是有依赖的事务A改了某行事务B也改同一行这俩要是并行应用、顺序反了目标库的数据就错了。但如果为了保序把所有事务串起来又退化成单线程了。它的做法是分析事务依赖关系有冲突的事务之间保证顺序没有依赖的——比如改的是不同的表、不同的行——就可以放心并行。这个依赖分析是实时做的基于主键、外键和实际变更行的信息。配置上有几个关键参数当时我们调了好久# KFS 并行同步相关参数节选具体名字以实际版本为准 # 解析并行度 parser.parallel.threads8 # 传输通道数 channel.count16 # 目标端应用并行度 applier.parallel.threads24 # 大表是否拆分并行 bigtable.parallel.enabletrue # 冲突检测策略基于行依赖 dependency.track.moderow # 批量提交大小 applier.batch.size2000 # 网络传输压缩 transport.compresslz4参数不是越大越好线程数开太多目标库那边连接数、CPU、IO扛不住反而变慢。我们当时是一边压测一边调从8线程开始往上加盯着目标库的负载和同步延迟最后找到一个平衡点——24个应用线程的时候目标库CPU大概六七十IO没打满延迟稳定在秒级。再往上加线程数据库成了瓶颈吞吐不涨反跌。还有个杀手锏大表的初始同步可以拆成多段并行跑。那种几十亿行的超大表单线程select拉数据得拉好几天按主键范围切成几十段多线程同时拉时间直接压缩到原来的几分之一。这个对我们这种存量数据巨大的项目特别关键。-- 大表分段的思路大概就是这样按范围切-- 每一段独立抽取、独立装载-- 第1段SELECT*FROMt_resourceWHEREidBETWEEN1AND100000000;-- 第2段SELECT*FROMt_resourceWHEREidBETWEEN100000001AND200000000;-- ...以此类推那段时间我天天盯监控KFS自己的控制台能看到每个通道的TPS、堆积量、延迟。有天半夜告警某个通道延迟突然飙到几分钟我爬上去一看是源端半夜跑批量大事务单个事务改了几千万行按顺序应用的时候把通道堵住了。后来调整了大事务的拆分策略才稳住。这种问题不经历一次真是想都想不到。割接那一夜前面所有事情——评估、改造、全量、增量同步、校验——都是为了最后这一下割接。割接的核心目标说起来就一句话选一个业务低峰期把源库停写等KFS把最后一点增量追平、最后做一次快速校验确认然后把应用切到新库。但就是这么简单一件事每次做都紧张得不行。因为这是唯一没有后悔药的环节前面出问题都能重来割接失败就得回退动静越大越被动。我们当晚的安排大概是这样割接时间线凌晨低峰窗口 0:00 - 4:00 ──────────────────────────────────── 23:30 全员到位最后确认各系统状态 KFS延迟检查要求秒级 应用、监控、回退脚本全部就绪 00:00 应用停止写入源库只读模式/停应用 通知割接正式开始 00:05 KFS进入追尾模式消费剩余日志 实时监控延迟归零 00:20 增量追平源端目标端位点一致 00:25 最终快速校验链式校验的精简模式 关键表行数、关键聚合值确认 00:45 校验通过 00:50 修改应用数据源配置指向新库 提前准备好配置切个开关的事 01:00 应用启动内部冒烟测试 登录、查询、下单、修改 全流程走一遍 01:30 小流量灰度放少量真实用户进来 盯错误日志、盯性能指标 02:00 全量放开 02:00-04:00 全员留守观察 重点盯慢SQL、报错率、业务指标 ────────────────────────────────────我为什么一直强调前期的评估和校验重要你们看这个时间线割接窗口只有四个小时其中留给出意外的余量非常小。如果同步延迟追不平、或者校验发现大量差异这个窗口根本兜不住只能取消割接、白熬一夜还要跟客户解释为什么延期。而同步能不能按时追平取决于你前面的并行架构调没调好校验能不能快速通过取决于链式校验靠不靠谱甚至割接后应用会不会报错都取决于前期KDMS有没有把应用里的SQL扫干净。割接那一夜的从容全是前面几个月攒下的。那天晚上实际还真出了个小插曲。应用切过去之后冒烟测试发现一个查询接口超时要十多秒才返回。当时全场气氛都凝固了。我们DBA赶紧上去看执行计划发现是一张大表的统计信息没收集优化器走了个糟糕的全表扫描。当场analyze了一下再查毫秒级返回。虚惊一场。但这个事情给我提了醒从那以后割接检查清单里我加了一条全量数据迁完后、割接前务必把目标库所有大表的统计信息重新收集一遍。这种坑踩一次就够记一辈子了。回退方案也必须提前准备好。当时我们的预案是如果新库出问题短时间解决不了就把数据源切回源库同时KFS开反向同步——把割接期间新库产生的增量数据同步回老库保证回退之后数据不丢。所幸最后没用到但带着这根救命稻草心里踏实。项目收尾和之后的事割接成功不代表项目立马结束。后面还有一周左右的护航期团队轮班盯新库的运行情况处理一些小问题——大多是边角报表SQL的兼容性不影响主业务。这期间KFS反向链路一直挂着作为回退保险。等一周过去系统稳稳当当才把同步链路彻底关掉、老库做归档项目才算真正收尾。这个运营商项目整体做下来我最大的感慨是现在做迁移和我刚入行那会儿真的是两个时代了。刚入行的时候迁移基本靠人肉拿个老DBA的经验赌迁完对数据靠运气割接靠胆子。现在呢评估有KDMS出量化报告结构有KDTS自动迁移增量有KFS全链路并行校验有链式校验层层收敛甚至割接后的差异都能自动修复。整个过程里人更多是在做判断、做兜底、处理那些真正需要理解业务的复杂问题而不是把时间浪费在机械重复的体力活上。但我也不想把话说得太满好像有了工具就能躺赢。工具再强有几件事永远只能靠人一是理解业务。报告告诉你这个PACKAGE要改但这个PACKAGE为什么这么设计、改动会不会影响某个业务约定工具不知道。有次我们改一个计算逻辑语法转得漂漂亮亮结果上线后财务对账差了几分钱——老逻辑里有个四舍五入的特殊约定代码里没有任何注释全靠跟客户那边的老业务人员聊才挖出来。二是做取舍。比如位图索引转B树、包级变量用什么方案模拟、某个慢SQL是改写法还是加索引这些都不是有标准答案的题得结合负载、结合运维成本、结合团队能力综合权衡。三是应急。割接那晚统计信息的问题工具不会自己跳出来帮你解决靠的是DBA的经验和临场反应。所以我对这些工具的定位一直很清楚它们把迁移项目的下限抬高了让你不至于因为没看到某个角落的问题而翻车但项目的上限——能不能做得又快又稳又省心——还是取决于用工具的人。最后说两句掏心窝子的这两篇写得有点啰嗦想到哪说到哪大家凑合看。如果你也在做或者即将做异构迁移我的建议就一条别省评估那点时间。我见过太多项目火急火燎地开工迁到一半才发现存量复杂度远超预期进退两难。花一天时间把KDMS跑一遍拿到那份报告你对项目的理解会上一个台阶——知道水有多深才好决定怎么蹚。评估报告里那些数字——多少对象、多少兼容、多少要改、多少人天——看着枯燥但它们是整个项目里最值钱的东西。因为它们把一个本来充满不确定性的决策变成了可以摆到桌面上讨论的事实。项目会上领导问风险有多大、多久能干完你不用再支支吾吾说应该问题不大而是把报告摊开一条一条指给他看。这种感觉干过项目的人都懂踏实。哦对还漏了个事儿没说就是那个环保集团的项目顺便提一嘴因为它代表了另一种场景。那个客户是东部某省的环保集团跟运营商项目不太一样它不是单一大库是十一个核心业务系统一起换——环保一体化、OA、投资管理、人力资源、数据中台、采购、供应链金融等等一大堆。原来底下用的库五花八门好几种都有等于要一锅端。这种多系统的局面KDMS评估反而是一个系统一个系统地跑出了一摞报告最后汇总。好处是每个系统的风险都清清楚楚哪个系统先迁哪个后迁、各自需要多少资源可以统筹着排兵布阵而不是十几条线同时开工乱成一锅粥。实际做下来真正需要人工干预的适配问题只有两个我印象很深。一个是某张叫sys_user的表跟系统视图重名了应用查的时候解析到错误的对象上去最后靠JDBC连接参数里加个配置解决的。另一个是一条监测汇总的SQL老库上要跑15秒迁过去之后我们重新建索引、把关联精简了一下最后1.8秒快了快九成。客户那边负责的人原话是干预极少全程几乎没什么问题——这话从甲方嘴里说出来分量你们懂的。举这个例子是想说不管是运营商那种单一大库大流量还是环保集团这种多系统多源端前期评估这一步的逻辑是通用的先把家底盘清楚再动手。盘子不一样道理是一个道理。至于KFS那套并行同步和链式校验如果你面对的是TB级、不能停机的大项目我只能说早点用少熬夜。我这几年头发是真的少了不少一部分得怪早年那些没有工具硬扛的项目。行了不废话了祝各位迁移顺利割接零故障。