大型数据库日志级复制平台：从容灾到异构同步的实践解析

干了这么多年数据架构和运维我越来越觉得“数据库容灾”是很多团队认知偏差最大的一个领域。不少人把“每天做一次全量备份、每小时传一次归档日志”当成高枕无忧的容灾方案可真到机房故障演练或者被业务方要求把RTO压进分钟级的时候才发现备份恢复的粒度根本扛不住。也就是在这种背景下我开始认真研究日志级的数据库复制平台DSG SuperSync就是当时进入视野的一款国产产品。这篇文章不打算写成一板一眼的厂商通稿而是想从一个使用者和技术评估者的角度把“大型数据库高性能复制平台”这个主题拆开聊透它到底解决了什么问题内部的复制链路是怎么跑的高性能和一致性怎么平衡部署落地有哪些坑以及和原生日志复制、ETL工具相比它的边界在哪里。1. 先弄清一个问题为什么大型数据库需要专门的复制平台1.1 备份、容灾、复制其实是三件完全不同的事我遇到不少刚接触这块的同行会把“复制平台”和“备份系统”混为一谈。这里必须先把概念理清楚。备份系统解决的是“数据坏了能找回”的问题它把数据从生产环境拷贝到廉价的存储介质上恢复时需要一个相对完整的恢复流程。而复制平台解决的是“数据在另一个地方实时或者准实时可用”的问题它在源端和目标端之间维护一条持续流动的数据通道目标端永远有一份接近实时的数据副本。这套逻辑放到大型数据库场景里差别会非常明显。以典型的Oracle核心交易库为例单日归档日志量动辄几十GB到几百GB加上十几张上亿行的核心大表备份系统做一次全量恢复光数据文件拷贝加日志应用往往就是小时级。如果业务方提出的要求是“机房级故障后15分钟内对外恢复服务”那纯备份方案基本做不到。SuperSync这类复制平台的作用就是让目标端数据库始终处于“只差几秒钟”的状态切换时只需要做最后的日志补齐和角色转换。从技术形态上看复制平台通常采用日志解析的方式工作。它不直接读写业务表而是从数据库的在线日志或归档日志中解析出完整的事务操作再通过网络传输到目标端执行。这样做的好处是第一对源库的性能影响小不需要在业务表上加触发器或者额外的时间戳字段第二实时性高日志一旦生成就能被捕获第三逻辑层复制可以做异构转换和部分表选择。注意我看过不少项目把“备份系统带个日志恢复功能”直接包装成“容灾复制”实际上恢复链路和复制链路完全是两种架构。选型时一定要问清楚产品到底走的是日志解析还是靠备份集增量回放。1.2 大型数据库场景下复制的三个典型诉求结合我参与过的几个项目大型数据库引入复制平台诉求基本可以归为三类。第一类是容灾切换。这是最常见的诉求。同城主中心加同城备中心或者两地三中心架构备中心需要有一份随时可用的数据副本并且支持定期做切换演练。这里的关键指标就是RPO和RTO。RPO要求做到秒级甚至零丢失意味着复制的实时性必须足够高RTO要求做到分钟级意味着切换流程不能依赖人工执行大量手工脚本复制平台最好能提供完整的切换辅助能力。第二类是读写分离和报表分流。核心生产库的CPU常年被分析型查询拖累一个复杂报表跑十几分钟把生产连接池占掉一大半。通过复制平台把数据准实时同步到分析库或者只读库业务就能把读流量引导过去。这个场景对复制的结构映射能力有要求因为分析库的表结构经常和生产库不完全一致可能需要增加字段、改表名、过滤某些行或者把多张表合并这些逻辑如果不能在产品层配置就得靠二次开发。第三类是异构数据库的数据汇聚与迁移。比如多个分库分表的MySQL实例要汇总到一个大型集中式数据库做统一查询或者要从Oracle平滑迁移到国产数据库迁移过程中需要保持双写并行一段时间。这类场景里复制平台对异构数据库的支持广度非常关键不是所有产品都能同时兼容十几种数据库端。这里顺便解释一个容易混淆的点同构物理复制和异构逻辑复制的差别。像Oracle Data Guard这样的原生方案走的是物理块复制它要求源库和目标库版本、平台基本一致优点是保真度极高缺点是完全不能跨厂商。而SuperSync这类平台走的是逻辑复制解析出来的是行级变更理论上只要目标端有与之对应的表结构就能写入所以天然支持异构场景。这也是为什么很多“去O”项目里物理复制方案只能做过渡逻辑复制平台才是迁移主力。2. SuperSync复制引擎的完整工作链路日志捕获、传输、应用三步走2.1 日志捕获层解析粒度决定复制能力的天花板复制平台最核心的技术壁垒几乎都藏在日志捕获这一层。下面谈工作机制我基于数据库复制产品的常见实现原理来拆解具体细节请以SuperSync各版本文档为准。无论是Oracle的redo log和archive log、MySQL的binlog还是国产数据库的WAL日志日志里记录的都是最底层的数据变更。捕获层要做的事情是从这些日志中识别出每一个事务、每一条DML操作然后组装成一种平台自己定义的内部格式。这个过程中有几个细节直接决定了平台的能力上限。事务边界识别是第一个关键点。日志里一个事务可能跨越多个日志文件也可能包含成千上万条操作。复制平台必须完整地把同一个事务的所有变更聚拢在一起保证后续应用时事务原子性不丢失。如果捕获层把事务拆散传输目标端就可能在应用一半时发生中断导致数据不一致。我接触过的几个复制产品在事务组装上的实现差异很大有的能支持几千条SQL的大事务有的超过一定规模就直接报错跳过这在生产环境是不可接受的。DDL解析是第二个关键点。很多复制工具只支持DML遇到ALTER TABLE增加字段、修改列类型就直接挂起需要人工干预。但真实生产环境里业务系统每个月都有版本迭代数据库表结构经常变动。SuperSync这类相对成熟的产品通常会通过支持解析常见DDL并同步执行到目标库或者在GUI里提供结构变更同步的手动确认入口确保表结构变更不会成为复制链路长期中断的理由。第三是字符集和数据类型映射。源端是ZHS16GBK目标端是UTF8或者源端是Oracle的NUMBER(38)目标端是国产库的DECIMAL(38,5)这种结构差异如果不在捕获层解决到了目标端应用时就会频繁报错。成熟的平台会在捕获阶段就完成类型标准化内部统一用一种跨数据库的中间类型体系到目标端再转换成对应数据库的类型。这个设计让平台在做异构复制时不需要为目标库定制一套解析器。2.2 传输层带宽优化和断点续传是稳定性的分水岭日志解析出来之后变更数据进入传输通道。这里最容易出现问题的就是网络带宽和断点恢复。对于大型数据库源端日志产生的速度可能高达每秒几MB高峰期甚至几十MB。如果不做任何压缩跨机房专线很容易被打满。常见做法是在捕获端做数据压缩日志类数据由于重复度高压缩比通常能达到2:1到5:1所以一个源库日志产生速率20MB/s的实例实际占用的网络带宽大约只有4MB/s到10MB/s。我在估算网络专线带宽时一般会按这个公式来留余量峰值日志速率除以压缩比再乘以1.5倍的突发余量。比如峰值40MB/s压缩比按4:1算业务带宽需求是10MB/s那专线至少预留15MB/s以上。传输层另一个容易被忽略的特性是断点续传。生产环境里网络闪断是家常便饭复制平台如果做不到断点续传链路的可用性会非常差。断点续传的实现机制本质上是源端捕获模块把解析到的日志位点信息持久化下来比如Oracle的日志序列号加文件偏移量MySQL的binlog文件名加position。网络恢复后从断点位点继续读取而不是重新全量扫描。这里有一个非常关键的质量指标位点持久化的频率。如果捕获模块每隔5秒才记录一次位点那一次宕机可能导致丢失最多5秒的数据。生产级平台一般会把位点持久化做成事务级的也就是一个事务处理完成后立刻更新位点保证源端崩溃时最多丢失正在传输中的那一个事务。2.3 应用层并行度、事务拆分和幂等性设计数据到达目标端之后应用层负责把变更写入目标数据库。这部分的性能优化空间最大也最容易出问题。最基础的问题是写入并发度。如果复制平台老老实实按照源端的串行事务顺序一个一个回放到目标端性能完全跟不上。常见的做法是将互不冲突的行级变更分到不同的并发线程去执行以行或者主键作为分片维度保证同一个主键的变更在同一个线程内有序执行避免并发更新同一行造成锁等待。比如一张订单表订单号尾号取模分成8个分片分到8个线程并行应用写入吞吐量能提升好几倍。但并行带来的新问题是事务一致性。源端一个事务里更新了10张表1000行数据目标端如果把这1000行拆到不同线程并发执行那这个事务在目标端就不再是原子的某个时刻可能只应用了一半。所以平台通常采用“事务级一致性”策略小事务整体串行应用以保证原子性大事务内部拆分成批并行应用但通过标记机制控制对外可见性直到整个事务全部应用完成。应用层的第三个设计要点是幂等性。复制链路发生重复传输时目标端可能收到同一条更新的多个副本。如果应用层不具备幂等能力一个UPDATE语句被重复执行两次问题不大但一条INSERT被重复执行就会产生主键冲突。成熟平台会在应用模块里做基于主键或唯一键的冲突检测或者通过事务位点去重保证重复消息被安全丢弃。这一点在做双向复制时尤其重要后面第六章我会具体说。3. 高性能与数据一致性不是二选一延迟、断点、校验的设计逻辑3.1 复制延迟到底怎么衡量多少算正常在运维复制平台时经常被业务方追问的一个问题是“现在延迟几秒钟”但“延迟”这个词在不同语境下含义完全不同。复制平台通常提供两个层的延迟指标捕获延迟和回放延迟。捕获延迟衡量的是日志产生到被捕获模块解析出来的时间差正常情况下应该是毫秒级因为日志只要落盘就能被扫描到。回放延迟衡量的是捕获到的数据到写入目标端的时间差这个才是真正影响RPO的指标。回放延迟在不同负载下波动很大平时可能只有一两秒遇到大事务批量更新延迟跳到几分钟也是正常的。这里有一个很常见的误区很多运维人员一看回放延迟超过30秒就认为复制平台出了问题。实际上如果源库正在跑一个批量数据修正任务一个事务里更新了几百万行复制平台为了保证事务原子性必须等所有变更都应用完才能对外确认提交这期间延迟必然上涨。这类“大事务毛刺”是可以接受的只要事务完成后延迟迅速回落说明平台的处理能力没有问题。真正需要警惕的是慢SQL堆积延迟持续上涨、队列越来越长那才是需要排查的故障信号。3.2 断点和故障恢复RPO能不能做到真正的秒级关于RPO有一个残酷的事实理论上任何复制平台都无法保证绝对的“零丢失”。原因在于源端数据库和复制捕获模块之间必然存在一个感知窗口。比如源库Orace的redo日志写入后复制模块每隔100毫秒扫描一次那理论上最多丢失100毫秒的日志。这也是为什么主备容灾架构里主中心故障时的RPO通常都是“秒级或亚秒级”而不是0。实际的RPO水平取决于三件事捕获模块扫描日志的频率、位点持久化的粒度、以及传输通道的确认机制。如果平台做到事务提交即捕获、位点随事务持久化、目标端应用完成后才回传确认那故障时的实际丢失量会被压到非常小。在做容灾方案设计时我会建议客户不要把RPO目标设成“0”而是设成“一个可控的秒级窗口”比如5秒以内。这样既能用合理的成本买到足够好的复制平台又不会因为追求极端指标而大幅增加系统复杂度。3.3 数据校验没有对账的复制链路是不可信的复制平台算不算“稳”不能只看监控面板上的延迟数字还要看目标端数据是否真的和源端一致。很多数据不一致问题是“静默”发生的字符集转换出错、类型精度丢失、主键冲突被跳过这些都不会让链路停止但会让目标端数据悄悄变坏。因此一个有校验能力的复制平台会让运维省心很多。SuperSync这类的平台通常提供两种校验模式。一种是在线校验按照主键分片对源端和目标端的数据做哈希比对只传输摘要值不传输全量数据减少网络开销。另一种是定期全量校验通常放在业务低峰期执行适合做月度或者季度的深度对账。运维实践中我一般建议复制链路刚建立时做一次全量校验之后每周做一轮在线抽样校验每月做一次核心表全量校验这样能在问题出现的早期就把它抓出来。4. 从拓扑规划到切换演练一套可落地的部署运维方案4.1 复制拓扑怎么选单向、双向、级联还是多活部署SuperSync之前先得想清楚复制拓扑。这步没做对后面所有配置都是在打补丁。单向复制是最简单的拓扑数据从A流向B适用于容灾备库、报表分库这种场景。它的优点是链路清晰、故障定位容易缺点是备库只读无法承担双活流量。双向复制则允许两个节点互相复制适用于应用双活部署比如两个城市的数据中心各自接管一部分业务流量。这里有个必须提前解决的问题双向同步时一条数据在A库被修改复制到B库B库的应用如果也修改了同一行再复制回A库就可能发生更新覆盖。平台需要在业务层面约定好分片规则比如按机构编码区分A中心机构的客户数据只在A库可写B中心机构的只在B库可写从机制上避免写冲突。级联复制适合跨地域的复杂网络。比如总部在北京上海和广州各有一个区域中心要求数据最终汇聚到北京总库。如果上海和广州各自建一条到北京的链路专线带宽成本高还可能因为网络延迟导致两端无法保持一致。改成上海复制到广州、广州统一复制到北京的级联结构虽然数据到达北京的时延变长了但整体链路更集中、更可控。多活拓扑是双向复制的进阶形态通常用于同城双中心甚至三中心的强一致场景。坦率地说多活对复制平台的冲突检测能力、事务处理能力要求极高也依赖底层数据库本身的能力。如果数据库不支持分布式事务纯粹靠复制平台做多活应用层的改动量会非常大。所以我的建议是没有特别强的业务诉求不要轻易上多活双活加快速切换对绝大多数企业来说已经是性价比最好的方案。4.2 部署前必做的源端评估和参数调整清单真正落地一套SuperSync复制链路我习惯按照下面这个顺序来做源端评估每一步都有具体的检查项。第一步是数据库版本和日志模式检查。复制依赖日志解析所以源库必须开启了完整的日志记录。如果用的是Oracle要确认数据库处于归档模式并且force logging开启否则某些NOLOGGING操作不会写入日志复制链路根本感知不到这些变更。MySQL则要确认binlog_format是ROW模式且binlog_row_image设置为FULL只记录镜像变更会让复制数据不完整。第二步是网络带宽和时延测量。在开工之前用tcping或者iperf3在源端和目标端之间做一组基准测试记录丢包率、时延、实际可用带宽。特别要注意的是很多企业的跨机房专线带宽是共享的高峰时段可能达不到标称值预留余量非常必要。第三步是账号和权限最小化评估。复制平台需要一个专用账号来读取日志这个账号的权限虽然不需要DBA但至少要能访问日志相关视图和表。安全部门通常会问这个账号会不会有业务表的读写权限会不会影响审计我们一般会给复制账号单独建一个profile限制登录来源IP只授权日志读取和会话创建相关权限从源头上控制风险。第四步是表结构和数据特征采集。对要复制的表统计每张表的行数、平均行长、主键类型、是否有无主键表、字符集是否一致。这些信息直接决定了目标端的表结构设计以及复制分片策略怎么定。特别是无主键表在目标端做数据应用时性能会非常差最好提前和开发团队沟通看能不能在目标端补一个唯一键。4.3 监控指标体系和切换演练的完整流程部署完成之后的日常运维最关键的是建立一套能真实反映复制健康度的监控指标。我常用的指标基本围绕四个层面。链路连通性层面看捕获进程、传输进程、应用进程三个组件是否在线任何一级挂掉都需要立刻告警。实时性层面关注捕获延迟和回放延迟建议设置两档告警延迟超过30秒告警到运维值班超过5分钟升级到DBA团队。数据量层面看每秒捕获的日志量、传输压缩比、目标端写入吞吐量这些指标帮助判断链路当前处于什么水位。异常层面重点监控错误队列长度和跳过事务数量一旦有数据被跳过必须立刻排查跳过事务往往是数据不一致的前兆。切换演练这件事我想多说两句。很多团队建好复制链路之后从来不演练真到灾难发生时才手忙脚乱。切换演练不只是按一下“切换”按钮它至少应该包括停止源端写入、等待复制延迟归零、执行最后的日志补齐、完成角色切换、启动目标端对外服务、验证核心交易链路、然后执行回切。整个过程建议做成标准操作流程文档并且每季度至少演练一次每次演练之后复盘耗时和问题。只有把演练当成常规运维动作真到故障那一刻才可能做到不慌乱。5. 选型视角SuperSync和原生复制、ETL、自研同步的分工边界5.1 与数据库原生日志复制方案的对比在选型时首先会被拿出来对比的一定是数据库原生的高可用方案。以Oracle为例Data Guard是绝大多数Oracle容灾方案的默认选择它走的是物理块复制在数据一致性、故障切换的成熟度上确实有巨大优势。但Data Guard的边界也很清晰一是只支持Oracle到Oracle对异构数据库毫无办法二是在主备角色切换后备库需要应用介质恢复整个切换过程对网络质量和日志应用速度要求很高三是Data Guard的数据不能做结构转换备库表结构必须和主库完全一致。SuperSync这类的逻辑复制平台和Data Guard不是替代关系更多是互补。同构的Oracle核心库容灾用Data Guard做第一层保障跨厂商的数据同步、异构迁移、读写分离则交给逻辑复制平台。我见过的最优实践是生产库到同构灾备库走物理复制同时灾备库再向其他大数据平台推送数据走逻辑复制两层各司其职。5.2 与ETL工具和自研同步任务的分工另外一类经常被拿来对比的是ETL工具。传统ETL工具解决的是“大数据量的批量抽取转换加载”典型场景是每天凌晨跑一个批处理把前一天的数据从业务库抽到数仓时间窗口是小时级甚至天级。而复制平台解决的是“实时的、事务级的、持续不断的变更同步”时间粒度是秒级。两者的应用场景有明显边界。如果你要做的是T1的数据分析ETL完全够用但如果你要的是一个随时可切换的容灾库或者一套实时数仓那就必须上复制平台。我还见过不少团队选择自研同步任务。业务系统在代码里双写或者定期按时间戳抽取增量数据。这种方案在小数据量、单一数据库的场景下可以跑得通但一旦数据量上来自研方案会面临几个躲不过的问题一是无法捕获物理删除操作业务里一旦有DELETE目标端就对不上二是不支持事务一致性一个事务里更新多张表自研按表抽取就会读到中间状态三是没有统一的监控和断点续传机制链路一旦中断补数据全靠手工。复制平台本质上就是在为这些问题买单。5.3 什么场景下SuperSync这类平台是唯一解结合实践经验下面几类场景里SuperSync这类专业复制平台几乎可以说是唯一解。第一类是国产化数据库迁移。从Oracle迁移到达梦、人大金仓、OceanBase等数据库时要求迁移过程中源端业务不能停要有一套稳定的增量同步能力同时还要对目标库做一定的结构适配。这类场景只有日志级复制平台能做。第二类是核心数据库的容灾切换要求RPO在秒级、RTO在分钟级且灾备机房和主中心不是同一套数据库软件。物理复制方案基本出局逻辑复制平台是仅有的成熟选项。第三类是多个业务系统的数据需要实时汇聚到统一平台而且源端MySQL、Oracle、SQL Server等多个数据库并存。复制平台对多源异构的支持越好这种项目就越省力。有些项目甚至需要把多个源端的数据按一定规则合并到一张目标表这种复杂映射关系只有产品级的复制平台才能配置出来。6. 实施中容易翻车的细节我在复制平台上踩过的真实坑6.1 大事务导致的延迟毛刺别被监控吓到第一次看到复制监控面板上回放延迟突然跳到6分钟我当时的第一反应是链路挂了。查下来发现源库正在跑一个月度表分区清理任务单事务更新了上亿行数据。复制平台为了保证事务原子性在目标端一个事务回放完之前不会上报这部分数据完成所以延迟显示会持续上涨。这个事务执行了大概10分钟延迟最高到了8分钟之后链路迅速恢复正常。这个案例给我两个教训。第一大事务执行前最好先通知DBA和相关运维避免看到延迟飙升造成误判。第二复制平台的告警阈值不能简单设一个固定值最好加上“持续超过X分钟”这样的条件过滤掉大事务带来的瞬时毛刺。6.2 无主键表的复制性能灾难还有一个让我印象极深的坑源库一张流水表没有主键只有唯一索引但唯一索引里包含两个允许为NULL的字段。复制到目标端后由于NULL在目标端的比较逻辑和源端不完全一致导致复制的UPDATE操作在目标端无法准确定位到具体行应用进程性能急剧下降目标端数据库的回滚段几乎被撑爆。排查过程花了大半天最终发现根因在表结构设计上。解决方法是和目标端开发团队确认后在目标端加了一个自增主键列复制的定位逻辑不再依赖原来那些可空的唯一键字段问题才彻底消失。这之后我养成了一个习惯任何表接入复制链路之前先检查源端是否有明确主键没有主键的表第一时间预警不能等到链路跑起来才发现。6.3 字符集和时区差异一个字符集问题导致的静默数据错误字符集和时区导致的数据不一致是最隐蔽的坑。源端Oracle是ZHS16GBK目标端是异构数据库用的UTF8MB4。大多数场景下中文能正常转换但遇到生僻字GBK里没有对应的Unicode映射转换后就成了空字符串或者乱码。更隐蔽的是时间字段源端存的是带时区的时间戳目标端配置的时区不对导致所有时间字段整体偏了8小时。这类问题在复制平台监控面板上完全看不出来只有业务方做对账时才会发现。我的处理思路是建链前做一轮小的样本数据验证专门挑几条包含生僻汉字、特殊字符、夏令时边界时间的数据做测试插入确认两端完全一致后再放开全量复制。同时校验功能也要特意覆盖字符类型和时间类型的字段不能只比对数值型字段。6.4 DDL变更导致的复制链路中断有一次业务上线新功能在源库给一张大表加了两个字段。平台检测到DDL后默认行为是暂停这条链路的写入等待人工确认目标端是否也做了相应变更。结果因为值班同事没注意到告警链路停了将近两个小时直到业务反馈报表数据延迟才被捞出来。后来我们规范了DDL变更的协作流程所有涉及复制链路表的DDL必须先通过变更平台提交工单DBA评估后同步在目标端执行然后由复制平台管理端手动放行DDL变更。这个过程虽然多了一个审批环节但避免了无数次链路静默中断。6.5 双向复制中的更新覆盖冲突双向复制上线初期我们遇到过最经典的主键冲突问题。源端A和源端B各自允许修改同一张客户表的某些行两个应用各自提交更新后复制平台把两条更新都同步到对端最后一次写入的版本覆盖了先前的版本。表面上看两端数据最终变成一模一样的了但实际上其中一端本次的更新被悄悄丢掉了。排查下来的结论是双向复制必须基于业务层面的分片规则来设计不能放任两端对同一行数据同时修改。如果业务确实需要多中心都写同一份数据那就需要引入基于版本号或时间戳的冲突检测机制但这要求应用层配合修改。关于这个机制我建议在选型时就把“冲突检测能力”放到需求清单里重点验证因为一旦双向复制上线后再改造成本会非常高。最后再分享一个我在实际项目中验证过的小技巧新复制链路部署完成后不要马上把它当作正式链路先做至少一个业务周期的影子运行。所谓影子运行就是让复制链路持续工作但业务方仍然以手工核对或者备份校验的方式验证目标端数据只有连续两个账期对账无差异后才正式切换流量。这个过程中积累下来的延迟基线数据、告警阈值调优经验、以及切换流程的一点点修正都会在未来真正需要切换的时候变成你的底气。希望这篇内容能让你对大型数据库复制平台多一分清晰、少一些踩坑。