分布式數(shù)據(jù)庫TiDB在商業(yè)銀行的設(shè)計(jì)與實(shí)踐

1、 分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設(shè)計(jì)與實(shí)踐 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66551356 分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設(shè)計(jì)與實(shí)踐 PAGEREF _Toc66551356 h 1 HYPERLINK l _Toc66551357 一、設(shè)計(jì)目標(biāo) PAGEREF _Toc66551357 h 3 HYPERLINK l _Toc66551358 二、業(yè)務(wù)要求 PAGEREF _Toc66551358 h 4 HYPERLINK l _Toc66551359 1、業(yè)務(wù)數(shù)據(jù)估算 PAGEREF _Toc66551359 h 4 HYPERLIN

2、K l _Toc66551360 2、設(shè)備需求估算 PAGEREF _Toc66551360 h 4 HYPERLINK l _Toc66551361 三、整體架構(gòu)設(shè)計(jì) PAGEREF _Toc66551361 h 5 HYPERLINK l _Toc66551362 1、邏輯架構(gòu)設(shè)計(jì) PAGEREF _Toc66551362 h 5 HYPERLINK l _Toc66551363 2、物理位置規(guī)劃 PAGEREF _Toc66551363 h 6 HYPERLINK l _Toc66551364 四、運(yùn)維方案設(shè)計(jì) PAGEREF _Toc66551364 h 6 HYPERLINK l _

3、Toc66551365 1、高可用方案 PAGEREF _Toc66551365 h 6 HYPERLINK l _Toc66551366 2、存儲(chǔ)方案 PAGEREF _Toc66551366 h 7 HYPERLINK l _Toc66551367 3、監(jiān)控與告警 PAGEREF _Toc66551367 h 7 HYPERLINK l _Toc66551368 4、備份與恢復(fù) PAGEREF _Toc66551368 h 9 HYPERLINK l _Toc66551369 5、日常運(yùn)維方案 PAGEREF _Toc66551369 h 10 HYPERLINK l _Toc665513

4、70 6、災(zāi)備方案 PAGEREF _Toc66551370 h 11 HYPERLINK l _Toc66551371 7、應(yīng)用適配和優(yōu)化 PAGEREF _Toc66551371 h 12 HYPERLINK l _Toc66551372 五、結(jié)語 PAGEREF _Toc66551372 h 12關(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” 層

5、，是分布式數(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部署簡單，在線彈性擴(kuò)容不影響業(yè)務(wù)，異地多活及自動(dòng)故障恢復(fù)保障數(shù)據(jù)

6、安全，同時(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集群

7、還需要中控機(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ī)劃完畢，詳情如下：設(shè)備角色生產(chǎn)集群TiKV生產(chǎn)集群TiDB/PD中控機(jī)監(jiān)控機(jī)備份服務(wù)器Kafka服務(wù)器從集群服務(wù)器三、整體架構(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

8、）整個(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

9、種負(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í)例上

10、進(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

11、 分鐘）無法恢復(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è)Rac

12、k同時(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è)

13、模塊：數(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

14、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ǔ)充，一方面檢測prometheus的模塊是否正常，另一方面也會(huì)直接監(jiān)控 TiDB 的關(guān)鍵服務(wù)工作狀態(tài)，針對(duì)異常

15、產(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ù)器

16、上，我們編寫了自動(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)過脫敏處理后用于測試環(huán)境的TiDB集群。5、日常運(yùn)維方案（1）產(chǎn)品升級(jí)策略TiDB作為開源軟件，其產(chǎn)品迭代速度快

17、，常使用補(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

18、時(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è)簡單的主從集群部署示意圖，主從集群通過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ì)綜合分析