★ FEATURED ARTICLE 前言干数据这行的多少都被同步两个字坑过。最常见的场景大概是这样财务系统在Oracle里订单在MySQL里新业务上了金仓数据库报表组还天天催着要数。怎么办写脚本呗。定时导出、传文件、清洗、导入一条链路一套脚本。头两年还能维护等链路堆到十几条已经没人说得清哪套脚本还活着、哪套早该进回收站了。跑批的苦就更别提。所谓的同步其实是ETL批处理凌晨业务一闲就开跑天亮能跑完就算顺利。业务同事看到的永远是昨天的数。哪天夜里任务再挂一次早上八点还没修利索那个场面懂的都懂。压力最大的还得是迁移。老库换新库存量几个TB领导批的停机窗口就一个周末。导出导入的速度明摆着不够用中途再出个岔子回滚还是硬着头皮上没人敢拍板。这三件事表面不一样病根是同一个靠搬数据文件过日子。换个思路文件不搬了改搬数据库的变更日志一大半问题就顺了。金仓数据库厂商电科金仓在这条路上有个专业产品叫金仓异构数据同步软件Kingbase FlySync圈子里一般喊它KFS。这篇就把它拆开聊聊原理、能耐还有落地时那些坑都过一遍。KFS是个啥一句话在不同数据平台之间干实时增量同步的软件。定位对标国外那款老牌同步工具名字就不点了做这行的都认识。跑起来的环境里有三个角色。KFS源端装在数据流出的那头专职从数据库日志里抓变更。KFS目标端装在数据流入那头把变更一条条写进目标库。中间还有个KFSMCWeb版管理台部署、监控、告警都在上面弄一套KFSMC能同时带着多个源端和目标端。顺带提醒个容易踩的点KFS按物理实例算套数。A库B库往C库汇数据就是两个源端一个目标端三套。动手前先把这笔账算了后面申请和部署都不抓瞎。再交代下背景免得有人觉得这东西没经过考验。KFS交付了5000多套客户500多家金融、电网、医疗、汽车行业的一批重量级单位都在用属于被大项目反复锤过的不是实验室玩具。原理这块其实不玄乎KFS走的是增量日志解析这条路整条链路就三步。第一步采集。源端直接读数据库的事务日志Oracle那边叫Redo金仓数据库这边叫WAL把里面的增删改实时解析出来。这里有个关键细节它只认已经提交的事务回滚的没提交的一律不碰脏数据进不来资源也省。另外它是读日志不是跑SQL去查数据跟触发器方案、全表扫描方案完全两码事生产库基本感觉不到它的存在。第二步落KUFL。KUFL全称Kingbase Unified Format Log一份加密格式的中间文件。多这层图什么各家数据库的日志格式差太远中间兜个统一格式异构的坎就平了。更重要的是数据先落盘再传网络断了、目标端趴了数据都稳稳躺在本地恢复之后从断点接着走。断点续传数据不丢这话不是吹的。第三步加载。目标端从KUFL读变更翻译成目标库自己的SQL去执行回放严格照源端事务的提交顺序来配上事务先后顺序检查、I/O顺序检查、日志全流程连续性检查三道关卡。能走JDBC的库都能当目标端它数据源覆盖广根子就在这。链路整体长这样源库日志→采集解析→KUFL文件→网络→目标端回放。两头解耦中间断了能续。光讲原理挺干来点具体的。你在源端随手敲这么几行-- 建张新表DDL也能同步CREATETABLEcrm_customer(id NUMBERPRIMARYKEY,name VARCHAR2(64),levelNUMBERDEFAULT1);-- 日常增改实时流向目标端INSERTINTOcrm_customer(id,name)VALUES(1001,张三);UPDATEcrm_customerSETlevel3WHEREid1001;-- 中途加个字段目标端跟着改ALTERTABLEcrm_customerADD(phone VARCHAR2(20));建表、两条数据变更、加字段几秒之内目标端按顺序全重演一遍。DML和DDL都跟得上这是日志解析方案特别省心的地方。能连哪些库先看家底选型第一件事永远是核对数据源清单别的往后稍稍。KFS现在支持30多种按类别归一下类别源端数据流出目标端数据流入国外主流数据库Oracle、SQL Server、MySQL/MariaDB、DB2、InformixOracle、SQL Server、MySQL/MariaDB、DB2国产数据库金仓数据库KingbaseES、达梦、OceanBase、PolarDB、openGauss、Vastbase、Gbase8s、TDSQL、AntDB等和源端基本一致另支持Greenplum、Gbase8a这些分析型库消息队列Kafka、RabbitMQ、RocketMQKafka、RabbitMQ、RocketMQ、华为ROMA大数据/分析平台—Hive、Hadoop、华为DWS、MRS数据湖、ClickHouse、ElasticSearch、MongoDB、星环ArgoDB其他常见RDS云数据库SQL文件、ETL工具、StreamSets、FlinkCDC信创环境也全鲲鹏、海光、飞腾、龙芯、申威到X86都有操作系统麒麟、统信、欧拉、Windows、Linux、AIX都行。拓扑随意搭一对一、一对多、多对一、级联、双向都支持。没想到的是连网络隔离装置、单向光闸、防火墙这种环境都能穿这本事后面讲案例你会看到多值钱。数据类型没什么好操心的字符数值日期不用提大对象、无主键表、GIS空间数据都支持序列、存储过程、视图、同义词、索引也都在覆盖范围里。同步范围还能裁。不是所有表都值得搬可以细到只同步某几个模式、某几张表、甚至某几个字段正则一筛就行^crm_.*$ 只同步crm_开头的表 ^(t_|log_).* 临时表日志表这类用排除规则跳过 sales\.\d{4}_.* sales模式下按年分表的那些表表一多就懂这功能多香了几百张表的库能砍掉一大半无用传输。跟老ETL比一比直接上表对比项传统ETL批处理KFS实时同步数据时效小时到天级业务永远看T1亚秒级实测延时40毫秒一致性没有事务保证窗口期容易错漏按事务提交顺序回放端到端一致对生产库的影响全表扫描拉数CPU和I/O一顿猛冲只读日志某医院现场内存占用不到2GB带宽占用全量来回搬增量传输4倍以上压缩2M带宽就能跑容灾数据校验人工对账内置比对加自动修复不停机就能做性能单独说两句。官方基准环境是X86、6核16G、SSD、千兆网这套配置下Oracle源端解析118MB/s目标端加载240MB/s往上TPCC模型一天同步600GB还多国外同类是460GB差了三成。就算缩到1核2G的丐版配置一天跑50GB也没问题。数字未必跟你家业务严丝合缝量级摆在这绝大多数场景够用。实战TB级迁移怎么做到不停机这是KFS的看家本领。动手前先把源库收拾利索。以Oracle为例日志解析类工具有个绕不开的前提归档和附加日志必须开SELECTlog_modeFROMv$database;-- 期望ARCHIVELOG没开的话后面免谈ALTERDATABASEADDSUPPLEMENTAL LOGDATA;ALTERSYSTEM SWITCH LOGFILE;然后是迁移的编排电科金仓固化成四步工具分工很清楚第1步 KDMS 结构迁移 └ 表结构、索引、约束这些对象定义先过去 第2步 KDTS 全量迁移SCN/LSN快照 └ 存量慢慢搬业务照常跑 第3步 KFS 增量缓存和第2步同时启动 └ 快照位点之后的Redo日志增量先落在KFS本地 第4步 KFS 增量回放 └ 全量完成后加载增量两端位点追平 └ 追平后暂停应用JDBC改指新库重启收工SCN和LSN可以理解成日志流上的进度条刻度。这套流程的精髓在第2步第3步并行全量爱跑多久跑多久期间冒出来的新增量全被KFS截在本地最后只追平一小段。停机窗口就从整个导出导入的时长缩成了追平最后那段的时长一般就是分钟级。讲个真实项目。某直辖市一卡通1.8亿用户存量12.3TB早高峰三小时涌进5900万笔交易业务一秒不能停。最后12.3TB三天搬完切换后每天500GB增量秒级同步数据比对全程没停业务。还有一个超大型三甲医院的项目更重8个院区加一个远郊医疗区400多个系统60TB起步的存量做法是每个院区放KFS前置机就地采集再统一汇聚进数仓采集加转换的延时压在10秒以内。对了迁移还有个稳妥玩法叫双轨并行不少人不知道。割接完先别急着让老库退休让KFS把新库数据反向同步回去两套并轨跑一阵子。新系统真不给力随时切回去数据一条不丢。等新库被验证得服服帖帖老库再光荣退休。后悔药说得就是它。踩坑实录没主键的表能把人逼疯先泼盆冷水日志同步不是万能的它天生依赖主键或者唯一键来定位行。源端一条UPDATE日志里记的是整行镜像到目标端得还原成UPDATE … WHERE id xxx。没主键的话WHERE条件只能拿一堆列硬拼拼不全数据一重复同步当场乱套。某金融项目把这坑暴露得明明白白5000多张表里1200多张没主键入库效率被拖得没法看。现场的解法挺接地气分类拆开含大对象的无主键表或者日更删超过10万条的 → 筛出55张走T1定时同步每天早上5:30跑 其余1100多张 → 照旧走实时链路 效果实时链路延迟长期压在1秒以内 那55张表每天约70G变化量5分钟跑完速率约240MB/s我的体会是工具给的是通解落不落地看你裁不裁。上线前把无主键表和大对象表盘一遍比上线之后救火舒服太多。两边数据到底一不一样同步跑通只是及格线业务真正盯的是这个。同步过程里先有三道检查兜着事务顺序、I/O顺序、日志连续性问题尽量拦在半路不流到末端。事后有内置的比对模块四种方式全量详细比对、筛选过滤、抽样、MD5摘要就是给每行数据算个指纹指纹一样内容就一样多线程并行大数据量也扛得住。任务能立即跑、定时跑、按周期跑差异明细在KFSMC界面直接看省得自己写对账脚本。发现不一致了怎么修人工挑表做记录级修正可以全自动修也行全程不停业务。环境装不了图形界面的话还有命令行版的校验修复工具兜底。真出岔子邮件、短信、钉钉告警第一时间就到。平时想自己粗核对一下也简单两端各数一遍对总量SELECTordersAStable_name,COUNT(*)AScnt,MAX(update_time)ASlatest_changeFROMordersWHEREupdate_timeTRUNC(SYSDATE);-- 金仓数据库侧换CURRENT_DATE一个意思记录数对上不代表内容全一致但对不上就肯定有事。平时拿这招扫一遍最省事要精细化核对再上比对模块。链路自己别先趴窝同步链路一旦扛上容灾的担子自己就不能是单点不然等于拿漏了气的救生圈救人。KFS这边是KFS-HA多实例热备备实例平时待命主的挂了自动顶上全程不用人碰。部署有几个讲究。一个KFS-HA实例可以一对一盯一个同步实例这叫合并部署也可以看护一整条链路的源端加目标端叫分离部署。两节点的玩法要额外给个能ping通的IP当虚拟IP而且半数以上节点状态得正常机制上等于自带了个小仲裁。上生产前建议先把图画出来别嫌麻烦。真实案例不缺。某国家级金融基础设施机构的业务平台用KFS架了条跨1000公里的双活链路两个中心实时互备。某省级公共资源交易平台也有意思省中心对16个地市做一对多分发中间是2M低带宽、高时延、还丢包的广域网靠着传输压缩优化2M照样把活干了。上线前花五分钟做个连同性自查能少翻一半的车forhostin10.0.0.1110.0.0.1210.0.0.13;doping-c3$host/dev/nullecho$host通||echo$host不通先查网络donedf-h/data# KUFL落盘目录建议单独挂盘空间留足日常运维的主战场在KFSMC。数据量、延迟、速率这些指标按链路、按节点两个维度都能看还能下钻到表级操作分析和性能耗时哪张表拖后腿一眼就能瞅出来。另外KFS把RESTful、Thrift、JMX、Shell接口全开放了银行、政务这种已经有统一监控大盘的直接接进去就行不用额外开发适配层这点是真加分。碎碎念开头那三件事数据孤岛、凌晨跑批、迁移窗口不够用答案其实是同一个把搬数据变成持续重放日志。什么团队值得认真看看它我觉得三类。要做国产化替换又不敢一步到位的双轨并行就是给这场景生的。ETL时效拖累业务、天天被T1数据恶心着的。还有手里库种杂、要跨隔离网络做分发汇聚的政务、金融、医疗、能源这几个行业尤其对症。工具终究是工具。上线前把表结构盘清楚没主键的表重点照顾实例数量提前算明白比对校验放进日常巡检别等出了事才想起来。这三件事做稳了数据同步就能从天天救火变成没人想起。一条链路能让人想不起来这活儿基本就算干成了。
阅读完成 · 觉得有帮助？
