Mysql multi replication 之 Tungsten

Tungsten multi replication

簡單介紹
Tungsten 提供的是一種類似於xtradb cluster的多主複製方式，其核心思想是多個Master同時維護一份資料。
xtradb cluster維護的是一個環形結構通過在Mysql代碼曾進行加鎖來保證資料一致性，而Tungsten則是簡單的依賴於Binlog的Transfer和Apply來保證所有Master節點的資料都是一致的，並且Tungsten並不是簡單的維護一個環形結構而是一種更複雜的結構。

拓撲結構

下面這張圖就是Matser節點為4個的情況下的一個拓撲結構：

可以看出其對應關係非常複雜，任何一個Master節點寫的Binlog都要向其他三個節點進行傳輸，如果要再加一個節點的話就會是這樣：

其實這樣最大的好處就是比較靈活，我可以把一台Mysql的Binlog放在任何一台或者多台Myqsql上執行。
其實這個結構是什麼樣完全取決於怎麼配的。

實現原理

下面就兩個Master節點的情況下對他的原理進行說明。

一共有兩個Master節點：Sjc和Nyc
每一個Master節點對應兩個服務LocalService和RemoteService，：Sjc的LocalService會把Binlog解析成TungstenLog推送到Nyc的RemoteService上並且在Nyc上執行，同樣Nyc的LocalService會把Binlog解析成TungstenLog推送到Sjc的RemoteService上並且執行。
這樣會有一個問題：
會不會出現無線迴圈的推送，比如說在Sjc產生的Binlog執行到Nyc上，在Nyc上Apply這個Binlog以後產生的Binlog會不會再次傳到Sjc上執行？
Tungsten使用BidiRemoteSlaveFilter來防止這種情況的發生，簡單的理解他會加一個標記符來標記這個SQL語句是在本機執行的還是遠程傳輸過來的。比如說在Sjc上執行的SQL語句傳輸到Nyc上，在Nyc上執行以後就會在Binlog裡加一個注釋，來表明是從哪一個LocalService傳送過來的，這樣他就能知道把需要哪些Binlog傳送到別的機器上。

insert into xx values (911) /* ___SERVICE___ = [test1] */

Tungsten的問題

Tungsten完全是根據Binlog解析成TungstenLog傳輸到別的機器再Apply來保證資料完整性的，所以這個過程中問題會很多。
假設這樣一種情況：
master1 開啟事務執行一條Update，修改一條記錄。
Master2 同時開始事務執行Delete，刪除Master1修改的記錄，並提交。
單節點的情況下會被鎖住，但是在Tungsten這種複製關係中會直接報錯。
在TungstenLog的傳輸過程中有可能會遇到延遲等網路問題或者Tungsten本身服務掛掉，這時候各個節點資料之間的一致性是無法保證的。

雖然Tungsten有著這樣那樣的問題，但是tungsten 他很靈活，他能實現多Master寫到一個slave。這樣對我們合并多個Slave有很大協助。