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

1、 分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設(shè)計與實踐 目 錄 TOC o 1-3 h z u HYPERLINK l _Toc66551356 分布式數(shù)據(jù)庫 TiDB 在商業(yè)銀行的設(shè)計與實踐 PAGEREF _Toc66551356 h 1 HYPERLINK l _Toc66551357 一、設(shè)計目標(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è)計 PAGEREF _Toc66551361 h 5 HYPERLINK l _Toc66551362 1、邏輯架構(gòu)設(shè)計 PAGEREF _Toc66551362 h 5 HYPERLINK l _Toc66551363 2、物理位置規(guī)劃 PAGEREF _Toc66551363 h 6 HYPERLINK l _Toc66551364 四、運維方案設(shè)計 PAGEREF _Toc66551364 h 6 HYPERLINK l _

3、Toc66551365 1、高可用方案 PAGEREF _Toc66551365 h 6 HYPERLINK l _Toc66551366 2、存儲方案 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、日常運維方案 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ù)庫，整個產(chǎn)品的結(jié)構(gòu)非常清晰，計算跟數(shù)據(jù)存儲層分離，這是現(xiàn)代大部分分布式數(shù)據(jù)處理系統(tǒng)通常都會傾向和考慮采用的架構(gòu)：最底層“TiKV” 層

5、，是分布式數(shù)據(jù)庫的存儲引擎層，不只是用來存取和管理數(shù)據(jù)，同時也負(fù)責(zé)執(zhí)行對數(shù)據(jù)的并行運算。在TiKV之上即是“TiDB”層，為分布式數(shù)據(jù)庫的SQL引擎層，處理關(guān)系型數(shù)據(jù)庫諸如連接會話管理、權(quán)限控制、SQL解析、優(yōu)化器優(yōu)化、執(zhí)行器等核心功能。此外，還有一個承擔(dān)集群大腦角色的集中調(diào)度器，叫做“PD”，同時整體架構(gòu)中還會融合一些運維管理工具，包括部署、調(diào)度、監(jiān)控、備份等。TiDB可實現(xiàn)自動水平伸縮，強一致性的分布式事務(wù)，基于 Raft 算法的多副本復(fù)制等重要 NewSQL 特性，并且也滿足我行對于高可用、高性能、高可擴展性的要求。TiDB部署簡單，在線彈性擴容不影響業(yè)務(wù)，異地多活及自動故障恢復(fù)保障數(shù)據(jù)

6、安全，同時兼容 MySQL 協(xié)議，使遷移使用成本降到極低。這篇文章中，我們將詳細(xì)介紹TiDB在我行的設(shè)計與實踐。一、設(shè)計目標(biāo)我們在設(shè)計TiDB分布式數(shù)據(jù)庫集群時，需要考慮多方面的需求，因此，制定了以下內(nèi)容，作為項目的設(shè)計目標(biāo)。二、業(yè)務(wù)要求1、業(yè)務(wù)數(shù)據(jù)估算我們設(shè)計的TiDB分布式數(shù)據(jù)庫集群在一期計劃承載一套業(yè)務(wù)系統(tǒng)，該系統(tǒng)為我行核心支付交易系統(tǒng)。在采購設(shè)備之前，我們根據(jù)業(yè)務(wù)的發(fā)展規(guī)模進行了合理估算，得出了預(yù)期日交易量、數(shù)據(jù)規(guī)模、數(shù)據(jù)增長率等信息。2、設(shè)備需求估算設(shè)備需求按照第一年的數(shù)據(jù)量和日交易量進行規(guī)劃，并綜合考慮了數(shù)據(jù)副本數(shù)和磁盤空間可用率，因此需要規(guī)劃足夠的冗余存儲容量。此外，TiDB集群

7、還需要中控機對集群進行統(tǒng)一管理、需要監(jiān)控機進行集群監(jiān)控、需要服務(wù)器進行數(shù)據(jù)備份，因此，還要考慮這些服務(wù)器的規(guī)劃。除了生產(chǎn)集群，我們還設(shè)計了從集群，作為異地災(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中控機監(jiān)控機備份服務(wù)器Kafka服務(wù)器從集群服務(wù)器三、整體架構(gòu)設(shè)計我們的TiDB集群為兩地三中心多活架構(gòu)，并且設(shè)計了主從集群的災(zāi)備部署，本章節(jié)我們將詳細(xì)介紹架構(gòu)設(shè)計。1、邏輯架構(gòu)設(shè)計架構(gòu)說明：（1

8、）整個集群采用主從結(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各配置兩個機柜，均用于部署生產(chǎn)主集群，IDC3一個機柜用于部署生產(chǎn)主集群，另一個機柜用于部署災(zāi)備從集群。（2）每個IDC配置兩臺萬兆交換機（以主備模式部署），主集群各臺機器內(nèi)部通信、從集群各臺機器內(nèi)部通信、主從集群之間都是使用萬兆網(wǎng)絡(luò)。（3）全局DNS下掛載三個IDC的負(fù)載均衡，各IDC

9、種負(fù)載均衡掛載各自中心內(nèi)部的TiDB服務(wù)器，以千兆網(wǎng)環(huán)境對外提供業(yè)務(wù)服務(wù)。四、運維方案設(shè)計1、高可用方案高可用是 TiDB 數(shù)據(jù)庫的特性之一，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集群的可用性。我行的TiDB生產(chǎn)集群，由生產(chǎn)中心、同城災(zāi)備中心、異地災(zāi)備中心共同實現(xiàn)兩地三中心多活高可用部署方案。下面，我們將從不同的維度來分析集群的高可用性。（1）從服務(wù)器角色的角度集群中的服務(wù)器有三個角色：TiDB、TiKV、PD，我們從這三個角色來分析集群的高可用性。TiDB 是無狀態(tài)的，以實例為單位通過前端的負(fù)載均衡設(shè)備對外提供服務(wù)。當(dāng)單個TiDB實例失效時，僅僅會影響當(dāng)前實例上

10、進行的會話，應(yīng)用服務(wù)出現(xiàn)單次請求失敗的情況，應(yīng)用重新連接至其他TiDB實例后即可繼續(xù)獲得服務(wù)，此時可以先摘除這個實例進行故障解決或者重新部署一個新的實例。TiKV 以集群方式部署，通過 Raft 協(xié)議保持多副本情況下的數(shù)據(jù)一致性，并通過 PD 進行數(shù)據(jù)層面的負(fù)載均衡調(diào)度。單個TiKV節(jié)點失效時，會影響這個節(jié)點上存儲的所有Region。對于 Region 中的Leader 結(jié)點，會中斷服務(wù)，等待其他TiKV上的Region重新選舉Leader，待Leader選出了可繼續(xù)對外提供服務(wù)；對于Region 中的Follower節(jié)點，不會影響服務(wù)。當(dāng)某個 TiKV 節(jié)點失效，并且在一段時間內(nèi)（默認(rèn) 30

11、 分鐘）無法恢復(fù)，PD 會將其上的數(shù)據(jù)遷移到其他的 TiKV 節(jié)點上。PD 同樣以集群方式部署，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性。單個實例失效時，如果不是leader，那么服務(wù)完全不受影響；如果是leader，那么PD集群會重新選出新的leader，自動恢復(fù)服務(wù)。（2）從宕機規(guī)模的角度我行的TiDB數(shù)據(jù)庫集群可容忍單機級、Rack級、數(shù)據(jù)中心級的故障，從而實現(xiàn)高可用。單機服務(wù)器故障，分為TiDB、TiKV、PD三個角色，參考上一小節(jié)的闡述。我們將集群所有服務(wù)器分散放置在各個Rack里，根據(jù)Raft協(xié)議大多數(shù)原則，單個Rack出現(xiàn)故障，不會影響集群對外提供服務(wù)。我行的架構(gòu)允許集群中兩個Rac

12、k同時出現(xiàn)故障。任何一個數(shù)據(jù)中心發(fā)生故障，根據(jù)Raft協(xié)議大多數(shù)原則，剩余的兩個數(shù)據(jù)中心仍可對外提供服務(wù)。2、存儲方案TiDB 集群數(shù)據(jù)庫集群的數(shù)據(jù)包括業(yè)務(wù)數(shù)據(jù)、數(shù)據(jù)庫日志、數(shù)據(jù)庫運行狀況數(shù)據(jù)，綜合考慮硬盤的容量、I/O讀寫速率等因素后，我們選用了SAS盤+SSD盤作為服務(wù)器硬盤存儲。需要注意的是，在規(guī)劃容量時，要考慮數(shù)據(jù)多副本的特點，從而規(guī)劃出足夠的存儲容量。數(shù)據(jù)庫日志分為TiDB日志、TiKV日志、PD日志，分別存儲在各自的實例節(jié)點上。數(shù)據(jù)庫運行狀況相關(guān)數(shù)據(jù)存放集群默認(rèn)庫里，也分散存儲在所有TiKV節(jié)點上，通過定期執(zhí)行analyze操作進行更新。3、監(jiān)控與告警我行的TiDB數(shù)據(jù)庫監(jiān)控分三個

13、模塊：數(shù)據(jù)庫運行狀況實時監(jiān)控、旁路監(jiān)控、mocha監(jiān)控，告警也分別由這三個模塊各自觸發(fā)。（1）數(shù)據(jù)庫運行狀況實時監(jiān)控這部分是最多、最重要的監(jiān)控內(nèi)容。TiDB集群使用開源時序數(shù)據(jù)庫 Prometheus 作為監(jiān)控和性能指標(biāo)信息存儲方案，使用 Grafana 可視化組件對監(jiān)控數(shù)據(jù)進行展示。告警渠道有兩個，一個是我行自主研發(fā)的一體化監(jiān)控平臺，一個是AlertManager。監(jiān)控組件安裝在監(jiān)控服務(wù)器上，Prometheus產(chǎn)生的監(jiān)控數(shù)據(jù)也存儲在這里。監(jiān)控與告警總體架構(gòu)如下圖所示：集群的TiDB/PD/TiKV組件分別向Prometheus Pushgateway推送數(shù)據(jù)，統(tǒng)一供 Prometheus

14、server抓?。煌ㄟ^定制Grafana展示模板對Prometheus中的監(jiān)控數(shù)據(jù)進行展示。當(dāng)監(jiān)控的數(shù)值超過我們指定的閾值時，就會觸發(fā)告警，告警信息通過AlertManager或一體化監(jiān)控平臺，以郵件和短信的方式通知管理員。根據(jù)故障發(fā)生的嚴(yán)重程度，告警被劃分為3個級別：warning、critical、emergency，其中emergency級別最高，表示故障最嚴(yán)重。根據(jù)業(yè)務(wù)要求和信息系統(tǒng)安全性要求，我們分別定制了不同的告警策略。（2）旁路監(jiān)控旁路監(jiān)控是對prometheus監(jiān)控的補充，一方面檢測prometheus的模塊是否正常，另一方面也會直接監(jiān)控 TiDB 的關(guān)鍵服務(wù)工作狀態(tài)，針對異常

15、產(chǎn)生告警。下圖是旁路監(jiān)控示意圖：（3）mocha監(jiān)控監(jiān)控數(shù)據(jù)庫級別的運行狀況。4、備份與恢復(fù)雖然TiDB集群的多副本策略可以避免故障發(fā)生時數(shù)據(jù)的丟失，但我們?nèi)匀恍枰贫ㄍ晟频臄?shù)據(jù)備份與恢復(fù)策略，進一步加強數(shù)據(jù)安全性。通過全量備份工具（Mydumper）與增量備份組件（binlog），對 TiDB 集群數(shù)據(jù)庫的任意時間點的狀態(tài)進行保存；當(dāng)需要恢復(fù)數(shù)據(jù)到某一個時間點時，首先使用全量數(shù)據(jù)恢復(fù)工具（Loader）恢復(fù)該時間點之前的最后一個全量備份，確認(rèn)全量導(dǎo)入無誤后，使用增量恢復(fù)工具（Reparo）恢復(fù)PB文件形式的binlog 增量數(shù)據(jù)到所要求的恢復(fù)時間點。（1）備份所有的備份組件都安裝在備份服務(wù)器

16、上，我們編寫了自動備份腳本，全量備份和增量數(shù)據(jù)文件都先存儲在本地，再轉(zhuǎn)儲至磁帶上。備份策略：每周一次全備份，選在業(yè)務(wù)量少的夜間進行；每天實時備份增量數(shù)據(jù)。備份特性：支持按表恢復(fù)數(shù)據(jù)；TiDB 的備份數(shù)據(jù)可以恢復(fù)到 TiDB 集群或 MySQL（5.7.x）中；TiDB 增量備份是貫穿于數(shù)據(jù)庫整個生命周期的，它以PB文件的形式存在，PB文件由 Drainer 解析 binlog 生成。備份示意圖如下：（2）恢復(fù)任意一臺安裝有mysql實例的服務(wù)器均可用來恢復(fù)數(shù)據(jù)，也可將備份的生產(chǎn)數(shù)據(jù)經(jīng)過脫敏處理后用于測試環(huán)境的TiDB集群。5、日常運維方案（1）產(chǎn)品升級策略TiDB作為開源軟件，其產(chǎn)品迭代速度快

17、，常使用補丁式更新，一旦發(fā)現(xiàn)錯誤可馬上更新，這與銀行業(yè)要求的穩(wěn)定性存在一定差異，且不符合監(jiān)管要求的變更流程。因此，我們目前的升級策略是待其新發(fā)布的大版本穩(wěn)定后再安排變更升級，對于補丁式小版本，在不影響業(yè)務(wù)的情況下，暫緩升級。（2）集群日常巡檢除了24小時實時監(jiān)控外，我行要求每日對數(shù)據(jù)庫進行定時巡檢。這部分我們編寫了自動巡檢腳本，通過郵件方式推送數(shù)據(jù)庫運行狀態(tài)。（3）集群擴容縮容方案TiDB 集群可以在不影響線上服務(wù)的情況下動態(tài)進行擴容和縮容，實現(xiàn)在線靈活可擴展特性。擴容縮容也分為TiDB、TiKV、PD三種情況，具體操作在PingCAP官網(wǎng)都有清晰地描述，這里不再贅述。需要特別說明的是擴容PD

18、時，需滾動升級集群，升級過程中會導(dǎo)致TiDB連接斷開，影響業(yè)務(wù)，待升級完成即可恢復(fù)，因此，最好選擇業(yè)務(wù)量少的時段進行。6、災(zāi)備方案除了生產(chǎn)主集群，我行的TiDB集群還增加了從集群的設(shè)計，目的是為了實現(xiàn)異地災(zāi)備。因此，我們也制定了完善的主從集群災(zāi)備切換方案。下圖是一個簡單的主從集群部署示意圖，主從集群通過binlog進行數(shù)據(jù)同步：切換時，主從集群架構(gòu)不變，僅僅是主從同步數(shù)據(jù)流改變方向。切換流程如下：1）停業(yè)務(wù)，等待主從同步完成；2）關(guān)閉主集群 Drainer, 停止主從同步；3）關(guān)閉主集群，記錄當(dāng)前時間戳；4）將業(yè)務(wù)數(shù)據(jù)庫連接切換到從集群；5）啟動主集群；6）從集群運行 Drainer，向主機群同步。7、應(yīng)用適配和優(yōu)化（1）檢查和優(yōu)化庫/表/索引等內(nèi)部對象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 構(gòu)成，TiDB提供了EXPLAIN語句，可以查看SQL語句的執(zhí)行詳細(xì)信息。當(dāng)數(shù)據(jù)庫中的對象需要優(yōu)化時，我們會綜合分析