故事背景
我们目前的数据库架构是数据库一主一备的架构，都在同一个机房中。这样的话可能会有一个问题，如果整个机房的网络挂了或者是断电了等异常情况，无论是主备数据库都无法使用。后面我们搭建了备灾机房，如果主机房网络有问题则会切换到备灾机房中。但是备灾机房因为不走内网，运维没弄主从复制，说的是走外网有网络延迟，让我们自己想办法- -上回说到用binlog主从配置外网ip也是可行的，不过这次有更好的解决方案，就是使用阿里的otter数据同步系统。
otter介绍
由于阿里有海外业务，衍生出了杭州和美国异地机房的需求，同时为了提升用户体验，整个机房的架构为双A，两边均可写，由此诞生了otter这样一个产品。
otter主要有三个模块：
1、基于canal开源产品，通过binlog实时增量同步数据库的日志数据。
2、典型管理系统架构，manager(web管理)+node(工作节点)。
3、基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作。
搭建otter官方文档：
可以根据官方文档搭建otter，简单来说就是要安装一个manager模块，用于otter管理页面，因为manager模块依赖zookeeper调度node节点，也要先安装zookeeper。然后在需要同步的两个数据库服务器搭建node节点（记得开启bin_log日志），node节点自带了canal，然后就可以在manager模块配置node节点了。
主键冲突
双主同步可能会遇到一个比较麻烦的主键冲突问题，因为两边数据库同时写入数据，用自增id的话会生成同一个id，这时候同步到数据库就会报主键冲突。遇到问题可以先看看官网的issue有没有解决方案，结果....
得到的答案都是说避免唯一索引冲突...那就要从业务上修改id的生成方案，用雪花算法或者redis分布式id等方式。后面看到可以通过自定义修改映射规则自定义EventProcessor，不同步主键id解决。
参考链接：www.jianshu.com/p/9c93bd6bd…
但是这样可能又会引入另外一个小问题，就是如果其他表用了主键id，关联查询会有问题，比如order表有一条数据，userid是1，但是同步的时候自动生成的userid是2，那就对应不上了。用这种方法的关键是不能用主键id去关联表查询。
优点：
1、基于Binlog的增量同步：通过解析MySQL的binlog实现低延迟（毫秒级）数据捕获，对源库性能影响较小，避免全表扫描带来的资源消耗。
2、自动重试与断点续传：网络异常或目标库故障时，自动记录断点并重试，减少人工干预需求。
3、- 无缝集成Canal：复用Canal的Binlog解析能力，降低开发复杂度。
缺点：
1、 依赖组件多： 需独立部署ZooKeeper、Canal、Node Manager等多个组件，初始配置繁琐。
2、学习曲线陡峭： 需熟悉分布式协调、Binlog解析机制，对运维团队技术要求较高。
3、- 资源占用较高：分布式节点间心跳检测、日志同步可能消耗较多网络带宽与内存资源。
总结
Otter适合中大型企业解决MySQL跨地域实时同步的核心痛点，但在多数据库支持、易用性、社区资源等方面需结合团队能力评估。对于复杂场景，可考虑结合Debezium或商业方案（如AWS DMS）互补使用。
