同城多數據中心部署TiDB數據庫高可用環境

一、了解 Raft 協議

二、同城三數據中心方案

2.1、簡易架構圖

2.2、架構優化圖

2.3、樣例部署圖

2.3.1、樣例拓撲架構

1、TiKV Labels 簡介

2、TiKV Labels 樣例規劃

一、了解 Raft 協議

二、同城三數據中心方案

2.1、簡易架構圖

2.2、架構優化圖

2.3、樣例部署圖

2.3.1、樣例拓撲架構

1、TiKV Labels 簡介

2、TiKV Labels 樣例規劃

2.3.2、高可用和容災分析

作為 NewSQL 數據庫，tidb 兼顧了傳統關系型數據庫的優秀特性、NoSQL 數據庫可擴展性以及跨數據中心場景下的高可用。本文檔旨在介紹同城多數據中心部署 TiDB 方案。

參考：https://docs.pingcap.com/zh/tidb/stable/multi-data-centers-in-one-city-deployment

一、了解 Raft 協議

Raft 是一種分布式一致性算法，在 TiDB 集群的多種組件中，PD 和 TiKV 都通過 Raft 實現了數據的容災。Raft 的災難恢復能力通過如下機制實現：

Raft 成員的本質是日志復制和狀態機。Raft 成員之間通過復制日志來實現數據同步；Raft 成員在不同條件下切換自己的成員狀態，其目標是選出 leader 以提供對外服務。

Raft 是一個表決系統，它遵循多數派協議，在一個 Raft Group 中，某成員獲得大多數投票，它的成員狀態就會轉變為 leader。也就是說，當一個 Raft Group 還保有大多數節點 (majority) 時，它就能夠選出 leader 以提供對外服務。

遵循 Raft 可靠性的特點，放到現實場景中：

想克服任意 1 臺服務器 (host) 的故障，應至少提供 3 臺服務器。

想克服任意 1 個機柜 (rack) 的故障，應至少提供 3 個機柜。

想克服任意 1 個數據中心（dc，又稱機房）的故障，應至少提供 3 個數據中心。

想應對任意 1 個城市的災難場景，應至少規劃 3 個城市用于部署。

可見，原生 Raft 協議對于偶數副本的支持并不是很友好，考慮跨城網絡延遲影響，或許同城三數據中心是最適合部署 Raft 的高可用及容災方案。

二、同城三數據中心方案

同城三數據中心方案，即同城存有三個機房部署 TiDB 集群，同城三數據中心間的數據同步通過集群自身內部（Raft 協議）完成。同城三數據中心可同時對外進行讀寫服務，任意中心發生故障不影響數據一致性。

2.1、簡易架構圖

集群 TiDB、TiKV 和 PD 組件分別分布在 3 個不同的數據中心，這是最常規且高可用性最高的方案。

優點：

所有數據的副本分布在三個數據中心，具備高可用和容災能力

任何一個數據中心失效后，不會產生任何數據丟失 (RPO = 0)

任何一個數據中心失效后，其他兩個數據中心會自動發起 leader election，并在合理長的時間內（通常情況 20s 以內）自動恢復服務

缺點：

性能受網絡延遲影響。具體影響如下：

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

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

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

2.2、架構優化圖

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

優點：

集群 TSO 獲取能力以及讀取性能有所提升。具體調度策略設置模板參照如下：

-- 其他機房統一驅逐 leader 到業務流量機房 config set label-property reject-leader LabelName labelValue -- 遷移 PD leader 并設置優先級 member leader transfer pdName1 member leader_priority pdName1 5 member leader_priority pdName2 4 member leader_priority pdName3 3

缺點：

寫入場景仍受數據中心網絡延遲影響，這是因為遵循 Raft 多數派協議，所有寫入的數據需要同步復制到至少 2 個數據中心

TiDB Server 數據中心級別單點

業務流量純走單數據中心，性能受限于單數據中心網絡帶寬壓力

TSO 獲取能力以及讀取性能受限于業務流量數據中心集群 PD、TiKV 組件是否正常，否則仍受跨數據中心網絡交互影響

2.3、樣例部署圖

2.3.1、樣例拓撲架構

下面假設某城存有 IDC1、IDC2、IDC3 三機房，機房 IDC 中存有兩套機架，每個機架存有三臺服務器，不考慮混布以及單臺機器多實例部署下，同城三數據中心架構集群（3 副本）部署參考如下：

TiKV 是一個 Multi-Raft 系統，其數據按 Region（默認 96M）切分，每個 Region 的 3 個副本構成了一個 Raft Group。假設一個 3 副本 TiDB 集群，由于 Region 的副本數與 TiKV 實例數量無關，則一個 Region 的 3 個副本只會被調度到其中 3 個 TiKV 實例上，也就是說即使集群擴容 N 個 TiKV 實例，其本質仍是一個 3 副本集群。

由于 3 副本的 Raft Group 只能容忍 1 副本故障，當集群被擴容到 N 個 TiKV 實例時，這個集群依然只能容忍一個 TiKV 實例的故障。2 個 TiKV 實例的故障可能會導致某些 Region 丟失多個副本，整個集群的數據也不再完整，訪問到這些 Region 上的數據的 SQL 請求將會失敗。而 N 個 TiKV 實例中同時有兩個發生故障的概率是遠遠高于 3 個 TiKV 中同時有兩個發生故障的概率的，也就是說 Multi-Raft 系統集群擴容 TiKV 實例越多，其可用性是逐漸降低的。

正因為 Multi-Raft TiKV 系統局限性， Labels 標簽應運而出，其主要用于描述 TiKV 的位置信息。Label 信息隨著部署或滾動更新操作刷新到 TiKV 的啟動配置文件中，啟動后的 TiKV 會將自己最新的 Label 信息上報給 PD，PD 根據用戶登記的 Label 名稱（也就是 Label 元信息），結合 TiKV 的拓撲進行 Region 副本的最優調度，從而提高系統可用性。

針對 TiKV Labels 標簽，你需要根據已有的物理資源、容災能力容忍度等方面進行設計與規劃，進而提升系統的可用性和容災能力。并根據已規劃的拓撲架構，在集群初始化配置文件中進行配置（此處省略其他非重點項）：

server_configs: pd: replication.location-labels: ["zone","dc","rack","host"] tikv_servers: - host: 10.63.10.30 config: server.labels: { zone: "z1", dc: "d1", rack: "r1", host: "30" } - host: 10.63.10.31 config: server.labels: { zone: "z1", dc: "d1", rack: "r1", host: "31" } - host: 10.63.10.32 config: server.labels: { zone: "z1", dc: "d1", rack: "r2", host: "32" } - host: 10.63.10.33 config: server.labels: { zone: "z1", dc: "d1", rack: "r2", host: "33" } - host: 10.63.10.34 config: server.labels: { zone: "z2", dc: "d1", rack: "r1", host: "34" } - host: 10.63.10.35 config: server.labels: { zone: "z2", dc: "d1", rack: "r1", host: "35" } - host: 10.63.10.36 config: server.labels: { zone: "z2", dc: "d1", rack: "r2", host: "36" } - host: 10.63.10.37 config: server.labels: { zone: "z2", dc: "d1", rack: "r2", host: "37" } - host: 10.63.10.38 config: server.labels: { zone: "z3", dc: "d1", rack: "r1", host: "38" } - host: 10.63.10.39 config: server.labels: { zone: "z3", dc: "d1", rack: "r1", host: "39" } - host: 10.63.10.40 config: server.labels: { zone: "z3", dc: "d1", rack: "r2", host: "40" } - host: 10.63.10.41 config: server.labels: { zone: "z3", dc: "d1", rack: "r2", host: "41" }

本例中，zone 表示邏輯可用區層級，用于控制副本的隔離（當前集群 3 副本）。

不直接采用 dc，rack，host 三層 Label 結構的原因是考慮到將來可能發生 dc（數據中心）的擴容，假設新擴容的 dc 編號是 d2，d3，d4，則只需在對應可用區下擴容 dc；rack 擴容只需在對應 dc 下擴容即可。

如果直接采用 dc，rack，host 三層 Label 結構，那么擴容 dc 操作可能需重打 Label，TiKV 數據整體需要 Rebalance。

2.3.2、高可用和容災分析

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

數據庫 邊緣數據中心管理 EDCM

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。