摘要：作為一個開源的分布式數(shù)據(jù)庫產(chǎn)品，具有多副本強(qiáng)一致性的同時能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對上層業(yè)務(wù)無感知。另外本身維護(hù)了數(shù)據(jù)多副本，這點(diǎn)和分布式文件系統(tǒng)的多副本是有重復(fù)的。

作者：鄧栓
來源：細(xì)說云計(jì)算

作為一款定位在 Cloud-native 的數(shù)據(jù)庫，現(xiàn)如今 TiDB 在云整合上已取得了階段性的進(jìn)展。日前 Cloud TiDB 產(chǎn)品在 UCloud 平臺正式開啟公測，TiDB 彈性伸縮的特性在 Cloud 提供的基礎(chǔ)設(shè)施支持下發(fā)揮的淋漓盡致。在感受云數(shù)據(jù)庫魅力的同時，讓我們來一探究竟，看一下 TiDB 與 Cloud 背后的技術(shù)秘密。

首先還是要先從 TiDB 的架構(gòu)說起，TiDB 和傳統(tǒng)的單機(jī)關(guān)系型數(shù)據(jù)庫有什么不同？相信長期以來一直關(guān)注 TiDB 的同學(xué)都比較了解了，但這里還是科普一下。TiDB 作為一個開源的分布式數(shù)據(jù)庫產(chǎn)品，具有多副本強(qiáng)一致性的同時能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對上層業(yè)務(wù)無感知。TiDB 的主體架構(gòu)包含三個模塊，對應(yīng) GitHub 上面 PingCAP 組織下的三個開源項(xiàng)目，TiDB / TiKV / PD：

TiDB 主要是負(fù)責(zé) SQL 的解析器和優(yōu)化器，它相當(dāng)于計(jì)算執(zhí)行層，同時也負(fù)責(zé)客戶端接入和交互；

TiKV 是一套分布式的 Key-Value 存儲引擎，它承擔(dān)整個數(shù)據(jù)庫的存儲層，數(shù)據(jù)的水平擴(kuò)展和多副本高可用特性都是在這一層實(shí)現(xiàn)；

PD 相當(dāng)于分布式數(shù)據(jù)庫的大腦，一方面負(fù)責(zé)收集和維護(hù)數(shù)據(jù)在各個 TiKV 節(jié)點(diǎn)的分布情況，另一方面 PD 承擔(dān)調(diào)度器的角色，根據(jù)數(shù)據(jù)分布狀況以及各個存儲節(jié)點(diǎn)的負(fù)載來采取合適的調(diào)度策略，維持整個系統(tǒng)的平衡與穩(wěn)定。

上面的這三個模塊，每個角色都是一個多節(jié)點(diǎn)組成的集群，所以最終 TiDB 的架構(gòu)看起來是這樣的。

由此可見，分布式系統(tǒng)本身的復(fù)雜性導(dǎo)致手工部署和運(yùn)維的成本是比較高的，并且容易出錯。傳統(tǒng)的自動化部署運(yùn)維工具如 Puppet / Chef / SaltStack / Ansible 等，由于缺乏狀態(tài)管理，在節(jié)點(diǎn)出現(xiàn)問題時不能及時自動完成故障轉(zhuǎn)移，需要運(yùn)維人員人工干預(yù)。有些則需要寫大量的 DSL 甚至與 Shell 腳本一起混合使用，可移植性較差，維護(hù)成本比較高。

在云時代，容器成為應(yīng)用分發(fā)部署的基本單位，而谷歌基于內(nèi)部使用數(shù)十年的容器編排系統(tǒng) Borg 經(jīng)驗(yàn)推出的開源容器編排系統(tǒng) Kubernetes 成為當(dāng)前容器編排技術(shù)的主流。作為 Cloud Native Database，TiDB 選擇擁抱容器技術(shù)，并與 Kubernetes 進(jìn)行深度整合，使其可以非常方便地基于 Kubernetes 完成數(shù)據(jù)庫的自動化管理。

Kubernetes 項(xiàng)目可以說是為 Cloud 而生，利用云平臺的 IaaS 層提供的 API 可以很方便的和云進(jìn)行整合。這樣我們要做的事情就很明確了，只要讓 TiDB 與 Kubernetes 結(jié)合的更好，進(jìn)而就實(shí)現(xiàn)了和各個云平臺的整合， 使得 TiDB 在云上的快速部署和高效運(yùn)維成為現(xiàn)實(shí)。

Kubernetes 最早是作為一個純粹的容器編排系統(tǒng)而誕生的，用戶部署好 Kubernetes 集群之后，直接使用其內(nèi)置的各種功能部署應(yīng)用服務(wù)。由于這個 PaaS 平臺使用起來非常便利，吸引了很多用戶，不同用戶也提出了各種不同的需求，有些特性需求 Kubernetes 直接在其核心代碼里面實(shí)現(xiàn)了，但是有些特性并不適合合并到主干分支，為滿足這類需求，Kubernetes 開放出一些 API 供用戶自己擴(kuò)展，實(shí)現(xiàn)自己的需求。當(dāng)前 Kubernetes 已經(jīng)發(fā)展到 v1.8，其內(nèi)部的 API 變得越來越開放，使其更像是一個跑在云上的操作系統(tǒng)。用戶可以把它當(dāng)作一套云的 SDK 或 Framework 來使用，而且可以很方便地開發(fā)組件來擴(kuò)展?jié)M足自己的業(yè)務(wù)需求。對有狀態(tài)服務(wù)的支持就是一個很有代表性的例子。

Kubernetes 項(xiàng)目最早期只支持無狀態(tài)服務(wù) (Stateless Service) 來管理的，無狀態(tài)服務(wù)通過 ReplicationController 定義多個副本，由 Kubernetes 調(diào)度器來決定在不同節(jié)點(diǎn)上啟動多個 Pod，實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。對于無狀態(tài)服務(wù)，多個副本對應(yīng)的 Pod 是等價(jià)的，所以在節(jié)點(diǎn)出現(xiàn)故障時，在新節(jié)點(diǎn)上啟動一個 Pod 與失效的 Pod 是等價(jià)的，不會涉及狀態(tài)遷移問題，因而管理非常簡單。但是對于有狀態(tài)服務(wù) (Stateful Service)，由于需要將數(shù)據(jù)持久化到磁盤，使得不同 Pod 之間不能再認(rèn)為成等價(jià)，也就不能再像無狀態(tài)服務(wù)那樣隨意進(jìn)行調(diào)度遷移。Kubernetes v1.3 版本提出 PetSet 的概念用來管理有狀態(tài)服務(wù)并于 v1.5 將其更名為 StatefulSet。StatefulSet 明確定義一組 Pod 中每個的身份，啟動和升級都按特定順序來操作。另外使用持久化卷存儲 (PersistentVolume) 來作為存儲數(shù)據(jù)的載體，當(dāng)節(jié)點(diǎn)失效 Pod 需要遷移時，對應(yīng)的 PV 也會重新掛載，而 PV 的底層依托于分布式文件系統(tǒng)，所以 Pod 仍然能訪問到之前的數(shù)據(jù)。同時 Pod 在發(fā)生遷移時，其網(wǎng)絡(luò)身份例如 IP 地址是會發(fā)生變化的，很多分布式系統(tǒng)不能接受這種情況。所以 StatefulSet 在遷移 Pod 時可以通過綁定域名的方式來保證 Pod 在集群中網(wǎng)絡(luò)身份不發(fā)生變化。

然而現(xiàn)實(shí)中一些分布式系統(tǒng)更為復(fù)雜，StatefulSet 也顯得捉襟見肘。舉例來說，某些分布式系統(tǒng)的節(jié)點(diǎn)在加入集群或下線時還需要做些額外的注冊和清理操作，或者滾動升級要考量版本兼容性等?；谶@個原因 CoreOS 公司提出了 Operator 概念，并實(shí)現(xiàn)了 etcd-operator 和 prometheus-operator 來管理 Etcd 和 Prometheus 這樣的復(fù)雜分布式系統(tǒng)。用戶可以開發(fā)自己的 Operator，在 Kubernetes 之上實(shí)現(xiàn)自定義的 Controller，將有狀態(tài)服務(wù)的領(lǐng)域特定的運(yùn)維知識編碼進(jìn)去，從而實(shí)現(xiàn)對特定分布式系統(tǒng)的管理。同時 Operator 本身也是跑在 Kubernetes 中的一組 Pod（deployment），對 Kubernetes 系統(tǒng)并無侵入性。

針對 TiDB 這種復(fù)雜的分布式服務(wù)，我們開發(fā)了 tidb-operator 等一系列組件，來管理 TiDB 集群實(shí)例在 Kubernetes 平臺上的創(chuàng)建、銷毀、擴(kuò)縮容、滾動升級和故障轉(zhuǎn)移等運(yùn)維操作。同時在上層封裝一個 tidb-cloud-manager 組件，提供 RESTful 接口，實(shí)現(xiàn)與云平臺的控制臺打通。這樣也就實(shí)現(xiàn)了一個 DBaaS （數(shù)據(jù)庫即服務(wù)）架構(gòu)的基本形態(tài)。

由于 TiDB 對磁盤 I/O 有比較高的要求，通過 PV 掛載網(wǎng)絡(luò)盤性能上會有明顯的性能損耗。另外 TiKV 本身維護(hù)了數(shù)據(jù)多副本，這點(diǎn)和分布式文件系統(tǒng)的多副本是有重復(fù)的。所以我們要給 Pod 上掛載本地磁盤，并且在 Kubernetes 上面把 Local PV 管理起來，作為一種特定的資源來維護(hù)。Kubernetes 長期以來官方一直沒有提供 Local PV 支持，本地存儲只支持 hostPath 和 emptyDir 兩種方式。其中 hostPath 的生命周期是脫離 Kubernetes 管理的，使用 hostPath 的 Pod 銷毀后，里面的數(shù)據(jù)是不會被自動清理，下次再掛載 Pod 就會造成臟數(shù)據(jù)。而 emptyDir 更像一個臨時磁盤，在 Pod 重建時會被清理重置，不能成為持久化 PV 來使用。為此我們開發(fā)了一個 tidb-volume-manager 組件，用于管理 Kubernetes 集群中每臺物理主機(jī)上的本地磁盤，并且將其暴露成一種特殊的 PV 資源。結(jié)合 Operator 在部署 TiDB 節(jié)點(diǎn)時會參考 Local PV 資源的情況來選擇特定的節(jié)點(diǎn)來部署，分配一個空的 Local PV 和 Pod 綁定。而當(dāng) Pod 銷毀時候會根據(jù)具體情況來決定是否結(jié)束 Local PV 的生命周期，釋放掉的 Local PV 再經(jīng)歷一個 gc 周期后，被 tidb-volume-manager 回收，清理其盤上數(shù)據(jù)等待再次被分配使用。

將這些組件整合起來，就形成了上圖描述了 Cloud TiDB 的總體架構(gòu)，在 Kubenetes 管理的集群之上通過 tidb-operator 等組件來針對性的調(diào)配和使用集群資源，從而實(shí)現(xiàn) TiDB 集群實(shí)例的生命周期管理。通過這種方式，來實(shí)現(xiàn) TiDB 分布式數(shù)據(jù)庫和云平臺的整合。接下來，我們再針對 Cloud TiDB 的關(guān)鍵特性和實(shí)現(xiàn)細(xì)節(jié)分別進(jìn)行解讀。

數(shù)據(jù)庫產(chǎn)品上云的一個先決條件是能實(shí)現(xiàn)自動化的運(yùn)維管理，否則在云上靠手工運(yùn)維幾乎是不現(xiàn)實(shí)的。我們首先用 Kubernetes 將云平臺的主機(jī)資源管理起來，組成一個大的資源池。然后再通過 tidb-opeartor 及 tidb-cloud-manager 等組件來自動化完成 TiDB 實(shí)例的一鍵部署、擴(kuò)容縮容、在線滾動升級、自動故障轉(zhuǎn)移等運(yùn)維操作。

首先拿集群創(chuàng)建來說。前面提到過，TiDB 包含三大核心組件：TiDB / TiKV / PD，每個服務(wù)又都是一個多節(jié)點(diǎn)的分布式結(jié)構(gòu)。服務(wù)和服務(wù)之間的啟動順序也存在依賴關(guān)系。此外，PD 節(jié)點(diǎn)的創(chuàng)建和加入集群方式和 etcd 類似，是需要先創(chuàng)建一個單節(jié)點(diǎn)的 initial 集群，后面加入的節(jié)點(diǎn)需要用特殊的 join 方式，啟動命令上都有差別。有一些操作完成后還需要調(diào)用 API 進(jìn)行通知。Kubernetes 自身提供的 StatefulSet 是很難應(yīng)付這種復(fù)雜的部署，所以需要 tidb-operator 中實(shí)現(xiàn)特定的 Controller 來完成這樣一系列的操作。并且結(jié)合 Kubernetese 強(qiáng)大的調(diào)度功能，合理的規(guī)劃和分配整個集群資源，盡量讓新部署的 TiDB 實(shí)例節(jié)點(diǎn)在集群中均勻分布，最終通過 LB 暴露給對應(yīng)的租戶使用。

在線升級也是類似。由于 TiKV / PD 的 Pod 掛載的是本地存儲，并不能像云平臺提供的塊存儲或網(wǎng)絡(luò)文件系統(tǒng)那樣可以隨意掛載。如果 TiKV / PD 遷移到其它節(jié)點(diǎn)，相當(dāng)于數(shù)據(jù)目錄也被清空，所以必須保證 TiKV / PD 的 Pod 在升級完成后仍然能夠調(diào)度在原地，這也是要由 tidb-operator 的 Controller 來保證。TiDB 的數(shù)據(jù)副本之間由 Raft 算法來保證一致性，因此當(dāng)集群中某一個節(jié)點(diǎn)暫時斷開可以不影響整個服務(wù)的。所以在集群升級的過程中，必須嚴(yán)格按照服務(wù)的依賴關(guān)系，再依次對 Pod 進(jìn)行升級。

當(dāng)節(jié)點(diǎn)出現(xiàn)故障時，同樣是由于掛載本地?cái)?shù)據(jù)盤的原因，也不能像 StatefulSet 那樣直接把 Pod 遷移走。當(dāng) TiDB Operator 檢測到節(jié)點(diǎn)失效，首先要等一定的時間確認(rèn)節(jié)點(diǎn)不會再恢復(fù)了，開始遷移恢復(fù)的操作。首先調(diào)度選擇一個新節(jié)點(diǎn)啟動一個 Pod, 然后通知 TiDB 將失效的節(jié)點(diǎn)放棄掉，并將新啟的 Pod 加入集群。后面會由 TiDB 的 PD 模塊來完成數(shù)據(jù)副本數(shù)的恢復(fù)，以及數(shù)據(jù)往新節(jié)點(diǎn)上進(jìn)行搬移，從而重新維持集群內(nèi)數(shù)據(jù)平衡。

以上只是列舉了 TiDB 幾種典型的運(yùn)維操作流程，實(shí)際生產(chǎn)上運(yùn)維還有很多 case 需要考慮，這些都以程序的方式實(shí)現(xiàn)在 tidb-operator 里面。借助 Kubernetes 和 tidb-operator 來代替人工，高效的完成 TiDB 數(shù)據(jù)庫在云平臺上的復(fù)雜運(yùn)維管理。

彈性水平伸縮是 TiDB 數(shù)據(jù)庫最主要的特性之一。在大數(shù)據(jù)時代，人們對數(shù)據(jù)存儲的需求在快速膨脹。有時候用戶很難預(yù)估自己的業(yè)務(wù)規(guī)模的增長速度，如果采用傳統(tǒng)的存儲方案，可能很快發(fā)現(xiàn)存儲容量達(dá)到了瓶頸，然后不得不停機(jī)來做遷移和完成擴(kuò)容。如果使用 Cloud TiDB 的方案，這個過程就非常簡單，只需要在 Cloud 控制臺上修改一下 TiDB 的節(jié)點(diǎn)數(shù)量，很快就能完成擴(kuò)容操作，期間還不會影響業(yè)務(wù)的正常服務(wù)。

那么在 Cloud 后臺，同樣借助 Kubernetes 和 tidb-operator 的能力來完成 TiDB 增減節(jié)點(diǎn)操作。Kubernetes 本身的運(yùn)作是基于一種 Reconcile 的機(jī)制。簡單來說當(dāng)用戶提交一個新的請求，比如期望集群里面跑 5 個 TiKV 節(jié)點(diǎn)，而目前正在跑的只有 3 個，那么 Reconcile 機(jī)制就會發(fā)現(xiàn)這個差異，首先由 Kubernetes 的調(diào)度器根據(jù)集群整體資源情況，并結(jié)合 TiDB 節(jié)點(diǎn)分配的親和性原則和資源隔離原則來分配節(jié)點(diǎn)。另外很重要一點(diǎn)就是選擇有空閑 Local PV 的機(jī)器來創(chuàng)建 Pod 并進(jìn)行掛載。最終通過 tidb-operator 將 2 個節(jié)點(diǎn)加入 TiDB 集群。

對于縮容的過程也是類似。假如數(shù)據(jù)庫存儲的總數(shù)據(jù)量變少，需要減少節(jié)點(diǎn)以節(jié)省成本。首先用戶通過云控制臺向后端提交請求，在一個 Reconciling 周期內(nèi)發(fā)現(xiàn)差異，tidb-operator 的 Controller 開始通知 TiDB 集群執(zhí)行節(jié)點(diǎn)下線的操作。安全下線可能是個比較長的過程，因?yàn)槠陂g需要由 PD 模塊將下線節(jié)點(diǎn)的數(shù)據(jù)搬移到其他節(jié)點(diǎn)，期間集群都可以正常服務(wù)。當(dāng)下線完成，這些 TiKV 變成 tombstone 狀態(tài)。而 tidb-operator 也會通知 Kubernetes 銷毀這些 Pod，并且由 tidb-volume-manager 來回收 Local PV。

資源隔離也是云上用戶關(guān)心的一個問題。尤其是數(shù)據(jù)庫這類應(yīng)用，不同租戶的數(shù)據(jù)庫實(shí)例，甚至一個租戶的多套數(shù)據(jù)庫實(shí)例，都跑在一套大的 Kubernetes 管理的集群上，相互間會不會有資源的爭搶問題，某個實(shí)例執(zhí)行高負(fù)載的計(jì)算任務(wù)時，CPU、內(nèi)存、I/O 等會不會對同臺機(jī)器上部署的其他實(shí)例產(chǎn)生影響。其實(shí)容器本身就是資源隔離的一個解決方案，容器的底層是 Linux 內(nèi)核提供的 cgroups 技術(shù)，用于限制容器內(nèi)的 CPU、內(nèi)存以及 IO 等資源的使用，并通過 namespace 技術(shù)實(shí)現(xiàn)隔離。而 Kubernetes 作為容器編排系統(tǒng)，能夠根據(jù)集群中各個節(jié)點(diǎn)的資源狀況，選擇最優(yōu)的策略來調(diào)度容器。同時 tidb-operator 會根據(jù) TiDB 自身的特性和約束，來綜合決策 TiDB 節(jié)點(diǎn)的調(diào)度分配。舉例來說，當(dāng)一個 Kubernetes 集群橫跨多個可用區(qū)，用戶申請創(chuàng)建一個 TiDB 集群，那么首先根據(jù)高可用性原則，將存儲節(jié)點(diǎn)盡量分配到不同的可用區(qū)，并給 TiKV 打上 label。那么同一個可用區(qū)內(nèi)也盡量不把多個 TiKV 部署到相同的物理節(jié)點(diǎn)上，以保證集群資源最大化利用。此外，每個 Local PV 也是一塊獨(dú)立的磁盤，每個 TiKV 的 Pod 分別掛載不同的盤，所以 I/O 上也是完全隔離的。Kubernetes 還可以配置 Pod 之間的親和性(affinity)和反親和性(anti-affinity)，例如 TiKV 和 TiDB 之間我們可以通過親和性使其調(diào)度到網(wǎng)絡(luò)延時較小的節(jié)點(diǎn)之上，提高網(wǎng)絡(luò)傳輸效率，TiKV 之間借助反親和性，使其分散部署到不同的主機(jī)、機(jī)架和可用區(qū)上，降低因硬件或機(jī)房故障造成的丟數(shù)據(jù)的風(fēng)險(xiǎn)。

上面解釋了容器層面的隔離，可以看作是物理層面的隔離。那么數(shù)據(jù)層面的隔離，TiDB 的調(diào)度體系也是有所考慮的。比如一個大的 TiDB 集群，節(jié)點(diǎn)分布在很多臺主機(jī)，跨越多個機(jī)架、可用區(qū)。那么用戶可以定義 Namespace，這是一個邏輯概念，不同業(yè)務(wù)的數(shù)據(jù)庫和表放置在不同的 Namespace。再通過配置 Namespace 和 TiKV 節(jié)點(diǎn)以及區(qū)域的對應(yīng)關(guān)系，由 PD 模塊來進(jìn)行調(diào)度，從而實(shí)現(xiàn)不同業(yè)務(wù)的數(shù)據(jù)在物理上的隔離。

TiDB 作為一個分布式數(shù)據(jù)庫本身就具有高可用性，每個核心組件都可以獨(dú)立的擴(kuò)縮容，任意一個模塊在部署多份副本時如果有一個掛掉，整體仍然可以正常對外提供服務(wù)，這是由 Raft 協(xié)議保證的。但是如果對數(shù)據(jù)庫節(jié)點(diǎn)的調(diào)度不加任何限制，包含一份數(shù)據(jù)的多個副本的節(jié)點(diǎn)可能會被調(diào)度到同一臺主機(jī)。這時如果主機(jī)發(fā)生故障，就會同時失去多個副本，一個 Raft 分組內(nèi)在失去多數(shù)派節(jié)點(diǎn)就會使整個集群處于不可用的狀態(tài)。因此 tidb-operator 在調(diào)度 TiKV 節(jié)點(diǎn)時需要避免出現(xiàn)這種情況。

另外 TiDB 支持基于 label 的數(shù)據(jù)調(diào)度的，給不同的 TiKV 實(shí)例加上描述物理信息的 label，例如地域(Region)、可用區(qū)(AZ)、機(jī)架(Rack)、主機(jī)(Host)，這樣 PD 在對數(shù)據(jù)進(jìn)行調(diào)度時就會參考這些信息更加智能的制定調(diào)度策略，盡最大可能保證數(shù)據(jù)的可用性。例如 PD 會基于 label 信息盡量把相同數(shù)據(jù)的副本分散調(diào)度到不同的主機(jī)、機(jī)架、可用區(qū)、地域上，這樣在物理節(jié)點(diǎn)掛掉或機(jī)架掉電或機(jī)房出故障時，其它地方仍然有該數(shù)據(jù)足夠的副本數(shù)。借助 tidb-operator 中 controller-manager 組件我們可以自動給 TiKV 實(shí)例加上物理拓?fù)湮恢脴?biāo)簽，充分發(fā)揮 PD 對數(shù)據(jù)的智能調(diào)度能力，實(shí)現(xiàn)數(shù)據(jù)層面的高可用性。

同時我們還可以實(shí)現(xiàn)實(shí)例級別的高可用性，通過 Kubernetes 強(qiáng)大的調(diào)度規(guī)則和我們擴(kuò)展的調(diào)度器，我們按優(yōu)先級會盡量選擇讓 TiKV 部署到不同的主機(jī)、機(jī)架和可用區(qū)上，把因主機(jī)、機(jī)架、機(jī)房出問題造成的影響降到最低，使數(shù)據(jù)具有最大的高可用性。
另外運(yùn)行在 Kubernetes 之上我們能實(shí)時監(jiān)測到 TiDB 各組件的運(yùn)行情況，當(dāng)出現(xiàn)問題時，我們也能第一時間讓 tidb-operator 對集群進(jìn)行自動修復(fù) (self-healing)。具體表現(xiàn)為 TiDB / TiKV / PD 實(shí)例出現(xiàn)故障時，執(zhí)行安全的下線操作。同時增加新的實(shí)例，來保證集群的規(guī)模和之前一致。

TiDB 作為一款 Cloud Native Database，通過 tidb-operator 的方式充分發(fā)揮 Kubernetes 平臺的強(qiáng)大能力，實(shí)現(xiàn)云上自動化管理，極大降低人力運(yùn)維成本。用戶可以根據(jù)業(yè)務(wù)需要進(jìn)行動態(tài)擴(kuò)容縮容，多租戶隔離特性讓不同租戶的實(shí)例可以共享計(jì)算和存儲資源，互不干擾，同時最大程度充分使用云上資源。Raft 算法和 tidb-operator 自動修復(fù)能力以及兩層調(diào)度機(jī)制保證了 Cloud TiDB 的高可用性。UCloud 和 PingCAP 公司深度合作，推出 Cloud TiDB 產(chǎn)品現(xiàn)已開啟公測，歡迎大家來體驗(yàn)云時代的新一代數(shù)據(jù)庫。