跨數據中心部署方案

作為 NewSQL 數據庫，TiDB 兼顧了傳統關系型數據庫的優秀特性以及 NoSQL 數據庫可擴展性，以及跨數據中心(下文簡稱“中心”)場景下的高可用。本文檔旨在介紹跨數據中心部署的不同解決方案。

三中心部署方案

TiDB, TiKV, PD 分別分布在 3 個不同的中心，這是最常規，可用性最高的方案。

優點

所有數據的副本分布在三個數據中心，任何一個數據中心失效后，另外兩個數據中心會自動發起 leader election，并在合理長的時間內(通常情況 20s 以內)恢復服務，并且不會產生數據丟失。

缺點

性能受網絡延遲影響。

對于寫入的場景，所有寫入的數據需要同步復制到至少 2 個數據中心，由于 TiDB 寫入過程使用兩階段提交，故寫入延遲至少需要 2 倍數據中心間的延遲。

對于讀請求來說，如果數據 leader 與發起讀取的 TiDB 節點不在同一個數據中心，也會受網絡延遲影響。

TiDB 中的每個事務都需要向 PD leader 獲取 TSO，當 TiDB 與 PD leader 不在同一個數據中心時，它上面運行的事務也會因此受網絡延遲影響，每個有寫入的事務會獲取兩次 TSO。

讀性能優化

如果不需要每個數據中心同時對外提供服務，可以將業務流量全部派發到一個數據中心，并通過調度策略把 Region leader 和 PD leader 都遷移到同一個數據中心(我們在上文所述的測試中也做了這個優化)。這樣一來，不管是從 PD 獲取 TSO 還是讀取 Region 都不受數據中心間網絡的影響。當該數據中心失效后，PD leader 和 Region leader 會自動在其它數據中心選出，只需要把業務流量轉移至其他存活的數據中心即可。

兩地三中心部署方案

兩地三中心的方案與三數據中心類似，算是三機房方案根據業務特點進行的優化，區別是其中有兩個數據中心距離很近(通常在同一個城市)，網絡延遲相對很小。這種場景下，我們可以把業務流量同時派發到同城的兩個數據中心，同時控制 Region leader 和 PD leader 也分布在同城的兩個數據中心。

與三數據中心方案相比，兩地三中心有以下優勢：

寫入速度更優

兩中心同時提供服務資源利用率更高

依然能保證任何一個數據中心失效后保持可用并且不發生數據丟失

但是，缺陷是如果同城的兩個數據中心同時失效(理論上講要高于異地三數據中心損失 2 個的概率)，將會導致不可用以及部分數據丟失。

兩數據中心 + binlog 同步方案

兩數據中心 + binlog 同步類似于傳統的 MySQL 中 master/slave 方案。兩個數據中心分別部署一套完整的 TiDB 集群，我們稱之為主集群和從集群。正常情況下所有的請求都在主集群，寫入的數據通過 binlog 異步同步至從集群并寫入。

當主集群整個數據中心失效后，業務可以切換至從集群，與 MySQL 類似，這種情況下會有一些數據缺失。對比 MySQL，這個方案的優勢是數據中心內的 HA — 少部分節點故障時，通過重新選舉 leader 自動恢復服務，不需要人工干預。

另外部分用戶采用這種方式做雙數據中心多活，兩個數據中心各有一個集群，將業務分為兩個庫，每個庫服務一部分數據，每個數據中心的業務只會訪問一個庫，兩個集群之間通過 binlog 將本數據中心業務所涉及的庫中的數據變更同步到對端機房，形成環狀備份。

注意：

在兩數據中心 + binlog 同步部署方案中，數據中心之間只有 binlog 異步復制。在數據中心間的延遲較高的情況下，從集群落后主集群的數據量會增大。當主集群故障后(DR)，會造成數據丟失，丟失的數據量受網絡延遲等因素影響。

高可用和容災分析

對于三數據中心方案和兩地三中心方案，我們能得到的保障是任意一個數據中心故障時，集群能自動恢復服務，不需要人工介入，并能保證數據一致性。注意各種調度策略都是用于幫助性能優化的，當發生故障時調度機制總是第一優先考慮可用性而不是性能。

對于兩數據中心 + binlog 同步的方案，主集群內少量節點故障時也能自動恢復服務，不需要人工介入，并能保證數據一致性。當整個主集群故障時，需要人工切換至從集群，并可能發生一些數據丟失，數據丟失的數量取決于同步延遲，和網絡條件有關。

總結

以上是生活随笔為你收集整理的mysql集群跨地域同步部署_跨地域冗余 - 跨数据中心部署方案 - 《TiDB v2.1 用户文档》 - 书栈网 · BookStack...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。