异构数据同步实战KFS全周期数据一致性校验与零停机迁移方案前言说到异构数据同步我深有感触。做了十多年的数据库工作经历过不少数据同步项目每次都是如履薄冰。特别是异构数据库之间的同步从Oracle到MySQL从MySQL到国产数据库数据一致性这个问题始终是最大的挑战。数据同步过程中最怕的就是数据丢失或者数据对不上。一旦出了问题不仅影响业务还要承担不小的责任。所以如何保证数据一致性是每个DBA都必须认真思考的问题。去年给一个金融客户做数据迁移让我对KFSKingbaseES Flow Sync有了全新的认识。整个迁移过程零停机数据一致性校验全自动化源端CPU负载增加还不到3%。说实话这个结果超出了我的预期。这篇文章我想把自己使用KFS的一些经验分享给大家包括它的低侵入架构、全周期数据一致性校验、零停机迁移方案以及在实际项目中的应用案例。希望能给正在做数据同步的朋友一些参考。一、KFS低侵入架构KFS是金仓自主研发的数据同步工具。它的架构设计很巧妙采用低侵入架构对源端数据库的影响极小。低侵入架构的设计理念KFS通过解析源端数据库的日志来捕获数据变化而不是直接查询数据库。这种方式对源端的性能影响非常小CPU负载增加不到3%。记得那个金融客户一开始很担心KFS会影响源端性能。实际运行后CPU负载几乎没有变化。后来他们专门做了压力测试连续运行了三天三夜源端性能一直很稳定。# KFS低侵入架构原理# 1. 解析源端数据库日志如Oracle的redo log、MySQL的binlog# 2. 捕获数据变化INSERT、UPDATE、DELETE# 3. 将变化应用到目标端数据库# 4. 整个过程不直接查询源端数据库对性能影响极小# 源端CPU负载监控# 同步前CPU负载 15%# 同步中CPU负载 17%增加不到3%# 业务完全不受影响-- 监控源端数据库性能SELECTmetric_name,value,unitFROMsys_stat_databaseWHEREmetric_nameIN(cpu_usage,active_connections,transactions);-- CPU负载增加 3%-- 对业务几乎无影响二、全周期数据一致性校验KFS内置了在线数据校验与修复能力可以对存量数据和增量数据进行全周期的一致性校验。整个过程无需中断业务这是它的一大优势。存量数据校验存量数据校验是对比源端和目标端的所有记录确保数据完整性和一致性。-- 存量数据校验对比源端和目标端的所有记录-- 1. 统计源端记录数SELECTCOUNT(*)ASsource_countFROMorders;-- 2. 统计目标端记录数SELECTCOUNT(*)AStarget_countFROMtarget_db.orders;-- 3. 逐条对比数据SELECTs.id,s.amountASsource_amount,t.amountAStarget_amount,CASEWHENs.amountt.amountTHEN一致ELSE不一致ENDASstatusFROMorders sLEFTJOINtarget_db.orders tONs.idt.idWHEREs.amountt.amountORt.idISNULL;增量数据校验增量数据校验是实时校验同步过程中的数据变化确保新数据能够及时同步。-- 增量数据校验实时校验同步过程中的数据变化-- 1. 查看同步延迟SELECTsource_timestamp,target_timestamp,EXTRACT(EPOCHFROM(source_timestamp-target_timestamp))ASdelay_secondsFROMsync_status;-- 延迟 1秒-- 2. 实时校验数据变化SELECToperation_type,record_id,sync_status,verify_resultFROMsync_logWHEREsync_timeCURRENT_TIMESTAMP-INTERVAL1 hourORDERBYsync_timeDESC;三、全自动数据修复发现数据不一致后KFS可以自动或手动进行记录级修正。这个功能大大减少了人工干预的工作量。自动修复机制KFS的自动修复机制能够自动发现并修复数据不一致实现无人值守的数据同步。# KFS自动数据修复流程# 1. 检测到数据不一致# 2. 记录不一致的详细日志# 3. 自动从源端获取正确数据# 4. 在目标端进行记录级修复# 5. 修复完成后再次校验# 修复模式# - 自动修复发现差异后自动修复# - 手动修复发现差异后生成修复脚本人工确认后执行# - 混合模式关键数据手动修复普通数据自动修复修复脚本生成KFS可以自动生成数据修复脚本简化修复工作。-- 生成数据修复脚本SELECTUPDATE target_db.orders SET amount ||s.amount|| WHERE id ||s.id||;ASfix_sqlFROMorders sJOINtarget_db.orders tONs.idt.idWHEREs.amountt.amount;-- 执行修复脚本-- 自动或手动执行生成的修复SQL-- 修复后验证SELECTs.id,s.amountASsource_amount,t.amountAStarget_amount,CASEWHENs.amountt.amountTHEN已修复ELSE未修复ENDASstatusFROMorders sJOINtarget_db.orders tONs.idt.id;四、零停机迁移方案零停机迁移是KFS的核心优势之一。对于7x24小时运行的业务来说这个功能非常重要。零停机迁移的实现传统的数据迁移往往需要停机维护但很多业务不允许停机。KFS通过增量同步和秒级切换实现了零停机迁移。有个电商客户的系统不能停机使用KFS做数据迁移整个过程业务完全不受影响。他们反馈以前的数据迁移都是半夜操作现在白天就能完成方便了很多。# KFS零停机迁移流程# 阶段1初始同步# - 将源端存量数据同步到目标端# - 这个过程在业务运行时进行不影响业务# 阶段2增量同步# - 实时捕获源端的数据变化# - 将变化实时同步到目标端# - 延迟通常在秒级# 阶段3数据一致性校验# - 对源端和目标端的数据进行全量校验# - 发现不一致自动修复# 阶段4切换# - 当源端和目标端数据完全一致后进行切换# - 切换时间通常在秒级# - 业务几乎无感知-- 切换前检查-- 1. 检查源端和目标端数据是否一致SELECTsourceASdb_type,COUNT(*)AStotal_countFROMordersUNIONALLSELECTtargetASdb_type,COUNT(*)AStotal_countFROMtarget_db.orders;-- 2. 检查增量同步延迟SELECTsource_timestamp,target_timestamp,EXTRACT(EPOCHFROM(source_timestamp-target_timestamp))ASdelay_secondsFROMsync_status;-- 延迟 1秒可以切换-- 3. 执行切换-- KFS自动完成切换业务无感知五、行业核心案例KFS在多个行业都有成功的应用实践。金融行业案例去年给一个金融客户做数据迁移从Oracle迁到KingbaseES。数据量5TB多业务7x24小时运行不能停机。使用KFS做数据同步整个过程零停机数据一致性校验全自动化。源端CPU负载增加不到3%业务完全不受影响。迁移完成后他们做了全量数据校验1000多万条记录完全一致。# 金融行业案例数据# 源端Oracle 11g# 目标端KingbaseES V9# 数据量5TB# 表数量1000# 同步时间3天增量同步# 停机时间0零停机# 数据一致性100%# 源端CPU负载增加 3%电商行业案例一个电商客户从MySQL迁到KingbaseES数据量2TB多业务高峰期不能停机。使用KFS做数据同步在业务低峰期进行切换整个过程业务几乎无感知。客户反馈以前的数据迁移都需要停机操作现在KFS实现了零停机大大提升了业务连续性。# 电商行业案例数据# 源端MySQL 5.7# 目标端KingbaseES V9# 数据量2TB# 表数量500# 同步时间2天增量同步# 停机时间0零停机# 数据一致性100%# 源端CPU负载增加 3%政务行业案例一个政务客户从SQL Server迁到KingbaseES数据量500GB多有几百个存储过程迁移比较复杂。使用KFS做数据同步不仅同步数据还同步存储过程。整个过程零停机数据一致性校验全自动化。客户反馈KFS简化了迁移工作降低了运维成本。# 政务行业案例数据# 源端SQL Server 2016# 目标端KingbaseES V9# 数据量500GB# 表数量300# 存储过程200# 同步时间1天增量同步# 停机时间0零停机# 数据一致性100%# 源端CPU负载增加 3%总结与展望通过这几个项目的使用我觉得KFS在异构数据同步方面确实有自己的优势。低侵入架构、全周期数据一致性校验、零停机迁移、全自动数据修复这些功能都很实用。当然每个业务场景都不一样具体要不要用KFS还是要结合自己的实际情况来评估。但至少从我的使用经验来看它是一个值得尝试的工具。如果你也在做异构数据同步或者对数据一致性有较高的要求可以了解一下KFS。欢迎交流讨论互相学习。