TiDB 是 PingCAP 公司設計的開源分散式 HTAP (Hybrid Transactional and Analytical
Processing) 資料庫,結合了傳統的 RDBMS 和 NoSQL 的最佳特性。TiDB 相容 MySQL,
支援無限的水平擴充套件,具備強一致性和高可用性。TiDB 的目標是為 OLTP (Online
Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的
解決方案。


TiDB 具備如下核心特性:
高度相容 MySQL
水平彈性擴充套件
分散式事務
真正金融級高可用
一站式 HTAP 解決方案
雲原生 SQL 資料庫


要深入瞭解 TiDB 的水平擴充套件和高可用特點,首先需要了解 TiDB 的整體架構。TiDB 叢集主
要包括三個核心元件:TiDBServer,PD Server 和 TiKV Server。此外,還有用於解決使用者
複雜 OLAP 需求的 TiSpark 元件。


TiDB Server
TiDB Server 負責接收 SQL 請求,處理 SQL 相關的邏輯,並通過 PD 找到儲存計算所需數
據的 TiKV 地址,與 TiKV 互動獲取資料,最終返回結果。TiDB Server 是無狀態的,其本身
並不儲存資料,只負責計算,可以無限水平擴充套件,可以通過負載均衡元件(如 LVS、HAProxy 或
F5)對外提供統一的接入地址。
PD Server
Placement Driver(簡稱 PD) 是整個叢集的管理模組,其主要工作有三個:一是儲存叢集的
元資訊(某個 Key 儲存在哪個 TiKV 節點);二是對 TiKV 叢集進行排程和負載均衡(如資料
的遷移、Raft group leader 的遷移等);三是分配全域性唯一且遞增的事務 ID。
PD 是一個叢集,需要部署奇數個節點,一般線上推薦至少部署 3 個節點。
TiKV Server
TiKV Server 負責儲存資料,從外部看 TiKV 是一個分散式的提供事務的 Key-Value 儲存引
擎。儲存資料的基本單位是 Region,每個 Region 負責儲存一個 Key Range(從 StartKey
到 EndKey 的左閉右開區間)的資料,每個 TiKV 節點會負責多個 Region。TiKV 使用 Raft
協議做複製,保持資料的一致性和容災。副本以 Region 為單位進行管理,不同節點上的多個
Region 構成一個 RaftGroup,互為副本。資料在多個 TiKV 之間的負載均衡由 PD 排程,
這裡也是以 Region 為單位進行排程。
TiSpark
TiSpark 作為 TiDB 中解決使用者複雜 OLAP 需求的主要元件,將 Spark SQL 直接執行在
TiDB 儲存層上,同時融合 TiKV 分散式叢集的優勢,並融入大資料社群生態。至此,TiDB 可
以通過一套系統,同時支援 OLTP 與 OLAP,免除使用者資料同步的煩惱。


核心特性
水平擴充套件
無限水平擴充套件是 TiDB 的一大特點,這裡說的水平擴充套件包括兩方面:計算能力和儲存能力。TiDB
Server 負責處理 SQL 請求,隨著業務的增長,可以簡單的新增 TiDBServer 節點,提高整
體的處理能力,提供更高的吞吐。TiKV 負責儲存資料,隨著資料量的增長,可以部署更多的 TiKV
Server 節點解決資料 Scale 的問題。PD 會在 TiKV 節點之間以 Region 為單位做排程,將
部分資料遷移到新加的節點上。所以在業務的早期,可以只部署少量的服務例項(推薦至少部署
3 個 TiKV, 3 個 PD,2 個 TiDB),隨著業務量的增長,按照需求新增 TiKV 或者 TiDB 實
例。
高可用
高可用是 TiDB 的另一大特點,TiDB/TiKV/PD 這三個元件都能容忍部分例項失效,不影響整
個叢集的可用性。下面分別說明這三個元件的可用性、單個例項失效後的後果以及如何恢復。
TiDB
TiDB 是無狀態的,推薦至少部署兩個例項,前端通過負載均衡元件對外提供服務。當單個例項
失效時,會影響正在這個例項上進行的 Session,從應用的角度看,會出現單次請求失敗的情
況,重新連線後即可繼續獲得服務。單個例項失效後,可以重啟這個例項或者部署一個新的例項。
PD
PD 是一個叢集,通過 Raft協議保持資料的一致性,單個例項失效時,如果這個例項不是 Raft
的 leader,那麼服務完全不受影響;如果這個例項是 Raft 的 leader,會重新選出新的 Raft
leader,自動恢復服務。PD 在選舉的過程中無法對外提供服務,這個時間大約是 3 秒鐘。推
薦至少部署三個 PD 例項,單個例項失效後,重啟這個例項或者新增新的例項。
TiKV
TiKV 是一個叢集,通過 Raft協議保持資料的一致性(副本數量可配置,預設儲存三副本),
並通過 PD做負載均衡排程。單個節點失效時,會影響這個節點上儲存的所有 Region。對於
Region 中的 Leader 結點,會中斷服務,等待重新選舉;對於 Region 中的 Follower 節點,
不會影響服務。當某個 TiKV 節點失效,並且在一段時間內(預設 30 分鐘)無法恢復,PD 會
將其上的資料遷移到其他的 TiKV 節點上。
https://pingcap.com/docs-cn/QUICKSTART/ TIDB 詳細入門指南見官網


TiDB 作為一款開源分散式 NewSQL 資料庫,可以很好的部署和執行在 Intel 架構伺服器環
境及主流虛擬化環境,並支援絕大多數的主流硬體網路。作為一款高效能資料庫系統,TiDB 支
持主流的 Linux 作業系統環境。
https://pingcap.com/docs-cn/op-guide/recommendation/ 軟硬體環境需求


使用 docker 部署 TIDB 叢集
解除安裝低版本,安裝高版本 docker,啟動 docker 服務


配置 rhel7.3的 yum 源


方法一:在單機上通過 Docker Compose 快速一鍵部署一套 TiDB 測試叢集。
Docker Compose 可以通過一個 YAML 檔案定義多個容器的應用服務,然後一鍵啟動或停止
https://pingcap.com/docs-cn/op-guide/docker-compose/
1,下載 tidb-docker-compose
git clone https://github.com/pingcap/tidb-docker-compose.git


2,獲取並匯入 tidb 相關軟體包


**Dockerfile 是 tidb-docker-compose 自帶的,其餘的 tar 包是我們自己獲取的,需要匯入,
docker 不支援一次匯入多個包,只能一個一個匯入


3,在 tidb-docker-compose 目錄下 compose 服務
這裡我們要修改官方原來的.yml檔案,改變檔案控制代碼,每個 tikv 下面做如下修改


4,在 tidb-docker-compose 目錄下 compose 服務


注意:如果要重新 compose,先停掉服務,然後刪除資料目錄下的內容


此時檢視 yml 檔案定義的服務已經全部啟動


4,瀏覽器檢視監控
初始使用者 admin,初始密碼 admin


5,登入資料庫


6,關閉叢集


注意:我們在 compose 建立服務時,自動建立了一個網路,這個網路就是提供這個服務中多個
容器之間的通訊


方法二:如何在多臺主機上使用 Docker 部署一個 TiDB 叢集(本實驗在一臺主機模擬多臺主
機)
https://pingcap.com/docs-cn/op-guide/docker-deployment/


1,建立網路容器


!!!這個網絡卡繫結的是 172.20.0.1/16(其實是從 17 開始向上遞增的,這是第三次實驗,所
以變成了 20),建立這個網絡卡的左右和 yml 檔案定義的網絡卡的作用一樣,實現容器間通訊,而
且是自動做了 dns 解析,普通網絡卡只能 ping ip 地址,不可以 ping 容器名,搭建這個網絡卡之
後就自動做了解析,可以 ping 容器名,至於為什麼一定要用容器名,而不用 ip,這是因為我
們建立容器時並不知道 ip 是多少,這個 ip 是建立之後隨即分配的,雖然有遞增的規律,但是對
於一個特定的例項來說,我們並不知道要給他分配的 ip 是多少,而在建立一個服務時,我們需
要用到多個容器,並且會讓他們通訊,這個時候就必須用容器名,且建立之後對應的 ip 自動解
析到位


***************************實驗驗證***********************
普通網絡卡

使用網絡卡容器

在 yml 檔案中,我們都可以看到使用容器名而沒有使用ip


************************************繼續搭建*********************************


清空 data 下的資料(可忽略)
2,建立叢集
pd:

tikv:

tidb:


3,這個沒有監控頁面,如果想要監控頁面,仿照以上和 yml 檔案新增
4,登入資料庫測試