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

2021-10-14 10:39:53 字數 1803 閱讀 8524

今天我們將嘗試**資料庫的異地多活高可用。注意,我們討論的都是超大資料量(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異地多活方案 最易懂的資料庫異地多活方案

前言 今天我們將嘗試 資料庫的異地多活高可用。注意,我們討論的都是超大資料量 50tb 級別 的資料庫。第一種直接上分布式資料庫,目前市面上常見的有 3 種,tidb,阿里雲 polardb,亞馬遜 aurora。雖然 tidb 可以將資料 sharding 到各個城市,但由於各個城市的物理距離導致...

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

今天我們將嘗試 資料庫的異地多活高可用。注意,我們討論的都是超大資料量 50tb 級別 的資料庫。直接上分布式資料庫,目前市面上常見的有 3 種,tidb,阿里雲 polardb,亞馬遜 aurora。雖然 tidb 可以將資料 sharding 到各個城市,但由於各個城市的物理距離導致的網路消耗,...

mysql異地多活方案 對於異地多活的實踐與思考

對於異地多活的實踐與思考 瀏覽次數 707 一 引 異地多活是近幾年比較熱門的乙個話題,那麼在實際業務中什麼時候需要去做這件事?如何去做?做的時候需要考慮什麼?1 何時去做?個人感覺取決於以下幾個方面 業務發展 基礎設施狀況 技術積澱 2 如何做?目前在網上搜尋到的異地多活方案來看,基本都是阿里 餓...