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

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

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

一、設計目標

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

二、業(yè)務要求

1、業(yè)務數(shù)據(jù)估算

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

2、設備需求估算

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

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

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

三、整體架構設計

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

1、邏輯架構設計 

架構說明：

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

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

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

2、物理位置規(guī)劃

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

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

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

四、運維方案設計

1、高可用方案

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

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

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

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

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

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

(2)從宕機規(guī)模的角度

我行的TiDB數(shù)據(jù)庫集群可容忍單機級、Rack級、數(shù)據(jù)中心級的故障，從而實現(xiàn)高可用。

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

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

任何一個數(shù)據(jù)中心發(fā)生故障，根據(jù)Raft協(xié)議大多數(shù)原則，剩余的兩個數(shù)據(jù)中心仍可對外提供服務。

2、存儲方案

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

數(shù)據(jù)庫日志分為TiDB日志、TiKV日志、PD日志，分別存儲在各自的實例節(jié)點上。

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

3、監(jiān)控與告警

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

(1)數(shù)據(jù)庫運行狀況實時監(jiān)控

這部分是最多、最重要的監(jiān)控內容。

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

監(jiān)控與告警總體架構如下圖所示： 

集群的TiDB/PD/TiKV組件分別向Prometheus Pushgateway推送數(shù)據(jù)，統(tǒng)一供 Prometheus server抓取;通過定制Grafana展示模板對Prometheus中的監(jiān)控數(shù)據(jù)進行展示。

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

(2)旁路監(jiān)控

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

(3)mocha監(jiān)控

監(jiān)控數(shù)據(jù)庫級別的運行狀況。

4、備份與恢復

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

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

(1)備份

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

備份策略：

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

每天實時備份增量數(shù)據(jù)。

備份特性：

支持按表恢復數(shù)據(jù);

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

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

備份示意圖如下： 

(2)恢復

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

5、日常運維方案

(1)產品升級策略

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

(2)集群日常巡檢

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

(3)集群擴容縮容方案

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

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

6、災備方案

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

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

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

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

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

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

4)將業(yè)務數(shù)據(jù)庫連接切換到從集群;

5)啟動主集群;

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

7、應用適配和優(yōu)化

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

TiDB 優(yōu)化器會根據(jù)統(tǒng)計信息來選擇最優(yōu)的SQL執(zhí)行計劃。

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

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

當數(shù)據(jù)庫中的對象需要優(yōu)化時，我們會綜合分析統(tǒng)計信息、執(zhí)行計劃，然后給出優(yōu)化方案。

(2)性能檢查和判斷

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

五、結語

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