今年下半年开始，接手了部门内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将version更新为2，那么两地binlog的变化流程如下：
可以看到最后binlog再次恢复到平静，两地数据保持一致。
双A同步
双A同步如果也只是单纯是双向同步的流程的话，会出现数据不一致的情况，考虑下面的流程
到最后binlog稳定下来的时候，出现了数据不一致的问题
为此，otter引入主站点的概念，并规定备站点到主站点的数据，还需要再一次从主站点回放到备战点。
因此流程变为：
最终我们看到，两地的数据又恢复了一致
双A同步的中间版本问题
关于双A同步备站点会回放的验证，可以开启mysql的sql记录：
SET GLOBAL general_log = 'ON';
来观察sql回放过程，这里只做简单说明。
A、B配置双A同步，A为备站点。同步表为back，初始数据如下：
1. 在A地连续执行5次更新语句 update back set value=concat(value,'a')
2. 观察general_log，这5次的变更是否有回放到A地
注意到general_log中有5次回放（截图只截了4次，太长了），这5次回放是从B->A的。
也就是说，在双A同步中因为有备站点数据回放的关系，如果在回放还没完成的时候去查询备站点，那么就会查询到中间版本。
所以查询到中间版本是因为：
1. 查询的是备站点的数据
2. 主站点到备站点的网络可能比较慢，导致处理回放的过程比较长，容易读取到中间版本
以上。
