今年下半年開始，接手了部門內(nèi)otter同步的運維事項。雖然閱讀了github上的wiki文檔，但是對otter的雙向同步原理依然不熟悉。
昨天（2019.12.9）睡覺時，不知道為什么突然靈光一閃，開始理解了otter同步的一些過程。
現(xiàn)在在這里記錄下來，作為備忘。
這里主要分兩部分：雙向同步、雙A同步來講。
這兩個概念在otter的頁面上是通過是否有配置主站點來區(qū)分的。
有配置主站點的話就是雙A同步，否則是雙向同步。
雙A同步會有數(shù)據(jù)回環(huán)的問題，雙向同步不會。
我在維護(hù)otter同步的過程中就有碰到過雙向同步配置成雙A同步，導(dǎo)致某張表更新頻繁的時候，讀取到了中間版本，這個后面會說明。
先記住結(jié)論：如果不是兩地同時寫，配置成雙向同步就已經(jīng)足夠了。
雙向同步
假設(shè)有這樣一個雙向同步A <---> B，兩個pipline：piplineA負(fù)責(zé)將A的數(shù)據(jù)同步到B，piplineB負(fù)責(zé)將B的數(shù)據(jù)同步到A
為了便于說明，我們只假設(shè)只同步一張表version。version表只有兩個字段：id，version，其中id是主鍵。并且表中只有一筆數(shù)據(jù)，id=1
這個時候，假設(shè)A將version更新為2，那么兩地binlog的變化流程如下：
可以看到最后binlog再次恢復(fù)到平靜，兩地數(shù)據(jù)保持一致。
雙A同步
雙A同步如果也只是單純是雙向同步的流程的話，會出現(xiàn)數(shù)據(jù)不一致的情況，考慮下面的流程
到最后binlog穩(wěn)定下來的時候，出現(xiàn)了數(shù)據(jù)不一致的問題
為此，otter引入主站點的概念，并規(guī)定備站點到主站點的數(shù)據(jù)，還需要再一次從主站點回放到備戰(zhàn)點。
因此流程變?yōu)椋?/p>
最終我們看到，兩地的數(shù)據(jù)又恢復(fù)了一致
雙A同步的中間版本問題
關(guān)于雙A同步備站點會回放的驗證，可以開啟mysql的sql記錄：
SET GLOBAL general_log = 'ON';
來觀察sql回放過程，這里只做簡單說明。
A、B配置雙A同步，A為備站點。同步表為back，初始數(shù)據(jù)如下：
1. 在A地連續(xù)執(zhí)行5次更新語句 update back set value=concat(value,'a')
2. 觀察general_log，這5次的變更是否有回放到A地
注意到general_log中有5次回放（截圖只截了4次，太長了），這5次回放是從B->A的。
也就是說，在雙A同步中因為有備站點數(shù)據(jù)回放的關(guān)系，如果在回放還沒完成的時候去查詢備站點，那么就會查詢到中間版本。
所以查詢到中間版本是因為：
1. 查詢的是備站點的數(shù)據(jù)
2. 主站點到備站點的網(wǎng)絡(luò)可能比較慢，導(dǎo)致處理回放的過程比較長，容易讀取到中間版本
以上。
