關系型數據庫的發展經歷了漫長歲月，這些數據庫大家都非常熟悉，包括交易型、分析型的很多數據庫產品和技術。TiDB 分布式數據庫是新一代開源分布式 NewSQL 數據庫，整個產品的結構非常清晰，計算跟數據存儲層分離，這是現代大部分分布式數據處理系統通常都會傾向和考慮采用的架構： 

最底層“TiKV” 層，是分布式數據庫的存儲引擎層，不只是用來存取和管理數據，同時也負責執行對數據的并行運算。在TiKV之上即是“TiDB”層，為分布式數據庫的SQL引擎層，處理關系型數據庫諸如連接會話管理、權限控制、SQL解析、優化器優化、執行器等核心功能。此外，還有一個承擔集群大腦角色的集中調度器，叫做“PD”，同時整體架構中還會融合一些運維管理工具，包括部署、調度、監控、備份等。

TiDB可實現自動水平伸縮，強一致性的分布式事務，基于 Raft 算法的多副本復制等重要 NewSQL 特性，并且也滿足我行對于高可用、高性能、高可擴展性的要求。TiDB部署簡單，在線彈性擴容不影響業務，異地多活及自動故障恢復保障數據安全，同時兼容 MySQL 協議，使遷移使用成本降到極低。這篇文章中，我們將詳細介紹TiDB在我行的設計與實踐。

一、設計目標

我們在設計TiDB分布式數據庫集群時，需要考慮多方面的需求，因此，制定了以下內容，作為項目的設計目標。 

二、業務要求

1、業務數據估算

我們設計的TiDB分布式數據庫集群在一期計劃承載一套業務系統，該系統為我行核心支付交易系統。在采購設備之前，我們根據業務的發展規模進行了合理估算，得出了預期日交易量、數據規模、數據增長率等信息。

2、設備需求估算

設備需求按照第一年的數據量和日交易量進行規劃，并綜合考慮了數據副本數和磁盤空間可用率，因此需要規劃足夠的冗余存儲容量。此外，TiDB集群還需要中控機對集群進行統一管理、需要監控機進行集群監控、需要服務器進行數據備份，因此，還要考慮這些服務器的規劃。

除了生產集群，我們還設計了從集群，作為異地災備使用。生產集群和災備集群之間通過binlog同步數據，我們選用了Kafka作為binlog同步工具，因此，需要考慮Kafka服務器的配置規劃。

至此，我行的TiDB集群所需的設備均已規劃完畢，詳情如下：

三、整體架構設計

我們的TiDB集群為兩地三中心多活架構，并且設計了主從集群的災備部署，本章節我們將詳細介紹架構設計。

1、邏輯架構設計 

架構說明：

(1)整個集群采用主從結構，主集群作為生產集群，承擔日常生產服務，從集群通過 binlog 異步同步主集群數據，作為災備集群使用。

(2) 主集群(生產集群)采用兩地三中心架構，分別為同城IDC1、同城IDC2、異地 IDC3。

(3)從集群與主集群通過binlog完成數據同步。

2、物理位置規劃

(1)IDC1、IDC2各配置兩個機柜，均用于部署生產主集群，IDC3一個機柜用于部署生產主集群，另一個機柜用于部署災備從集群。

(2)每個IDC配置兩臺萬兆交換機(以主備模式部署)，主集群各臺機器內部通信、從集群各臺機器內部通信、主從集群之間都是使用萬兆網絡。

(3)全局DNS下掛載三個IDC的負載均衡，各IDC種負載均衡掛載各自中心內部的TiDB服務器，以千兆網環境對外提供業務服務。

四、運維方案設計

1、高可用方案

高可用是 TiDB 數據庫的特性之一，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集群的可用性。我行的TiDB生產集群，由生產中心、同城災備中心、異地災備中心共同實現兩地三中心多活高可用部署方案。下面，我們將從不同的維度來分析集群的高可用性。

(1)從服務器角色的角度

集群中的服務器有三個角色：TiDB、TiKV、PD，我們從這三個角色來分析集群的高可用性。

TiDB 是無狀態的，以實例為單位通過前端的負載均衡設備對外提供服務。當單個TiDB實例失效時，僅僅會影響當前實例上進行的會話，應用服務出現單次請求失敗的情況，應用重新連接至其他TiDB實例后即可繼續獲得服務，此時可以先摘除這個實例進行故障解決或者重新部署一個新的實例。

TiKV 以集群方式部署，通過 Raft 協議保持多副本情況下的數據一致性，并通過 PD 進行數據層面的負載均衡調度。單個TiKV節點失效時，會影響這個節點上存儲的所有Region。對于 Region 中的Leader 結點，會中斷服務，等待其他TiKV上的Region重新選舉Leader，待Leader選出了可繼續對外提供服務;對于Region 中的Follower節點，不會影響服務。當某個 TiKV 節點失效，并且在一段時間內(默認 30 分鐘)無法恢復，PD 會將其上的數據遷移到其他的 TiKV 節點上。

PD 同樣以集群方式部署，通過 Raft 協議保持數據的一致性。單個實例失效時，如果不是leader，那么服務完全不受影響;如果是leader，那么PD集群會重新選出新的leader，自動恢復服務。

(2)從宕機規模的角度

我行的TiDB數據庫集群可容忍單機級、Rack級、數據中心級的故障，從而實現高可用。

單機服務器故障，分為TiDB、TiKV、PD三個角色，參考上一小節的闡述。

我們將集群所有服務器分散放置在各個Rack里，根據Raft協議大多數原則，單個Rack出現故障，不會影響集群對外提供服務。我行的架構允許集群中兩個Rack同時出現故障。

任何一個數據中心發生故障，根據Raft協議大多數原則，剩余的兩個數據中心仍可對外提供服務。

2、存儲方案

TiDB 集群數據庫集群的數據包括業務數據、數據庫日志、數據庫運行狀況數據，綜合考慮硬盤的容量、I/O讀寫速率等因素后，我們選用了SAS盤+SSD盤作為服務器硬盤存儲。需要注意的是，在規劃容量時，要考慮數據多副本的特點，從而規劃出足夠的存儲容量。

數據庫日志分為TiDB日志、TiKV日志、PD日志，分別存儲在各自的實例節點上。

數據庫運行狀況相關數據存放集群默認庫里，也分散存儲在所有TiKV節點上，通過定期執行analyze操作進行更新。

3、監控與告警

我行的TiDB數據庫監控分三個模塊：數據庫運行狀況實時監控、旁路監控、mocha監控，告警也分別由這三個模塊各自觸發。

(1)數據庫運行狀況實時監控

這部分是最多、最重要的監控內容。

TiDB集群使用開源時序數據庫 Prometheus 作為監控和性能指標信息存儲方案，使用 Grafana 可視化組件對監控數據進行展示。告警渠道有兩個，一個是我行自主研發的一體化監控平臺，一個是AlertManager。監控組件安裝在監控服務器上，Prometheus產生的監控數據也存儲在這里。

監控與告警總體架構如下圖所示： 

集群的TiDB/PD/TiKV組件分別向Prometheus Pushgateway推送數據，統一供 Prometheus server抓取;通過定制Grafana展示模板對Prometheus中的監控數據進行展示。

當監控的數值超過我們指定的閾值時，就會觸發告警，告警信息通過AlertManager或一體化監控平臺，以郵件和短信的方式通知管理員。根據故障發生的嚴重程度，告警被劃分為3個級別：warning、critical、emergency，其中emergency級別最高，表示故障最嚴重。根據業務要求和信息系統安全性要求，我們分別定制了不同的告警策略。

(2)旁路監控

旁路監控是對prometheus監控的補充，一方面檢測prometheus的模塊是否正常，另一方面也會直接監控 TiDB 的關鍵服務工作狀態，針對異常產生告警。下圖是旁路監控示意圖： 

(3)mocha監控

監控數據庫級別的運行狀況。

4、備份與恢復

雖然TiDB集群的多副本策略可以避免故障發生時數據的丟失，但我們仍然需要制定完善的數據備份與恢復策略，進一步加強數據安全性。

通過全量備份工具(Mydumper)與增量備份組件(binlog)，對 TiDB 集群數據庫的任意時間點的狀態進行保存;當需要恢復數據到某一個時間點時，首先使用全量數據恢復工具(Loader)恢復該時間點之前的最后一個全量備份，確認全量導入無誤后，使用增量恢復工具(Reparo)恢復PB文件形式的binlog 增量數據到所要求的恢復時間點。

(1)備份

所有的備份組件都安裝在備份服務器上，我們編寫了自動備份腳本，全量備份和增量數據文件都先存儲在本地，再轉儲至磁帶上。

備份策略：

每周一次全備份，選在業務量少的夜間進行;

每天實時備份增量數據。

備份特性：

支持按表恢復數據;

TiDB 的備份數據可以恢復到 TiDB 集群或 MySQL(5.7.x)中;

TiDB 增量備份是貫穿于數據庫整個生命周期的，它以PB文件的形式存在，PB文件由 Drainer 解析 binlog 生成。

備份示意圖如下： 

(2)恢復

任意一臺安裝有mysql實例的服務器均可用來恢復數據，也可將備份的生產數據經過脫敏處理后用于測試環境的TiDB集群。

5、日常運維方案

(1)產品升級策略

TiDB作為開源軟件，其產品迭代速度快，常使用補丁式更新，一旦發現錯誤可馬上更新，這與銀行業要求的穩定性存在一定差異，且不符合監管要求的變更流程。因此，我們目前的升級策略是待其新發布的大版本穩定后再安排變更升級，對于補丁式小版本，在不影響業務的情況下，暫緩升級。

(2)集群日常巡檢

除了24小時實時監控外，我行要求每日對數據庫進行定時巡檢。這部分我們編寫了自動巡檢腳本，通過郵件方式推送數據庫運行狀態。

(3)集群擴容縮容方案

TiDB 集群可以在不影響線上服務的情況下動態進行擴容和縮容，實現在線靈活可擴展特性。擴容縮容也分為TiDB、TiKV、PD三種情況，具體操作在PingCAP官網都有清晰地描述，這里不再贅述。

需要特別說明的是擴容PD時，需滾動升級集群，升級過程中會導致TiDB連接斷開，影響業務，待升級完成即可恢復，因此，最好選擇業務量少的時段進行。

6、災備方案

除了生產主集群，我行的TiDB集群還增加了從集群的設計，目的是為了實現異地災備。因此，我們也制定了完善的主從集群災備切換方案。

下圖是一個簡單的主從集群部署示意圖，主從集群通過binlog進行數據同步： 

切換時，主從集群架構不變，僅僅是主從同步數據流改變方向。切換流程如下：

1)停業務，等待主從同步完成;

2)關閉主集群 Drainer, 停止主從同步;

3)關閉主集群，記錄當前時間戳;

4)將業務數據庫連接切換到從集群;

5)啟動主集群;

6)從集群運行 Drainer，向主機群同步。

7、應用適配和優化

(1)檢查和優化庫/表/索引等內部對象

TiDB 優化器會根據統計信息來選擇最優的SQL執行計劃。

統計信息收集了表級別和列級別的信息，存儲在stats_meta、tats_histograms、stats_buckets這三個表里。除了系統自動更新外，我們還編寫了手動更新統計信息的腳本，每日定期執行ANALYZE語句來收集統計信息。

SQL執行計劃由一系列的 operator 構成，TiDB提供了EXPLAIN語句，可以查看SQL語句的執行詳細信息。

當數據庫中的對象需要優化時，我們會綜合分析統計信息、執行計劃，然后給出優化方案。

(2)性能檢查和判斷

應用連接 TiDB 數據庫后，需要著重檢查幾個指標：QPS、TPS、響應時間、業務庫大小、業務表增長率、數據庫連接會話數、熱點盤等。目前我們會通過監控、巡檢、日志三方面綜合進行指標分析，從而判斷數據庫的性能。

五、結語

綜上即為我行分布式數據庫TiDB兩地三中心多活架構的方案設計與具體實踐，并且結合涵蓋了日常運維管理的各個方面，包括監控告警、集群調優、備份恢復、災備切換、擴容縮容等。今后我行會嘗試將更多的業務場景遷移到分布式數據庫上，以探索更多的實踐領域。同時也希望將我行的實踐經驗分享給大家，互相學習、共同進步，歡迎各位提出寶貴建議!