mysql異地多活方案最易懂的資料庫異地多活方案

今天我們將嘗試**資料庫的異地多活高可用。注意，我們討論的都是超大資料量(50tb 級別)的資料庫。

直接上分布式資料庫，目前市面上常見的有 3 種，tidb，阿里雲 polardb，亞馬遜 aurora。

雖然 tidb 可以將資料 sharding 到各個城市，但由於各個城市的物理距離導致的網路消耗，查詢的效率可想而知(或許可以通過 hash 的方式解決？)。polardb 和 aurora 是相同的思路，計算節點是分布式的，儲存使用共享儲存，帶來的問題還是單機房問題。

因此，分布式資料庫解決的還是超大資料的儲存和單機房的 ha，一旦跨越城市，目前還沒有看到好的方案。

在分庫分表就能無限擴容嗎一文中，我們提到了單元化。單元化說白了，就是先分庫分表，然後，將資料庫劃分為固定的幾個單元，使固定的業務進入固定的單元，這樣，就不會出現每個業務都需要連線所有的資料庫 —— 從而減小連線數。

在單元化的基礎上，我們可以實現異地多活。

解釋一下上圖：我們將資料分成了 3 個資料庫，同時，我們有3個城市的機房，紅色表示為寫節點，每個 shard 庫最好只保證只有乙個地方寫，盡量避免雙寫的問題。另外，杭州機房作為主機房。

上海機房的 shard 1 庫在寫入資料後，會同步到杭州主節點，北京機房的 shard 3 節點在寫入資料後，也會同步到杭州主節點，杭州機房的 shard 2 寫入資料後，也會同步到上海機房和北京機房。

其中，非紅色資料庫都是備庫或讀庫。

我們假設，上海機房斷電。

此時，杭州機房將會接管 shard 1 庫，變成寫入節點。

我們再假設，杭州機房斷電。

杭州機房斷電後，上海機房將會接管 shard 2 節點，同時，將 shard 2 節點的資料同步到北京機房，仍然保證可用性。

注意，這裡為什麼是上海機房的 shard 2 接管，而不是北京機房的 shard 2 接管呢？實際上，我是隨便寫的，在生產環境中，如果有超過 2 個副本，那麼就需要使用 raft 這種一致性協議來決策到底由誰來接管，這裡為了簡單，就寫上海了。

我們觀察到，其中，同步是核心，注意，使用 mysql 自帶的同步是不可靠的，通常會自行開發乙個穩定的，ha 的高可用複製系統，稱之為 drc，即資料複製中心，主要處理多城市或多機房的資料複製。

其中，阿里雲已經有商業版的 drc ，即 dts，支援資料同步，資料訂閱，資料遷移。而其底層則是 otter + canal，已經開源，不過比較簡陋，想上生產環境的話，還需要二次開發和優化。

本文簡單的討論了資料庫的異地多活的方案，我們認為，在單元化的方案中，同步是核心，穩定的同步是保證資料一致的關鍵，而這，在單個機房中，只需要通過簡單的 rpc 即可解決，但在跨機房，跨城市的網路中，就顯得尤為複雜。

那麼，如何打造乙個高可用，低延遲，可靠的一致性，高吞吐的同步系統呢?

且聽下次分享。

it168企業級

讓一部分人先看到企業it的未來

mysql異地多活方案 最易懂的資料庫異地多活方案