摘要: 本文為今年年初 PingCAP 商業(yè)產(chǎn)品團隊負責人劉寅在 TiDB DevCon2018 上分享的 《 TiDB 工具鏈和生態(tài)》實錄內容，詳細介紹了 TiDB 的周邊工具以及生態(tài)系統(tǒng)。

本文為今年年初 PingCAP 商業(yè)產(chǎn)品團隊負責人劉寅在 TiDB DevCon2018 上分享的 《 TiDB 工具鏈和生態(tài)》實錄內容晌涕，詳細介紹了 TiDB 的周邊工具以及生態(tài)系統(tǒng)固蛾。

大家下午好贯涎，我叫劉寅淮野。在 PingCAP 主要負責 TiDB 商業(yè)工具產(chǎn)品開發(fā)涡扼，也在做公司 SRE 方面的事情荧止。今天下午我分享的主題是介紹下 TiDB 的周邊工具以及生態(tài)系統(tǒng)屹电。

今天要講的內容主要包含這幾方面，首先是關于 TiDB 的部署跃巡，這是很多使用 TiDB 的用戶首先關心的事情危号。接下來會介紹 TiDB 的數(shù)據(jù)導入工具和數(shù)據(jù)遷移同步工具，以及管理配置素邪，數(shù)據(jù)可視化相關的工具外莲。

TiDB 的架構可能大家都比較清楚了。TiDB 是一個由若干模塊組成的分布式系統(tǒng)兔朦。這些模塊相互依賴協(xié)調工作組成一個集群偷线，整體構成了 TiDB 數(shù)據(jù)庫。這樣一個架構烘绽，對于用戶進行部署和運維淋昭，其復雜程度相對單機數(shù)據(jù)庫比如? MySQL 來說不那么容易的事情。那讓我們來看看如何快速部署一套 TiDB 集群實例安接。最近我們公開了一個項目pingcap/tidb-docker-compose翔忽，這令我們在一個本地的開發(fā)和測試環(huán)境上跑一套 TiDB 變得非常簡單英融。只需要用一個命令docker-compose up就能快速啟動起來。docker-compose 是 Docker 生態(tài)中的一個非常便利的工具歇式，它可以在本機方便的把 TiDB 的各個組件驶悟，包括它的監(jiān)控，可視化工具材失，全部整合在一個 yaml 文件來描述痕鳍，非常的方便。不僅可以通過我們官方 docker image 鏡像啟動龙巨，也可以支持從本地的 binary 啟動笼呆。比如當我本機編譯了一個特殊版本的 binary，我就可以直接構建本地鏡像來啟動旨别，甚至還可以支持現(xiàn)場編譯源碼來啟動诗赌。所以這對于我們自己開發(fā)和測試也是非常方便的。另外我們也做了一個很簡化的配置文件秸弛，比如我不希望默認跑 3 個 TiKV铭若，我想啟 5 個或者更多，簡單的改下配置就可以搞定递览。

對于生產(chǎn)環(huán)境的部署和運維叼屠，往往面對的是一個成規(guī)模的集群，docker-compose 的部署方式就不夠了绞铃。我們建議采用提供的

Ansible 部署方式镜雨。用戶首先在一個 Inventory 文件中描述和編排所需的 TiDB 集群拓撲，然后執(zhí)行我們提供的

ansible-playbook 腳本憎兽，就可以快速部署和運維一個生產(chǎn)環(huán)境下的 TiDB 集群冷离。我們現(xiàn)在很多的線上用戶，也是用了這樣的部署方式纯命。

TiDB Ansible 不僅實現(xiàn)在裸機上部署集群，同時也支持 Cloud 的部署方式痹栖。比如說用 Ansible 提供的組件亿汞，我們可以基于

AWS / Azure / GCP 上一鍵創(chuàng)建 TiDB

的集群，而將來也會支持國內的公有云平臺揪阿。其次可以根據(jù)用戶需求疗我，定制集群的拓撲。這個比較細南捂，也會包含 TiDB 的一些周邊工具的部署吴裤，比如說

TiDB Binlog 組件。第三溺健，它提供一個配置管理的功能麦牺，包括 TiDB、TiKV

很多的參數(shù)配置。我們也集成進去剖膳，可以在一個地方統(tǒng)一管理整個集群的配置魏颓。除此之外，我們對運維操作的執(zhí)行腳本做了一系列的優(yōu)化吱晒。這樣對于在部署一個規(guī)模龐大的集群會變得及其方便甸饱。另外這里順便還要提一下，我們在

Ansible 部署過程中仑濒，我們會對硬件和系統(tǒng)環(huán)境做一個嚴格的檢查叹话。可能有些用戶出于測試的目的墩瞳，使用較低速的機械硬盤渣刷，而達不到跑 TiDB

的最低要求。所以這里矗烛，我們會有限定要求辅柴，會在安裝過程中交互提示出來。

TiDB

作為一個可以彈性水平擴展的分布式數(shù)據(jù)庫瞭吃，天生為云而設計碌嘀，從初期我們就和容器走的非常近。容器的優(yōu)勢歪架，相信大家都非常了解股冗。首先，它提供了一致化的環(huán)境和蚪，用戶不需要去適應各種不同的系統(tǒng)環(huán)境止状，而分別構建運行時

Binary。另外容器的啟動運行非常方便攒霹，可以很快速的在開發(fā)環(huán)境運行或者生產(chǎn)環(huán)境部署怯疤。另外容器提供了資源隔離的特性，通過 Namespace 和

CGroups 這些現(xiàn)代操作系統(tǒng)提供的能力催束，來實現(xiàn)容器內部和外部的資源隔離和限制集峦。

說到容器就不得不提容器編排，TiDB 在與 K8s 的整合方面我們做了非常多的事情抠刺。比如在 K8s 之上實現(xiàn)對 TiDB

集群的自動化管理塔淤，快速部署、擴縮容速妖、以及故障的自動愈合高蜂。同時更好的支持云平臺下的多租戶管理，通過限制單個租戶的資源的使用罕容，利用容器完成隔離备恤。來保證租戶之間不會相互影響稿饰。不至于說一個用戶執(zhí)行高負載的查詢或者寫入，對同一臺宿主機上的其他用戶實例造成影響烘跺。然而

TiDB 存儲本身是有狀態(tài)的湘纵，在 K8s 上部署的時候，如何管理好有狀態(tài)的服務滤淳，并且保證存儲的 iops

和延遲方面苛刻的要求梧喷，同時還要保證服務的高可用性就成為一個難題。

如果采用 K8s 提供的 native 存儲解決方案脖咐，外掛

PV铺敌，也就是掛網(wǎng)絡存儲。但是這樣對于數(shù)據(jù)庫系統(tǒng)來說屁擅，尤其是大量的隨機讀和順序寫的場景下偿凭，網(wǎng)絡盤的性能是達不到要求的。所以說從最開始我們設計

TiDB 上云解決方案派歌，其實主要就是探索 K8s 的本地 PV 解決方案弯囊。當然現(xiàn)在 K8s 1.9 已經(jīng)開始對 Local PV

有一定支持，而我們在 1.7 的時候就實現(xiàn)了一個 Local Storage Manager胶果。我們現(xiàn)在做的一些工作匾嘱，也逐漸在和社區(qū) K8s

主版本進行整合。另外 TiDB

本身是一個復雜集群早抠，除了存儲還有網(wǎng)絡霎烙，以及周邊工具的管理都需要考慮。為了實現(xiàn)將專業(yè)領域的運維管理變的更加自動化蕊连，我們造了 TiDB

Operator悬垃。Operator 這個 pattern 其實是最初借鑒 CoreOS 的 Etcd Operator。TiDB

Operator 就是降低 TiDB 部署和運維的復雜度甘苍，實現(xiàn)自動化的擴縮容和故障轉移尝蠕。同時 Operator 在 K8s 上同時管理多套

TiDB 集群，像在騰訊云和 UCloud 兩個公有云上羊赵，就是用這種方式來實現(xiàn)多租戶統(tǒng)一化管理趟佃。我們實現(xiàn)的 Local PV

管理機制，實質上是對集群中所有本地磁盤的統(tǒng)一管理昧捷，并賦予他們生命周期，從而作為 K8s 中的一類資源參與調度罐寨。同時新版本 K8s

的趨勢上靡挥，在往云上的操作系統(tǒng)方向上發(fā)展，自身的資源以及 API 變的更加開放鸯绿。我們不需要去改動 K8s

本身的代碼跋破，而是去做更好的擴展簸淀，來實現(xiàn)滿足自己的調度功能。比如說我們利用 K8s

親和性的特點毒返，讓同種類型的服務運行在同一臺物理機上租幕，更充分的利用硬件資源。再比如說 PD 和 TiKV 這兩種服務拧簸，你不能在一起混部使用同一塊

SSD劲绪，否則 IO 會相互影響。所以我們利用反親和的特性盆赤，讓 PD 和 TiKV 調度的時候盡量分開贾富。另外再舉一個調度的例子，TiDB

集群本身是支持區(qū)分節(jié)點的地域屬性的牺六，PD 根據(jù)地域屬性來實現(xiàn)數(shù)據(jù)層面的調度颤枪，并且盡量保證同一份數(shù)據(jù)的多個副本盡可能按地域分散開。那么 K8s

部署 TiDB 節(jié)點的時候淑际，也需要考慮地域特征來進行調度畏纲。比如按照跨 Region、跨可用區(qū)將一個集群的節(jié)點分散部署春缕，并且把地域的信息傳遞給

TiKV 和 PD盗胀，使數(shù)據(jù)副本盡量分散。而這個知識本身 K8s 是不具備的淡溯，我們需要擴展 K8s 的調度器把經(jīng)驗和原則傳遞進去读整。

Operator包含一些 TiDB 擴展的 Controller 和 Scheduler，但還不夠咱娶，我們需要在上面包裝一層米间，以暴露出來統(tǒng)一的運維和管理接口，這就是 Cloud Manager膘侮。Cloud Manager 對外暴露標準化的接口屈糊，用于和云平臺的前端控制臺對接，這樣就通過前臺可以完成 K8s 以及 TiDB 集群的相關資源的綜合管理琼了。

DBaaS 結構圖可以看到 Cloud TiDB 的分層架構逻锐。最下層是容器云，中間一層是 K8s 自身的服務管理和 API

Server雕薪。我們在此基礎上進行擴展昧诱，實現(xiàn)各種 Controller 和調度器，自己本地存儲管理 Volume Manager所袁，最終通過

Cloud Manager 提供的 RESTful API 進行暴露盏档。可以很容易接一個前端的 Dashboard燥爷，或者直接使用 CLI

命令行工具蜈亩，完成 TiDB 集群實例的統(tǒng)一化管理懦窘。

這個圖就是前面講的一些細節(jié)。這里面可以看到稚配，左半邊是 Kube 本身的組件畅涂，右側是我們的擴展出來組件，另外道川，我們也自己定義了一些 TiDB

的資源類型放在 CDR 里面午衰。比如說 TiDB Cluster，在這個資源對象上可以描述要啟動多少個 TiKV愤惰，多少個 TiDB苇经。另外還有

TiDB Set / TiKV Set / PD Set 等一系列對象，來分別描述某個服務的配置宦言。

這是在騰訊云上面的一個截圖扇单，

這是UCloud的截圖

現(xiàn)在這兩個產(chǎn)品都在公測，有興趣的同學可以關注一下奠旺。

此外蜘澜，我們提供了 Operator Chart 的安裝方式，使用 Helm 工具可以一鍵通過 Operator 拉起來一套 TiDB 實例响疚。

這種方式在 K8s 上就更像是一個 RPM 包的方式部署服務鄙信，并且管理服務之間依賴。只需要一行命令忿晕，就可以獲得到官方的 Cloud

TiDB 的核心組件装诡。如果你有一個 K8s 集群，或者你在使用一個公有云提供的 K8s 集群践盼，用上面的命令鸦采，就可以快速運行 TiDB

Operator 和 TiDB 集群。

這是一個配置的例子咕幻，打開 charts 壓縮包可以找到對應的配置 yaml 文件渔伯。

我們對每一行的配置做了詳細的注釋。比如可以設定一些參數(shù)：像副本數(shù)肄程、CPU 內存使用限制锣吼、TiDB 起多少個、TiKV 起多少個蓝厌，等等玄叠。

部署工具就先介紹這么多。下一部分拓提，我們開始介紹一下 TiDB 周邊的工具诸典，其實這里面有一些大家已經(jīng)接觸和使用過了。

首先是Syncer崎苗，這個小工具在很多生產(chǎn)環(huán)境上已經(jīng)用起來了狐粱。它是一個 MySQL 到 TiDB 間的實時同步工具。原理很簡單胆数，就是把自己偽裝成一個 MySQL 的 Slave 庫肌蜻，從上游 MySQL 里面把 binlog 實時 dump 出來，并且還原成 SQL 到下游（TiDB）回放必尼。

這里我們支持簡單的規(guī)則過濾蒋搜，也支持分庫分表的合并。我們也可以同時跑多個 Syncer 把多個上游 MySQL判莉，按庫同步到一個大的 TiDB

集群豆挽。Syncer 的主要一些特性，首先是要支持按? GTID 同步券盅。GTID 是什么帮哈？它是 MySQL 自身的 replication

機制提供的一種特性。MySQL 主從同步最早是以 binlog

pos（文件名+offset）來描述同步位置锰镀，但這個設計有明顯的缺陷娘侍，比如說這樣一個場景，最初是 1 個 Master 帶 2 個

Slaves泳炉，當 Master 掛了這時需要把一個 Slave 升級為 Master憾筏，另一個 Slave 從新 Master

繼續(xù)同步。但這樣就要保證花鹅，新的 Master 和舊 Master 的 binlog pos 能接續(xù)上氧腰，但是 MySQL 不同實例的 binlog

記錄方式是不同的，因此必須有一個全局唯一 ID 來和 binlog 對應上刨肃，這就是 GTID古拴。在 MySQL 5.6 之后 GTID

支持的就比較好了，生產(chǎn)環(huán)境大多是開啟了這種方式之景。Syncer 除了支持按 pos 同步斤富，也支持 GTID。Syncer 從公有云的 RDS

同步支持的都比較好锻狗，比如像阿里云满力、騰訊云我們測的也比較多，因為云平臺后端機器故障或者維護轻纪，主從切換比較頻繁油额，而且 Virtual IP

還保持不變對用戶無感知，所以假如 Syncer 不能很好支持 GTID

的話那切一次主從數(shù)據(jù)就會不一致了刻帚。第二是分庫分表合并潦嘶。不管上游庫是按庫拆，按表拆崇众，甚至混合拆分掂僵，Syncer

都能很好支持航厚，通過配置文件描述出來。另外還有同步性能的問題锰蓬，因為 binlog

是一個單向數(shù)據(jù)流幔睬，我們同步的時候如果是單線程來做雖然比較簡單，但性能可能很差芹扭。使用多線程麻顶，就必須區(qū)分對同一行數(shù)據(jù)操作的因果順序，沒有關聯(lián)關系的行可以并行執(zhí)行舱卡，有關聯(lián)的行只能順序執(zhí)行辅肾。對于

MySQL 每一個 binlog event 都是一個事務，他里面會包含對不同表轮锥，不同行的多次操作矫钓。所以 Syncer

會對事務進行拆分，然后并行執(zhí)行交胚。這樣的代價是 Syncer 不保證按上游的事務原子性來同步份汗，但最終一致性沒有問題。Syncer

也支持一些簡單的過濾規(guī)則蝴簇，可以選擇指定庫或者表同步杯活，也可以做排除。另外也支持一些簡單的表名映射變換熬词。

在一個公司初期旁钧，可能業(yè)務鋪的比較快，每塊業(yè)務用一個 MySQL 庫互拾，不同的業(yè)務之間數(shù)據(jù)是隔離的歪今。后來業(yè)務復雜了，可能 MySQL

要掛從庫了颜矿。從庫專門用于一些數(shù)據(jù)分析的場景寄猩，而不能影響主庫支撐線上的讀寫。隨著進一步的發(fā)展骑疆，數(shù)據(jù)分析可能要跨業(yè)務線田篇，那么跨庫進行統(tǒng)計查詢，比如

Join 和 Sub Query 這樣的操作基本上很難箍铭。這個場景下我們可以把一個 TiDB 集群作為所有線上 MySQL 的 Slave泊柬，而使用

Syncer 完成同步。數(shù)據(jù)分析團隊可以在 TiDB 中完成復雜的關聯(lián)查詢和分析诈火，這跟使用 MySQL 沒有什么區(qū)別兽赁。而且 Syncer

同步的實時性很高，使后端的分析可以做到非常的實時。

接下來我們介紹一下TiDB Binlog刀崖。TiDB Binlog 本質上不同于 MySQL惊科，這個要聲明一下，我們的 binlog 跟 MySQL 的 binlog 格式不同蒲跨，TiDB 采用一種自描述的 protobuf 格式的 binlog译断。而每個 TiDB Server，都會寫自己的 binlog或悲，一個事務就是一個 binlog event。然后通過一個叫作 Pump 的小程序堪唐，匯總寫入到 Kafka 集群巡语。Pump 直接寫本地就好了，為什么還要用 Kafka淮菠？這是考慮到 log 落本地盤會有單點故障的風險男公。所以采用 Kafka 或者一個分布式文件系統(tǒng)來解決這個問題。在下游有一個叫 Drainer 的組件來消費 Kafka 的數(shù)據(jù)合陵。Drainer 的職責是將 binlog 按照事務的順序還原成 SQL枢赔，同步到下游數(shù)據(jù)庫，比如 MySQL拥知，也可能是另外一個 TiDB 集群踏拜，還可以寫到文件流實現(xiàn)增量數(shù)據(jù)備份。

其實 Drainer 做的事情是有一些難度的低剔，因為 TiDB 不像

MySQL速梗，他是一個分布式系統(tǒng)，大家可以思考一下襟齿。首先姻锁，怎么保證事務的完整性，什么意思呢猜欺，因為 TiDB

的事務大家都知道是兩階段事務位隶。那么有可能事務提交成功，但是 binlog 沒有寫成功开皿；也有可能事務沒有寫成功但是 binlog

發(fā)出去了涧黄，這兩種情況都可能導致不一致。第二點副瀑，如何來還原分布式事務之間的因果順序弓熏。TiDB 事務是提交到 TiKV

上來執(zhí)行，每個事務又是兩階段糠睡，事務的順序號是由 PD 產(chǎn)生挽鞠，在同一個 TiDB 節(jié)點上可能會并發(fā)執(zhí)行多個事務，所以產(chǎn)生的 binlog 的事務

seq 不能保證單調遞增，那如何還原順序并實時輸出信认。第三點材义，網(wǎng)絡本身可能也是不可靠的，你可能寫到 TiDB

是前一個事務在前嫁赏，一個在后其掂。而在網(wǎng)絡傳輸?shù)倪^程中，順序可能變化潦蝇。在多機都在產(chǎn)生 binlog 的情況下款熬，最終落到 Drainer

的順序是錯亂的，那么如何進行順序還原攘乒。這個似乎跟 TCP 有點像贤牛，但又不太一樣。在 TiDB 里面事務的全局順序編號并不是連續(xù)遞增则酝，所以說當

Drainer 收到了一個 binlog 的時候殉簸，永遠不知道下一個 binlog

的事務編號是多少。至于實現(xiàn)沽讹，我們設計了一個比較復雜的動態(tài)窗口算法般卑。時間關系我就不展開講，大家有興趣可以思考一下爽雄。

在場景方面蝠检，我們用 TiDB Binlog 可以做很多事兒。比如在 TiDB 集群上再掛一個從集群盲链。也可以同步到 MySQL

做從庫蝇率。像一些客戶在線上初期開始使用 TiDB 可能會比較謹慎，開始把 TiDB 通過 Syncer 掛到 MySQL

的后面做一個從庫刽沾，跑一段時間驗證覺得沒有問題本慕，就可以把它調換一下。TiDB 成為主庫侧漓，用 binlog 去反向同步到

MySQL锅尘。再跑一段時間覺得 OK 了很安全，就可以把 MySQL 從庫摘下來布蔗，這樣就完成了一個灰度上線的過程藤违。此外我們還可以用 binlog

去同步其他異構數(shù)據(jù)庫，或者一些數(shù)據(jù)倉庫纵揍、或者分布式存儲產(chǎn)品顿乒。包括我們也在研發(fā)自己的 OLAP 的存儲引擎。將來都是通過 binlog

來完成數(shù)據(jù)實時同步泽谨。只需要給 Drainer 寫不同的 Adapter 插件即可璧榄。

TiDB Binlog 還可以用于數(shù)據(jù)增量備份特漩，可以找到最近的一個全量備份點，然后回放這段時間的

Binlog骨杂，就可以還原到任意時間點的數(shù)據(jù)狀態(tài)涂身。另外還有一些場景，比如說有的公司業(yè)務希望在 binlog 基礎上實現(xiàn)事件訂閱搓蚪。我們可以通過監(jiān)聽

binlog蛤售，當監(jiān)測到某個業(yè)務數(shù)據(jù)發(fā)生變化的時候往 Kafka 里面觸發(fā)一條消息，類似實現(xiàn) trigger 的功能妒潭。binlog

本身是描述成一種通用的 protobuf 格式悴能，也可以用來驅動流式計算引擎，來實現(xiàn)一些異步/流式分析需求杜耙。Binlog

的使用場景非常廣泛搜骡，可以在實際業(yè)務中靈活發(fā)揮。

另外介紹一個工具就是Lightning佑女， Lightning可能大家都沒有用到過，因為我們還在最后的測試和優(yōu)化階段谈竿，這是一個快速的 TiDB 導入工具团驱，之前我們提供的工具是 MyDumper，MyDumper 是 MySQL 通用的一個數(shù)據(jù)導出的工具空凸。它同時還有一個 MyLoader嚎花，我們在這個基礎上又做了一個 TiDB Loader，但這個東西本質上還是去執(zhí)行 SQL呀洲。就是說 MyDumper 輸出的數(shù)據(jù)文件是很多的 SQL 文本紊选。那么用 Loader 導入到 TiDB 這個過程中大家可能會覺得導數(shù)據(jù)比較慢。這是因為這種方式的數(shù)據(jù)導入道逗，TiKV 底層存儲的 region 要不斷的分裂和搬移兵罢，而且一般順序寫數(shù)據(jù)，表的主鍵往往是遞增的滓窍，這樣會導致寫入熱點卖词，不能同時把所有 TiKV 節(jié)點都調動起來，失去了分布式的優(yōu)勢吏夯。那么 Lightning 是怎么做的呢此蜈？首先我們會直接把輸入的數(shù)據(jù)格式繞過 SQL 解析器和優(yōu)化器直接轉換成有序的 KV 鍵值對，并分批進行處理噪生，根據(jù) PD 預先計算好新插入數(shù)據(jù)的 Region 分布裆赵，然后直接生成 SST 文件 Ingest 到 TiKV 中，非常接近物理數(shù)據(jù)導入跺嗽。我們在內部測試比之前的 Loader 方式要快 7 到 10 倍战授，1T 的數(shù)據(jù)將近在 5 個小時之內完成導入页藻，預計很快會跟大家見面。

MyDumper 格式的文件作為輸入陈醒，首先完成 SQL 到 KV 的轉換惕橙，它是由若干分布式 worker

來完成，多機并行執(zhí)行钉跷。同時繞過了優(yōu)化器弥鹦，生成連續(xù)的 KV 流，再通過一個專門的 Ingest Server 對 KV

進行全局排序爷辙。同時可以預計算 region彬坏，通過 PD 提前安排調度到哪個節(jié)點，所以整個的流程是非常高效的膝晾。

接下來介紹一個我們商業(yè)化工具栓始，叫作Wormhole。這個可以理解為是一個帶控制面板的 Syncer血当，但比 Syncer 強大幻赚。它支持多源多目的地的數(shù)據(jù)同步。而且本身也是分布式結構臊旭，具有高可用落恼、并行執(zhí)行的特點。另外它對于分庫分表支持的更好离熏，配置可視化佳谦。在同步前檢查也更為嚴格，比如說同步 MySQL滋戳，會提前檢查表結構和 TiDB 的兼容性钻蔑，是否開啟 row 模式的 binlog 等等，避免在運行過程中發(fā)現(xiàn)了再報異常奸鸯。另外 Wormhole 也支持一些簡單的 ETL 轉換規(guī)則咪笑，比如在同步過程中對表的某些字段進行簡單映射計算和 UDF。比如對于分庫分表的合并府喳，如果每張分表都有自己的自增主鍵蒲肋，合表之后插入 TiDB 就可能遇到主鍵沖突。Wormhole 通過配置就可以完成主鍵的合并钝满，也可以新增一個字段作為真正的主鍵兜粘，原表的主鍵保留名字，去掉唯一性約束弯蚜。

我截了一些界面的圖孔轴，可以看到整個數(shù)據(jù)同步過程中的進度，包括全量碎捺、增量的同步速度路鹰，以及我隨時可以把它暫停下來贷洲，或者進行一些特定的操作。對于多源/目的地這樣同步晋柱，像這個配置爷绘，我可以直接把數(shù)據(jù)庫里面的表結構全部讀出來速兔，用在界面上就可以決定同步表和數(shù)據(jù)庫以及字段映射關系冈欢。

接下來第三部分漾抬，說說 TiDB 的數(shù)據(jù)可視化。TiDB Vision 這個項目是開源的碑诉，我們會在 PD 提供的接口上彪腔，來實現(xiàn)數(shù)據(jù)可視化。

從圖中可以清楚的看到在不同節(jié)點上 region 的分布进栽，以及 region leader 的關系德挣。圖中環(huán)上的每一段，代表一個 TiKV

store快毛。每個 store 的每一個小格代表一個 region格嗅，綠色代表是 leader ，中間的這些線段在運行過程中是有動畫效果的唠帝，當

Leader 發(fā)生分裂吗浩，遷移，還有 Leader transfer没隘，都有不同顏色的動畫來表示。從而反映一個真實 PD

產(chǎn)生調度的過程禁荸，我們可以通過可視化很直觀的看到右蒲。另外就是熱點，這個圖里可能沒有體現(xiàn)赶熟，如果某一個 region

出現(xiàn)熱點瑰妄，在界面上就可以看到一些紅色的點。另外映砖，這個邊緣展示的是每個 PD 調度的一些網(wǎng)絡流量间坐，TiKV

的一些流量的信息我們也是實時的展示。如果某一個結點掛了邑退，在這個邊緣竹宋，它會有一定的顏色表示，比如說 TiKV 下線地技，熟悉 TiDB 的人知道蜈七，下線

TiKV 并不是立即就下線了，它會先變成下線中莫矗，然后變成 Tombstone 的狀態(tài)飒硅，這個在圖上都可以直觀的反映出來砂缩。這個工具非常簡單，就在

TiDB Vision 開源項目三娩，有興趣的同學庵芭，可以給 TiDB 做更多的皮膚。讓這個展示更 cool雀监，對業(yè)務監(jiān)控更有幫助双吆。

這個是我們在做的一個企業(yè)版的Dashboard，這個可能跟大家看到的 Grafana 還有現(xiàn)有開源的界面不太相同滔悉，這里截了一些局部的圖伊诵。大家可以看到，每個節(jié)點上面每個進程的狀態(tài)回官，包括節(jié)點運行時日志曹宴，和服務健康狀態(tài)。通過 Dashboard 就可以把整個的集群的拓撲和運行狀態(tài)歉提，全部展示出來笛坦。在這個界面它可以選擇去創(chuàng)建多少個 TiDB 多少個 TiKV 節(jié)點，并且選擇規(guī)格苔巨。左邊可以選擇升級的 TiDB 組件版本版扩，完成滾動升級這樣的事情。

最后說一下 TiDB 的監(jiān)控侄泽。監(jiān)控我們后臺用的Prometheus這個非常出名的項目礁芦，通過它來做存儲數(shù)據(jù)庫各個服務的 metrics。每個 TiDB悼尾、TiKV 組件都會把自己的狀態(tài)上報到 Prometheus（實際是 pull 的模式）柿扣，我們通過 Node Exporter 來采集每臺主機的狀態(tài)。而對于 K8s 集群闺魏，是通過 cAdvisor 進行收集未状，把 metrics 在 Prometheus 進行匯總。通過 Grafana 來做監(jiān)控和可視化析桥。我們配置好的 Grafana 面板點擊編輯按鈕司草，都可以看到對應的 Prometheus 查詢表達式，通過一種類似 SQL 的查詢語句泡仗，你就可以很方便的從 Prometheus 拉取監(jiān)控數(shù)據(jù)然后對接到自己的監(jiān)控平臺埋虹。 Alert manager 也是 Prometheus 生態(tài)里面的一個工具，它可以去接受 Prometheus 發(fā)出的報警事件沮焕，然后通過各種報警方式推送出來吨岭。日志方面我們也是用比較流行的 EFK 套件。在 K8s 集群中峦树，采集每個 Pod 的日志辣辫，存放到 ES 里面再通過 Kibana 進行展示旦事。

這個是監(jiān)控的幾個截圖，這個大家可能都比較熟悉了急灭。

最后簡單聊一下 TiDB 生態(tài)姐浮，因為 TiDB 最大的優(yōu)勢是兼容 MySQL 協(xié)議。所以不光是命令行工具葬馋，包括比如 MySQL 自己的

MySQL Workbench 這樣的工具卖鲤，還有大家用傳統(tǒng)的 Navicat 這樣的產(chǎn)品工具，還有就是一個老牌的 phpMyAdmin 這樣的

Web 管理工具畴嘶，都可以直接連到一個 TiDB 實例蛋逾。我們同時也在不斷的優(yōu)化 TiDB 兼容性，因為畢竟它跟 MySQL

有些區(qū)別窗悯。像這些工具区匣，它可能會去讀 MySQL 的一些系統(tǒng)表，我們會盡量會跟 MySQL 保持兼容蒋院。還有一些很方便的功能亏钩，比如把 schema

抓出來，繪制 ER 圖欺旧，其實我們也希望在 TiDB 上跑的很順暢姑丑。這樣習慣使用 MySQL 各種管理工具的用戶，可以非常平滑的切換到 TiDB辞友。

我今天介紹的內容主要就這些了栅哀，謝謝大家！