兩地三中心部署TiDB數據庫高可用環境

一、簡介

二、架構

詳細示例

一、簡介

二、架構

詳細示例

三、配置

3.1、示例

3.2、Labels 設計

3.3、參數配置優化

本文檔簡要介紹兩地三中心部署的架構模型及配置。

參考：https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-deployment

一、簡介

兩地三中心架構，即生產數據中心、同城災備中心、異地災備中心的高可用容災方案。在這種模式下，兩個城市的三個數據中心互聯互通，如果一個數據中心發生故障或災難，其他數據中心可以正常運行并對關鍵業務或全部業務實現接管。相比同城多中心方案，兩地三中心具有跨城級高可用能力，可以應對城市級自然災害。

TiDB 分布式數據庫通過 Raft 算法原生支持兩地三中心架構的建設，并保證數據庫集群數據的一致性和高可用性。而且因同城數據中心網絡延遲相對較小，可以把業務流量同時派發到同城兩個數據中心，并通過控制 Region Leader 和 PD Leader 分布實現同城數據中心共同負載業務流量的設計。

二、架構

本文以北京和西安為例，闡述 TiDB 分布式數據庫兩地三中心架構的部署模型。

本例中，北京有兩個機房 IDC1 和 IDC2，異地西安一個機房 IDC3。北京同城兩機房之間網絡延遲低于 3 ms，北京與西安之間的網絡使用 ISP 專線，延遲約 20 ms。

下圖為集群部署架構圖，具體如下：

集群采用兩地三中心部署方式，分別為北京 IDC1，北京 IDC2，西安 IDC3；

集群采用 5 副本模式，其中 IDC1 和 IDC2 分別放 2 個副本，IDC3 放 1 個副本；TiKV 按機柜打 Label，既每個機柜上有一份副本。

副本間通過 Raft 協議保證數據的一致性和高可用，對用戶完全透明。

該架構具備高可用能力，同時通過 PD 調度限制了 Region Leader 盡量只出現在同城的兩個數據中心，這相比于三數據中心，即 Region Leader 分布不受限制的方案有以下優缺點：

優點

Region Leader 都在同城低延遲機房，數據寫入速度更優。

兩中心可同時對外提供服務，資源利用率更高。

可保證任一數據中心失效后，服務可用并且不發生數據丟失。

缺點

因為數據一致性是基于 Raft 算法實現，當同城兩個數據中心同時失效時，因為異地災備中心只剩下一份副本，不滿足 Raft 算法大多數副本存活的要求。最終將導致集群暫時不可用，需要從一副本恢復集群，只會丟失少部分還沒同步的熱數據。這種情況出現的概率是比較小的。

由于使用到了網絡專線，導致該架構下網絡設施成本較高。

兩地三中心需設置 5 副本，數據冗余度增加，增加空間成本。

詳細示例

北京、西安兩地三中心配置詳解：

如上圖所示，北京有兩個機房 IDC1 和 IDC2，機房 IDC1 中有三套機架 RAC1、RAC2、RAC3，機房 IDC2 有機架 RAC4、RAC5；西安機房 IDC3 有機架 RAC6。

如上圖中 RAC1 機架所示，TiDB、PD 服務部署在同一臺服務器上，還有兩臺 TiKV 服務器；每臺 TiKV 服務器部署 2 個 TiKV 實例（tikv-server），RAC2、RAC4、RAC5、RAC6 類似。

機架 RAC3 上安放 TiDB Server 及中控 + 監控服務器。部署 TiDB Server，用于日常管理維護、備份使用。中控 + 監控服務器上部署 Prometheus、Grafana 以及恢復工具；

另可增加備份服務器，其上部署 Drainer，Drainer 以輸出 file 文件的方式將 binlog 數據保存到指定位置，實現增量備份的目的。

三、配置

3.1、示例

以下為一個 tiup topology.yaml 文件示例：

# # Global variables are applied to all deployments and used as the default value of # # the deployments if a specific deployment value is missing. global: user: "tidb" ssh_port: 22 deploy_dir: "/data/tidb_cluster/tidb-deploy" data_dir: "/data/tidb_cluster/tidb-data" server_configs: tikv: server.grpc-compression-type: gzip pd: replication.location-labels: ["dc","rack","zone","host"] schedule.tolerant-size-ratio: 20.0 pd_servers: - host: 10.63.10.10 name: "pd-10" - host: 10.63.10.11 name: "pd-11" - host: 10.63.10.12 name: "pd-12" - host: 10.63.10.13 name: "pd-13" - host: 10.63.10.14 name: "pd-14" tidb_servers: - host: 10.63.10.10 - host: 10.63.10.11 - host: 10.63.10.12 - host: 10.63.10.13 - host: 10.63.10.14 tikv_servers: - host: 10.63.10.30 config: server.labels: { dc: "1", zone: "1", rack: "1", host: "30" } - host: 10.63.10.31 config: server.labels: { dc: "1", zone: "2", rack: "2", host: "31" } - host: 10.63.10.32 config: server.labels: { dc: "2", zone: "3", rack: "3", host: "32" } - host: 10.63.10.33 config: server.labels: { dc: "2", zone: "4", rack: "4", host: "33" } - host: 10.63.10.34 config: server.labels: { dc: "3", zone: "5", rack: "5", host: "34" } raftstore.raft-min-election-timeout-ticks: 1000 raftstore.raft-max-election-timeout-ticks: 1200 monitoring_servers: - host: 10.63.10.60 grafana_servers: - host: 10.63.10.60 alertmanager_servers: - host: 10.63.10.60

3.2、Labels 設計

在兩地三中心部署方式下，對于 Labels 的設計需要充分考慮到系統的可用性和容災能力，建議根據部署的物理結構來定義 DC、ZONE、RACK、HOST 四個等級。

PD 設置中添加 TiKV label 的等級配置。

server_configs: pd: replication.location-labels: ["dc","zone","rack","host"]

tikv_servers 設置基于 TiKV 真實物理部署位置的 Label 信息，方便 PD 進行全局管理和調度。

tikv_servers: - host: 10.63.10.30 config: server.labels: { dc: "1", zone: "1", rack: "1", host: "30" } - host: 10.63.10.31 config: server.labels: { dc: "1", zone: "2", rack: "2", host: "31" } - host: 10.63.10.32 config: server.labels: { dc: "2", zone: "3", rack: "3", host: "32" } - host: 10.63.10.33 config: server.labels: { dc: "2", zone: "4", rack: "4", host: "33" } - host: 10.63.10.34 config: server.labels: { dc: "3", zone: "5", rack: "5", host: "34" }

3.3、參數配置優化

在兩地三中心的架構部署中，從性能優化的角度，除了常規參數配置外，還需要對集群中相關組件參數進行調整。

啟用 TiKV gRPC 消息壓縮。由于涉及到集群中的數據在網絡中傳輸，需要開啟 gRPC 消息壓縮，降低網絡流量。

server.grpc-compression-type: gzip

調整 PD balance 緩沖區大小，提高 PD 容忍度，因為 PD 會根據節點情況計算出各個對象的 score 作為調度的依據，當兩個 store 的 leader 或 Region 的得分差距小于指定倍數的 Region size 時，PD 會認為此時 balance 達到均衡狀態。

schedule.tolerant-size-ratio: 20.0

異地 DC3 TiKV 節點網絡優化，單獨修改異地 TiKV 此參數，拉長異地副本參與選舉的時間，盡量避免異地 TiKV 中的副本參與 Raft 選舉。

raftstore.raft-min-election-timeout-ticks: 1000 raftstore.raft-max-election-timeout-ticks: 1200

調度設置。在集群啟動后，通過 tiup ctl pd 工具進行調度策略修改。修改 TiKV Raft 副本數按照安裝時規劃好的副本數進行設置，在本例中為 5 副本。

config set max-replicas 5

禁止向異地機房調度 Raft Leader，當 Raft Leader 在異地數據中心時，會造成不必要的本地數據中心與異地數據中心間的網絡消耗，同時由于網絡帶寬和延遲的影響，也會對 TiDB 的集群性能產生影響。需要禁用異地中心的 Raft leader 的調度。

config set label-property reject-leader dc 3

設置 PD 的優先級，為了避免出現異地數據中心的 PD 成為 Leader，可以將本地數據中心的 PD 優先級調高（數字越大，優先級越高），將異地的 PD 優先級調低。

member leader_priority PD-10 5 member leader_priority PD-11 5 member leader_priority PD-12 5 member leader_priority PD-13 5 member leader_priority PD-14 1

數據庫

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