做数据同步这件事很多团队一开始的思路都是“写个定时脚本每天凌晨捞一次数据”。但等表数量上来、业务要求分钟级甚至秒级延迟时脚本方案很快就扛不住要么丢增量要么延迟不可控表结构一改还要跟着改代码。今天要讲的 Otter是一套基于 binlog 的分布式数据库准实时同步中间件它解决的核心问题就一句话——把源库的增删改变化低延迟、可管理地搬到目标库并且支持一对多、多对一、双向同步这类复杂拓扑。这篇教程适合正在做数据库迁移、读写分离、灾备、多机房数据汇总的开发和运维同学。不管你是第一次接触 binlog 同步还是已经在用 Canal 自己做消费端只要你希望把同步链路稳定跑在生产环境下面从部署参数、映射配置到问题排查的实操经验都可以直接参考。我会尽量把“为什么这么配”也讲清楚避免你照着配完不知道下一步该往哪调。1. 先搞清楚 Otter 是什么以及它解决什么问题1.1 定时任务和业务双写为什么不够用先说一个我曾经接手过的典型场景核心订单表需要在两个数据库之间保持近乎实时的同步目标是做读写分离。团队之前的做法是业务代码里双写主库写一份再从应用层往另一个库插一份。结果每次大促都要发布新版本事务边界很难控制双写失败还会导致两边数据对不上。后来换成了 Otter 这类基于 binlog 的同步方案业务代码一行都不用改源库的变更被底层组件实时捕获后转发到目标库应用层完全无感知。定时脚本的问题更明显。它本质上是“定期跑一次全量对比或增量拉取”跑批的间隔决定了你能接受的延迟下限通常是分钟级甚至小时级。而且脚本要自己维护增量位点稍微处理不好就会漏数据。Otter 的思路不太一样它像是一个数据库的“日志订阅者”程序不主动去查询表而是监听源库的 binlog 日志流源库每次提交事务产生什么变化它就能拿到什么再做转换和投递。这种方式对源库的性能影响小也天然具备实时性。1.2 和其他同步组件怎么选型很多人会把 Otter 和 Canal、DataX 混在一起但其实它们解决的是不同层面的问题选错工具后续会非常痛苦。方案定位增量同步能力管理界面适用场景Canalbinlog 订阅解析组件强但只提供数据流接口无自带 UI对接消息队列、自研同步应用DataX离线批量同步框架无偏全量搬运简单 Web 配置全量迁移、数仓初始化Otter数据库间准实时同步中间件强基于 Canal 封装完整的 Manager 控制台增量复制、迁移、双向同步、多机房换句话说Canal 是“零件”Otter 是“整机”。Canal 给你的是订阅到的每一条变更记录你需要自己写程序消费、处理幂等、处理位点。Otter 则在 Canal 之上补全了任务管理、映射规则、冲突策略、监控报警这些生产上绕不开的东西开箱即用。如果你需要的目标端是 Kafka、ES 这类非数据库组件用 Canal 会更灵活但如果你就是在两个关系型数据库之间做同步Otter 的完整链路会省掉很多自研成本。1.3 核心组件和一条数据变更的完整路径Otter 的部署架构通常包含四类角色Manager、Node、ZooKeeper以及 Manager 自己的元数据库用 MySQL 存储。你可以在浏览器里登录 Manager 的可视化控制台做配置Node 是真正干活的节点ZooKeeper 负责协调节点状态和实现高可用。一条数据变更从源库到目标库大致会经历这么几步Node 内嵌的 Canal 连接器实时订阅源库 binlog拿到行级的变更事件。变更数据进入 Node 的处理队列进入 Extract 阶段按你配置的映射规则做字段过滤、字段转换。Load 阶段按事务边界把数据回放到目标库执行插入、更新或删除。在写入前Otter 会根据你配置的冲突策略判断这条变更是否要执行比如“源库优先”还是“目标库优先”。如果是双向同步场景还会做回环保护避免 A 同步给 B、B 再同步回 A 造成死循环。理解这条路径很重要因为后面所有排查都逃不开这几个阶段Select 出问题一般就是连不上源库或 binlog 没配好Extract 出问题通常是映射脚本抛异常Load 出问题基本就是目标库写入失败或冲突。2. 环境准备与部署参数实操2.1 部署前必须想清楚的三件事别一上来就下载安装包先花十分钟把下面三件事确认好。第一确认拓扑。你是单向同步、一对多、多对一还是双向同步这决定了你需要规划几个 Channel、几个 Node。第二确认源库和目标库的版本、字符集、账号权限尤其是目标库账号需要具备建表、改表的权限因为 Otter 在做结构同步或自动建表时会用到 DDL。第三评估一下数据量级和峰值 TPS测试环境可以先不管但生产环境最好留出至少一台独立主机跑 Node避免和业务应用争抢资源。我见过最典型的翻车现场是源库开了 binlog 但没开 ROW 格式任务配置得再漂亮也是白搭同步链路一点数据都不走。这类基础项检查一定要放在最前面。2.2 源库 MySQL 的 binlog 参数与账号授权Otter 底层依赖 Canal 订阅 binlog所以源库的 binlog 配置是关键前置条件。在源库的my.cnf里确认以下参数[mysqld] server-id100 log-binmysql-bin binlog_formatROW binlog_row_imageFULL expire_logs_days14binlog_format必须是 ROW才能拿到行级的变更前后镜像binlog_row_image建议设置成 FULL保证更新操作能拿到完整的新旧字段否则后续字段映射容易缺数据。server-id不能和同网络内其他 MySQL 实例冲突否则 binlog dump 会互相竞争。然后创建同步用的数据库账号授权规则如下CREATE USER otter_sync% IDENTIFIED BY 这里换成强密码; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO otter_sync%; FLUSH PRIVILEGES;SELECT权限是给 Canal 读取表结构和元数据用的REPLICATION SLAVE和REPLICATION CLIENT是订阅 binlog 必需的权限。注意不要用业务主账号来跑同步一旦后续回收权限或改密码整条链路都会出问题。2.3 ZooKeeper 集群准备Otter 的 Manager 和 Node 都依赖 ZooKeeper 做协调所以这个组件也要提前准备好。测试环境可以用单机 ZooKeeper生产环境建议至少三个节点组成小集群避免单点。ZooKeeper 的配置默认参数一般不用大动但要注意网络分区和磁盘 IO。Otter 的会话一旦超时Node 会认为自己在集群中失联触发任务重新调度同步会出现短暂中断。所以 ZK 所在服务器的磁盘不要跑满网络不要有频繁抖动。部署完 ZooKeeper 后把地址记下来Manager 和 Node 配置文件里都会用到格式是host1:2181,host2:2181,host3:2181。2.4 Manager 部署初始化元数据库与两个关键配置Manager 是 Otter 的控制大脑它本身需要一个 MySQL 库来存储任务配置、节点信息和运行日志。先建一个独立的数据库再用 Otter 发布包自带的 SQL 脚本完成初始化不要自己手工建表脚本里有初始化数据和权限相关的逻辑。然后编辑otter-manager/conf/otter.properties重点确认这几个配置otter.manager.datasource.url jdbc:mysql://127.0.0.1:3306/otter_manager otter.manager.datasource.username root otter.manager.datasource.password 数据库密码 otter.zookeeper.cluster.default 127.0.0.1:2181 otter.manager.port 10911otter.manager.datasource.url指向你自己创建的元数据库注意 JDBC 连接串里加上时区和字符集参数避免乱码。otter.manager.port是 Manager 与 Node 通信的 Netty 端口默认 10911一般不用改。启动 Manager 后浏览器访问http://部署机器IP:8080默认账号密码是admin/admin首次登录后第一件事就是改密码。别的先不急着操作下一步是把 Node 拉起来再一起注册。2.5 Node 部署nodeId 与机器注册顺序Node 是真正执行同步任务的工作节点部署过程比 Manager 多一个“注册认证”的步骤但很多新手会在这里卡住。先解压 Node 安装包编辑otter-node/conf/otter.propertiesotter.node.id 1 otter.node.port 2088 otter.manager.address 127.0.0.1:10911 otter.zookeeper.cluster.default 127.0.0.1:2181otter.node.id是这台 Node 在 Otter 集群里的唯一标识必须先在脑子里规划好后面在 Manager 的机器管理界面里要填同一个 ID。otter.node.port是 Node 对外提供通信服务的端口默认 2088。otter.manager.address写 Manager 的机器 IP 和 Netty 端口如果有多个 Manager 做高可用可以用逗号分隔多个地址。启动 Node 之后登录 Manager 控制台进入“机器管理”添加节点填写同样的 nodeId 和机器 IP 端口。这时候 Manager 会生成一段认证信息需要把这段认证信息回填到 Node 的配置中重新启动节点状态才会变成正常。这个机制本质上是为了防止没有权限的 Node 混进集群所以顺序一定是“先添加、再认证、后启动任务”。2.6 端口与连通性自查清单Node 启动之后还没等到注册成功八成是网络问题。我整理了一个自查清单建议保存下来端口用途谁来连谁8080Manager 的 Web 控制台浏览器访问 Manager10911Manager 与 Node 的通信端口Node 主动连 Manager2088Node 对外服务端口Manager 需要能访问 Node2181ZooKeeper 客户端端口Manager 和 Node 都要能访问3306源库和目标库数据库端口Node 连源库和目标库排查顺序也很简单先看进程在不在再看端口监听在哪个网卡上最后用telnet或nc从对端机器测一下端口通不通。很多“节点离线”的问题最后发现是云安全组只放行了 8080忘了放行 10911 和 2088。3. 核心同步流程实操从零跑通第一条链路3.1 数据源配置容易被忽略的两个细节在 Manager 控制台的“数据源管理”里把源库和目标库都添加进去。填 JDBC URL、账号、密码之后一定要点一下“测试连接”别等到建任务的时候再报错。第一个细节是 JDBC URL 里的参数。MySQL 8 以上版本如果不带时区参数连接会直接报错推荐格式是jdbc:mysql://源库IP:3306/your_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai第二个细节是目标库账号的权限。除了 DML 权限之外最好授予CREATE、ALTER、INDEX等权限否则遇到表结构同步或者目标表不存在时任务会直接失败。权限最小化固然安全但在同步场景下也要给工具留出必要的操作空间。3.2 Channel 和 Pipeline先搭框架再填规则数据源配好之后进入“同步管理”创建 Channel。Channel 在 Otter 里就是一条完整的业务同步链路创建时需要指定源数据源和目标数据源。Channel 创建完成之后还需要在里面新建 Pipeline。你可以把 Pipeline 理解成这条链路上的一段执行流程它把 Select、Extract、Load 三个阶段串起来并且决定了这段流程跑在哪个 Node 上。这里有两个参数需要关注Batch Size一批处理多少条变更数据默认值跑通即可性能调优时再调大。并发线程数Load 阶段写入目标库的线程数量调高能提吞吐但也会放大目标库压力。建议第一次跑的时候全部用默认参数先把链路跑通确认无误再根据延迟情况逐步调整。我见过有人一上来就把并发调到 32结果目标库从库延迟直接飙到几千秒主库都差点被拖垮。3.3 表映射与字段转换整表映射起步Groovy 脚本兜底Pipeline 建好后最关键的一步是配置“映射规则”。新手最容易犯错的地方是想得太复杂直接在页面上做字段级一一映射。我的建议是第一版先配“整表映射”也就是直接把源库的某张表映射到目标库同名表让数据完整流过去跑通之后再逐步加上字段过滤和转换。Otter 映射规则的核心能力有三个表名和字段名不一致时指定转换关系。不需要同步的列配置排除列直接过滤掉。字段需要做内容变换时写 Groovy 脚本处理。举个例子源库的status字段是数字编码目标库需要转成业务可读的字符串可以写这样一段脚本if (status 1) { return ACTIVE } if (status 2) { return LOCKED } return UNKNOWN注意 Groovy 脚本必须做兜底千万别默认所有枚举值都能被覆盖。脚本里一旦抛出异常这一条数据就会反复重试卡住后面的数据严重时整条链路都会阻塞。3.4 存量数据初始化与增量追平Otter 的核心优势在增量同步但生产上往往还要先处理存量数据。通常的做法是先用 DataX 或 mysqldump 做全量搬运全量搬完之后再启动 Otter 的增量任务。这时就会涉及一个“存量追平”的问题全量搬运期间源库新产生的变更会不会丢我的经验是分段处理。第一步先记录全量开始前的 binlog 位点。第二步跑全量导入。第三步启动 Otter 增量任务并设置起始位点为全量开始前记录的位置。这样全量期间产生的增量变更不会丢增量任务启动后会把它们补上最终达到一致性。同步链路跑通后不要只看“任务状态是正常”就收工。还要在 Manager 的监控页面观察“同步延迟”指标确认延迟稳定在一个合理区间内同时去目标库抽查几条数据验证字段内容和源库一致。4. 线上问题排查实践与避坑清单4.1 启动类问题先用这张表定位运营一段时间后你会发现大多数据同步问题都集中在“起不来”“不消费”“不同步”这三类。我把高频问题整理成一张速查表按表里顺序排查效率最高。现象可能原因处理建议Node 在管理端一直离线Manager 和 Node 网络不通或认证没完成检查 10911、2088 端口连通性重新认证节点任务启动后完全无数据源库 binlog 不是 ROW 格式确认binlog_formatROWbinlog_row_imageFULLCanal 连接源库失败账号缺少复制权限补授REPLICATION SLAVE, REPLICATION CLIENT节点状态正常但同步无进展映射规则未配置或配置错误检查 Pipeline 中映射表是否匹配目标表是否存在登录 Manager 后页面报错元数据库初始化不完整检查初始化 SQL 是否完整执行JDBC 地址是否写对排查这些问题的第一现场都在日志里Node 的日志在otter-node/logs/node/node.logManager 的日志在otter-manager/logs/manager/manager.log。不要在页面里瞎猜直接打开日志搜ERROR关键字定位基本都能找到具体原因。4.2 数据不一致、主键冲突和回环问题同步链路一旦通了第二个坑就是数据冲突。最常见的是主键冲突源库插入一条记录目标库已经存在相同主键的数据。这通常是因为目标库被其他程序直接写过或者同步链路曾经中断后又补跑导致两边数据状态不一致。Otter 在 Channel 里提供了冲突检测策略常用的有源库优先、目标库优先、时间戳优先三种。源库优先适合以源库为唯一事实来源的场景目标库优先适合目标库有本地额外写入的场景。我的建议是在配置之前先在团队内部明确“哪一边的数据才是权威”然后再选择策略。不要指望靠工具自动解决所有冲突业务规则不清楚的话任何策略都是错的。双向同步场景还有一个隐蔽问题回环。A 库的数据同步到 B 库B 库那边一旦有程序对同一行做了更新这条更新又回同步到 A 库如果 A 库再同步回去就会死循环。Otter 针对双向同步内置了回环保护机制但前提是你必须正确配置好相关参数。实际项目里我见过有人开着双向同步却忘了开启回环保护结果两个库互相覆盖数据最后两边都不对。上线前一定要在测试环境模拟双向写入场景验证。4.3 延迟从几秒变成几分钟怎么逐段定位同步延迟是最容易让运维同学头疼的问题。好在 Otter 的执行链路是分阶段的定位思路也非常清晰先看 Select 阶段有没有积压再看 Extract 阶段队列有没有堆积最后看 Load 阶段写入目标库是不是慢。Select 阶段积压说明 Node 消费 binlog 的速度跟不上源库写入速度。这时需要看源库的大事务一个大事务会产生海量 binlog 事件同步端必须等事务完整解析完才能继续。如果源库经常有大事务建议业务侧拆分事务而不是无限堆同步资源。Extract 阶段积压多半是 Groovy 转换脚本执行太慢或频繁抛异常。这时候去日志里搜转换异常把脚本逻辑简化尽量别在转换里查数据库。Load 阶段延迟一般是目标库写入遇到瓶颈。先看目标库的慢查询缺索引就补索引外键太多就考虑在同步场景下临时关闭外键检查同时适当调低 Load 并发避免死锁。还有一个很容易忽略的点ZooKeeper 抖动会导致 Node 会话过期、任务被重新调度恢复后开始追数据看起来就像突然积压了几分钟。遇到莫名其妙的延迟突刺先检查 ZK 集群的健康状态。4.4 实际项目中踩过的四个比较隐蔽的坑第一个坑是server-id和其他实例重复。曾经有一次排查了很久发现同步任务时断时续后来发现是源库 MySQL 的server-id和另一台做 binlog 分析的机器重复了导致 binlog dump 互相挤占。不同实例的server-id一定全局唯一这个用脚本检查一下最省事。第二个坑是目标库外键导致 Load 并发死锁。并发写入目标表时外键约束会触发额外的锁竞争表现就是 Load 阶段频繁报死锁错误。短期的解决办法是把 Load 并发降到 1保证串行写入长期的解决办法是评估外键是否必要如果只是为了数据完整性也可以用应用层逻辑替代。第三个坑是 Groovy 脚本没有异常兜底。有一条数据由于类型转换问题抛了异常结果任务卡在那条数据上反复重试后面的数据全部积压。后来我在所有转换脚本里统一加了 try-catch并且对转换失败的数据单独输出告警日志不再阻塞主链路。第四个坑是 Manager 元数据库的日志表无限膨胀。Otter 运行日志默认写进 Manager 的元数据库运行几个月后日志表能占用几个 GB磁盘满了导致 Manager 整个挂掉。建议定期清理历史日志或者配置定时任务归档删除。5. 生产级部署与监控建议5.1 高可用拓扑怎么搭如果同步链路是核心链路Manager 和 Node 都不能是单点。Manager 可以部署多台实例它们通过 ZooKeeper 选主同一时刻只有一台对外服务另一台处于热备状态。Node 连接 Manager 的otter.manager.address配置里可以写多个地址主 Manager 故障后节点能自动切换。Node 的高可用思路稍有不同。同一个机器下可以部署多个 Node也可以把不同的 Pipeline 分布到不同 Node 上实现任务的物理隔离和负载分摊。比如核心订单表的同步走 Node A日志表的同步走 Node B其中一个挂了另一个不受影响。这里是“隔离优先于冗余”的思路比盲目把所有 Pipeline 堆在同一台 Node 上更符合生产习惯。5.2 监控和告警至少要覆盖四个指标Otter 控制台自带运行监控但生产环境建议再补一层外部监控至少要盯住这四个指标同步延迟源库最新 binlog 位点和 Otter 已消费位点的差值这是同步健康度的首要指标。任务状态任务是否处于 running有没有频繁 restart。消费积压Pipeline 队列是否有持续增长的堆积。目标库写入失败数Load 阶段失败率是否突然上升。告警阈值可以按业务容忍度定。比如核心交易链路延迟超过 30 秒就要电话告警而日志类数据同步延迟 5 分钟都没关系。另外定期做数据一致性对账也很重要我习惯每天凌晨跑一次源库和目标库的 checksum 对比防止“看起来正常但其实个别表字段没同步”的情况。5.3 组合玩法全量加增量的一体化方案最后聊一下我推荐的一体化落地方式全量用 DataX增量用 Otter对账用自定义脚本。全量迁移阶段用 DataX 把存量数据搬到目标库同时在源库记录起始 binlog 位点启动 Otter 增量任务时从该位点开始消费把全量期间产生的增量补上全部追平后再开启定时对账脚本。这个组合方案的好处是每一层都用了最合适的工具不把鸡蛋放在一个篮子里。DataX 在全量搬运、数据转换方面非常成熟Otter 在增量同步和可视化运维上又足够省心两边互补不会冲突。我个人在实际项目里的体会是Otter 这类基于 binlog 的同步工具真正的难点从来不在部署那一步而在于你对自己数据模型的认知是否清晰——哪张表要写转换脚本、哪张表要排除敏感字段、冲突发生时到底该听谁的。把这些规则先在文档里想明白再去页面上配置后续维护会省非常多的力气。如果你们团队第一次上增量同步我的建议是别一上来就全量铺开。先挑一张核心业务表单独跑一条链路运行两周把延迟波动、日志异常、冲突策略这些现象都摸透再逐步放开到全链路。同步工具用得好不好取决于你对它的敬畏程度——把它当黑盒用它迟早会在某个深夜给你上一课。