TiDB 是 PingCAP 公司自主設(shè)計、研發(fā)的開源分布式關(guān)系型數(shù)據(jù)庫，是一款同時支持在線事務(wù)處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數(shù)據(jù)庫、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。目標是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數(shù)據(jù)規(guī)模較大等各種應(yīng)用場景。

創(chuàng)新互聯(lián)于2013年開始，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目網(wǎng)站制作、成都網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元崇信做網(wǎng)站,已為上家服務(wù),為崇信各地企業(yè)和個人服務(wù),聯(lián)系電話:18980820575

UCloud 于今年 8 月 將 TiDB 公有云化并推出 UCloud TiDB Service，當前使用的 TiDB 版本為 3.0.5 。UCloud TiDB Service 相比裸機部署性能并無損耗，提供跨可用區(qū)高可用，對監(jiān)控和 Binlog 等做了改造增強，使用戶可獲得一鍵創(chuàng)建、按需付費、靈活擴縮容的 TiDB 服務(wù)。

UCloud TiDB Service

為什么叫 UCloud TiDB Service？這里強調(diào) Service 是因為從公有云用戶的角度來看，TiDB 運行在公有云平臺上，其實是以服務(wù)的形式呈現(xiàn)而不是一個物理資源。UCloud TiDB Service 是一個支持原生 MySQL 協(xié)議的，高性能、跨可用區(qū)高可用、高可擴展的，面向 Serverless 的分布式數(shù)據(jù)庫服務(wù)。

兼容原生 MySQL 協(xié)議

大多數(shù)情況下，無需修改代碼即可從 MySQL 輕松遷移至 TiDB，分庫分表后的 MySQL 集群亦可通過 TiDB 工具進行實時遷移。

跨可用區(qū)高可用

TiDB 本身雖具備一定高可用性，但一般用戶沒有跨可用區(qū)部署條件。UCloud TiDB Service 的所有組件都是跨可用區(qū)部署。TiDB 所有模塊的多實例部署能力，結(jié)合 UCloud 跨可用區(qū)部署能力，UCloud TiDB Service 可抵御可用區(qū)級故障。

動態(tài)擴展

TiDB 無論是計算節(jié)點還是存儲節(jié)點都可以實現(xiàn)水平擴展，通過簡單地增加新節(jié)點即可按需擴展吞吐或存儲，輕松應(yīng)對高并發(fā)、海量數(shù)據(jù)場景。

Serverless

Serverless 的產(chǎn)品形態(tài)讓用戶更加簡單快捷的使用到 TiDB，無需關(guān)心底層的物理資源，也無需關(guān)心底層分布部署的細節(jié)。

按需付費，接入成本低

無需指定 CPU、內(nèi)存、硬盤等資源，用戶只需按實際使用的硬盤和存儲量進行付費，節(jié)省了前期的硬件成本投入。

性能對比

我們做了一個測試，在相同物理配置（Intel Xeon E5-2620 v4, DDR4_16GB_2400MHz x12, U.2_NVMe_3.2TB x2 ）和相同軟件部署（TiDB x3, TiKV x3, PD x3 ）情況下，測試條件為 sysbench 512 threads, 32 tables, 1000 萬行。在裸機上部署 TiDB 和 UCloud TiDB Service 的性能對比如下表所示：

結(jié)果表明各項指標基本一致，UCloud TiDB Service 和裸機部署相比較，并沒有帶來性能損耗，有些指標表現(xiàn)略好。而在這背后，UCloud 公有云后臺做了哪些事情呢？

打造分布式數(shù)據(jù)庫 PaaS 平臺

UCloud 內(nèi)部做了一個分布式數(shù)據(jù)庫的 PaaS 平臺（如上圖），在管理功能上，左邊第一部分有物理機的資源管理，包括每次創(chuàng)建實例的時候資源分配以及實例刪除以后資源回收等等操作。第二部分是集群部署，一個創(chuàng)建過程先選取合適的物理機，檢測上面的資源是否滿足，滿足以后分配特定的一些資源出來，然后再執(zhí)行相應(yīng)的創(chuàng)建工作，這里面要創(chuàng)建 TiDB 集群，相應(yīng)的監(jiān)控、LB 層，以及部署在公有云上都是運行在用戶 VPC 里面，需要做 VPC 網(wǎng)絡(luò)初使化等工作。第三部分是集群維護，比如某臺物理機有異常，就要把所有服務(wù)遷移到其他的節(jié)點面去。這里面主要涉及的是遷移、擴展、縮容這些工作。

右邊是監(jiān)控告警，主要用于對一些異常情況的及時通知告警管理；還有運營分析這塊是 UCloud 數(shù)據(jù)庫運營方面的管理。備份管理負責數(shù)據(jù)庫的備份與恢復(fù)，用戶可以設(shè)置比較詳細的備份策略，比如何時備份如何備份等。

原生協(xié)議是 MySQL 本來的數(shù)據(jù)流，在這里我們加了一層負載均衡，主要有兩個目的：一個是把 IP 地址統(tǒng)一成一個，用戶不需要管理 IP 地址的切換；另外針對公有云服務(wù)傳輸做一些控制，主要是帳號和系統(tǒng)方面的控制。

跨可用區(qū)部署實現(xiàn)高可用

TiDB 整體是由分布式 SQL 層（TiDB）、分布式 KV 存儲引擎（TiKV）以及管理整個集群的 PD 模塊組成。如圖我們將 TiDB 的 所有組件進行跨可用區(qū)部署，并且提供單一高可用接入地址，單一地址的好處是用戶不需要關(guān)注多地址，也不需要做地址之間的切換，另外一個好處是整個容災(zāi)過程對業(yè)務(wù)完全透明，比如要增加 / 縮掉一個 TiDB 節(jié)點，或者要遷移到另外一臺機器時。有了統(tǒng)一地址虛 IP 之后，業(yè)務(wù)就完全不用考慮地址，所有的操作對用戶完全透明。

對監(jiān)控的改造

TiDB 本身使用了 Prometheus 作為監(jiān)控和性能指標信息收集方案、Grafana 作為可視化組件進行展示、Alertmanager 用于實現(xiàn)報警機制，但是都是單點部署， 并不具備容災(zāi)能力。我們將這三個模塊都進行了高可用改造。大家知道，Grafana 本身是沒辦法使用 TiDB 存儲元數(shù)據(jù)的，我們對 Grafana 源碼進行了修改，改寫了大量 Multi-schema 語句，并且去掉了將字段改小的操作，從而支持了 Grafana 使用 TiDB 存儲元數(shù)據(jù)。

如圖是一個用戶業(yè)務(wù)監(jiān)控系統(tǒng)，左邊有一個 LB，兩個 Grafana 節(jié)點，我們通過 LB 連到 Prometheus，從而實現(xiàn)遠程高可用。

對 Binlog 的改造

有這樣一個用戶場景，將 TiDB 數(shù)據(jù)導(dǎo)入已有的大數(shù)據(jù)集群作數(shù)據(jù)分析， 需要輸出到 Kafka 的日志格式為 json， 以便 Flink 消費解析。由于 Binlog 是 PB 格式，目前提供的 driver 只支持 txt, mysql。

經(jīng)過我們對 Binlogdriver 的改造之后，Binlog 支持輸出 Json 格式、支持將 Json 格式日志寫入 Kafka。

品質(zhì)改善和 Bug 修復(fù)

在打造 TiDB 服務(wù)期間，我們也相繼發(fā)現(xiàn)解決了原生 TiDB 的一些小問題，從細節(jié)上提升產(chǎn)品品質(zhì)。其中很多在官方后續(xù)的新版本中也已經(jīng)陸續(xù)得到了改善和解決，例如：

Drainer 輸出 db.table 格式的語句 (fixed in 3.0)；
TiDB 升級到 2.1 以后時區(qū)變化；
Syncer 在 retry 階段不處理 SIGTERM (fixed)；
Syncer can’t decode set datatype (fixed)；
Drainer 只寫一個 partition 導(dǎo)致數(shù)據(jù)傾斜，我們可以啟動多個 drainer， 每個 drainer 寫一個 DB；
Raft store 單線程瓶頸 （fixed in 3.0）；
Binlog 開啟 / 關(guān)閉 10 分鐘內(nèi) DDL 慢 （fixed in 2.1.14）。
還有一些由于跟 MySQL 原生協(xié)議不同而導(dǎo)致語句理解上產(chǎn)生的問題，比如 ID 分段自增、GC 時間導(dǎo)致連接中斷、事務(wù)條數(shù)限制（單條 KV entry 不超過 6MB、總條數(shù)不超過 30w、總大小不超過 100MB）、失敗自動重試等。這些問題經(jīng)過 UCloud 內(nèi)部的長時間打磨和積累，已經(jīng)達到了一個相對成熟和穩(wěn)定的形態(tài)。

TiDB 管理模塊

產(chǎn)品控制臺向用戶開放了 TiDB 的管理模塊，分為四個部分：備份管理、恢復(fù)任務(wù)、用戶管理、Binlog 同步。具體如下：

備份管理：創(chuàng)建 TiDB 實例時可以選擇是否開啟自動備份策略，備份策略包括備份時間、自動備份保留份數(shù)以及自動備份周期。除了自動備份，TiDB 還提供手動備份選擇

恢復(fù)任務(wù)：TiDB 當前支持從備份文件恢復(fù)至一個新的 TiDB 實例，用戶需要提前準備好新實例，恢復(fù)工作會覆蓋新實例數(shù)據(jù)。

用戶管理：TiDB 提供給用戶相應(yīng)的權(quán)限管理，包括新增用戶并初始化權(quán)限 、調(diào)整用戶權(quán)限、刪除非 root 用戶等。

Binlog 同步：可將 TiDB 的增量數(shù)據(jù)實時同步到其他存儲中，當前支持 MySQL，TiDB 作為目標存儲。

總結(jié)

可以說 TiDB 是為云而生的數(shù)據(jù)庫，UCloud TiDB Service 在保證 TiDB 性能沒有損耗的前提下， 將 TiDB 以服務(wù)的形式提供給用戶， 降低了用戶使用門檻， 簡化了用戶管理， 提高了容災(zāi)能力。未來，UCloud 將繼續(xù)與 PingCAP 官方深度合作，致力于為云上數(shù)據(jù)庫創(chuàng)造更多可能性。