今年下半年开始，接手了部门内otter同步的运维事项。虽然阅读了github上的wiki文档，但是对otter的双向同步原理依然不熟悉。

昨天（2019.12.9）睡觉时，不知道为什么突然灵光一闪，开始理解了otter同步的一些过程。

现在在这里记录下来，作为备忘。

---

这里主要分两部分：双向同步、双A同步来讲。

这两个概念在otter的页面上是通过是否有配置主站点来区分的。

有配置主站点的话就是双A同步，否则是双向同步。

双A同步会有数据回环的问题，双向同步不会。

我在维护otter同步的过程中就有碰到过双向同步配置成双A同步，导致某张表更新频繁的时候，读取到了中间版本，这个后面会说明。

先记住结论：如果不是两地同时写，配置成双向同步就已经足够了。

---

双向同步

假设有这样一个双向同步A <---> B，两个pipline：piplineA负责将A的数据同步到B，piplineB负责将B的数据同步到A

为了便于说明，我们只假设只同步一张表version。version表只有两个字段：id，version，其中id是主键。并且表中只有一笔数据，id=1

A、B两地的version表，一开始只有一笔数据

这个时候，假设A将version更新为2，那么两地binlog的变化流程如下：

双向同步过程中，两地的binlog变化示意图

可以看到最后binlog再次恢复到平静，两地数据保持一致。

双A同步

双A同步如果也只是单纯是双向同步的流程的话，会出现数据不一致的情况，考虑下面的流程

双A同步如果不做额外的处理的话，会出现数据不一致的问题

到最后binlog稳定下来的时候，出现了数据不一致的问题

为此，otter引入主站点的概念，并规定备站点到主站点的数据，还需要再一次从主站点回放到备战点。

因此流程变为：

双A同步引入主站点的概念，消除了数据可能不一致的风险

最终我们看到，两地的数据又恢复了一致

双A同步的中间版本问题

关于双A同步备站点会回放的验证，可以开启mysql的sql记录：

SET GLOBAL general_log = 'ON';

来观察sql回放过程，这里只做简单说明。

A、B配置双A同步，A为备站点。同步表为back，初始数据如下：

双A同步中初始值

1. 在A地连续执行5次更新语句 update back set value=concat(value,'a')

2. 观察general_log，这5次的变更是否有回放到A地

A地的5次更新sql B地回放到A地的这5次sql

注意到general_log中有5次回放（截图只截了4次，太长了），这5次回放是从B->A的。

也就是说，在双A同步中因为有备站点数据回放的关系，如果在回放还没完成的时候去查询备站点，那么就会查询到中间版本。

所以查询到中间版本是因为：

1. 查询的是备站点的数据

2. 主站点到备站点的网络可能比较慢，导致处理回放的过程比较长，容易读取到中间版本

以上。