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

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

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

一、設(shè)計(jì)目標(biāo)

我們?cè)谠O(shè)計(jì)TiDB分布式數(shù)據(jù)庫集群時(shí)，需要考慮多方面的需求，因此，制定了以下內(nèi)容，作為項(xiàng)目的設(shè)計(jì)目標(biāo)。 

二、業(yè)務(wù)要求

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

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

2、設(shè)備需求估算

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

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

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

三、整體架構(gòu)設(shè)計(jì)

我們的TiDB集群為兩地三中心多活架構(gòu)，并且設(shè)計(jì)了主從集群的災(zāi)備部署，本章節(jié)我們將詳細(xì)介紹架構(gòu)設(shè)計(jì)。

1、邏輯架構(gòu)設(shè)計(jì) 

架構(gòu)說明：

(1)整個(gè)集群采用主從結(jié)構(gòu)，主集群作為生產(chǎn)集群，承擔(dān)日常生產(chǎn)服務(wù)，從集群通過 binlog 異步同步主集群數(shù)據(jù)，作為災(zāi)備集群使用。

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

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

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

(1)IDC1、IDC2各配置兩個(gè)機(jī)柜，均用于部署生產(chǎn)主集群，IDC3一個(gè)機(jī)柜用于部署生產(chǎn)主集群，另一個(gè)機(jī)柜用于部署災(zāi)備從集群。

(2)每個(gè)IDC配置兩臺(tái)萬兆交換機(jī)(以主備模式部署)，主集群各臺(tái)機(jī)器內(nèi)部通信、從集群各臺(tái)機(jī)器內(nèi)部通信、主從集群之間都是使用萬兆網(wǎng)絡(luò)。

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

四、運(yùn)維方案設(shè)計(jì)

1、高可用方案

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

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

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

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

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

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

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

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

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

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

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

2、存儲(chǔ)方案

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

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

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

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

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

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

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

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

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

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

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

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

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

(3)mocha監(jiān)控

監(jiān)控?cái)?shù)據(jù)庫級(jí)別的運(yùn)行狀況。

4、備份與恢復(fù)

雖然TiDB集群的多副本策略可以避免故障發(fā)生時(shí)數(shù)據(jù)的丟失，但我們?nèi)匀恍枰贫ㄍ晟频臄?shù)據(jù)備份與恢復(fù)策略，進(jìn)一步加強(qiáng)數(shù)據(jù)安全性。

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

(1)備份

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

備份策略：

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

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

備份特性：

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

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

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

備份示意圖如下： 

(2)恢復(fù)

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

5、日常運(yùn)維方案

(1)產(chǎn)品升級(jí)策略

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

(2)集群日常巡檢

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

(3)集群擴(kuò)容縮容方案

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

需要特別說明的是擴(kuò)容PD時(shí)，需滾動(dòng)升級(jí)集群，升級(jí)過程中會(huì)導(dǎo)致TiDB連接斷開，影響業(yè)務(wù)，待升級(jí)完成即可恢復(fù)，因此，最好選擇業(yè)務(wù)量少的時(shí)段進(jìn)行。

6、災(zāi)備方案

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

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

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

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

2)關(guān)閉主集群 Drainer, 停止主從同步;

3)關(guān)閉主集群，記錄當(dāng)前時(shí)間戳;

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

5)啟動(dòng)主集群;

6)從集群運(yùn)行 Drainer，向主機(jī)群同步。

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

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

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

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

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

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

(2)性能檢查和判斷

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

五、結(jié)語

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