PCTA考試筆記

tidb-server：對等的、無狀态的，可橫向擴充的、支援多節點寫入，直接承接使用者sql的入庫

pd:自動，自定義排程

tikv：分布式且支援事務key-value存儲引擎（transaction，mvcc，multi-raft，rockdb）

raft是一種用于替代paxos的共識算法，相比于paxos

raft的目标是提供更清晰的邏輯分工使得算法本身能被更好的了解，同時它安全性更高，并能提供一些額外的特性

去中心化的兩階段送出

   通過pd全局受時（tso）

--4m timestamps每秒

每個tikv節點配置設定單獨區域存放鎖資訊

google percolator事務模型

tikv支援完整事務kv api

預設樂觀事務模型

   也支援悲觀事務模型（3.0+版本）

預設隔離級别:snapshot lsolation

協作處理器（coprocessor）

coprocessor就是tikv中讀取資料并計算的子產品，每個tikv節點，都有一個協調電腦

第一，在tidb裡沒有分表概念，是以整個ddl完成過程是非常快速的

第二，把ddl過程分為public、delete-only、write-only等幾個狀态，每狀态在多節點之間同步和一緻，最終完成完整的ddl

otlp：高并發，低延遲

otap：吞吐量

引入spark來環節資料中台算力問題

tispark 是 pingcap 為解決使用者複雜 olap 需求而推出的産品。它借助 spark 平台，同時融合 tikv 分布式叢集的優勢，和 tidb 一起為使用者一站式解決 htap (hybrid transactional/analytical processing) 的需求。

spark隻能提供低并發的重量級查詢，從應用場景，很多中小規模的輕量ap查詢，也需要高并發、相對低延遲技術能力，這種場景下，spark的技術模型重，資源消耗高的缺點就會暴露

列存天然對olap查詢類有益，将副本放到一個列式引擎

實體隔離是最好的資源隔離

tiflash以raft learner方式接入multi-raft組，使用異步方式傳輸資料，對tikv産生非常小的負擔

當資料同步到tiflash時，會被從行格式拆解為列格式

mpp下，tidb-server作為入口，通過代價決定是否經由mpp模式計算

mpp模式下，tiflash作為mpp計算節點

lsm-tree結構本質是一個用空間置換寫入延遲，用順序寫入替換随機寫入的資料結構

rockdb是一個非常成熟的lsm-tree存儲引擎，支援批量寫入，無鎖快照讀

range分片可以更高效的掃描資料記錄

range分片可以簡單實作自動完成分裂與合并

彈性優先，分片需要可以自由排程

通過在key後面添加版本号來實作

自動merge

96m自增分片

20mb合并分片

全局有序的kv map

按照等長大小政策自動分片（96m）

每個分片是連續的kv，通過start/end key來尋址

每個分片seek成本固定

我們稱該分片為region，它是複制、排程的最小機關

tikv叢集是tidb資料庫的分布式kv存儲引擎，資料以region為機關進行複制和管理，每個region會有多個replica（副本）

這些replica會分布在不同的tikv點上，讀寫在leader上，follower負責同步leader發來的raft log

4.0版本開啟follower read

region base multi-raft的機制，實作了一個表可以同時有多個寫入點，tikv的排程機制，可以識别單個節點的實體資訊（機房、機櫃、主控端等），并進行限制與綁定

tidb引入了實時更新的列式引擎，既解決了資源隔離，有提升了ap效率

在列存上引入mpp模型，實作了sql join的下推與并行處理

通過raft-base replication實作了更時效性

融合大資料生态，比如tispark

tidb的cbo可以采集行列cost模型進行配置，并同步收集不通引擎的統計資訊，統一進行最佳執行路徑的選擇

tiup cluster 是 tiup 提供的使用 golang 編寫的叢集管理元件，通過 tiupcluster 元件就可以進行日常的運維工作，包括部署、啟動、關閉、銷毀、彈性擴縮容、更新 tidb 叢集，以及管理 tidb 叢集參數

​目前 tiup 可以支援部署 tidb、tiflash、tidb binlog、ticdc，以及監控系統。

tidb、tikv、pd節點都有資料資訊

pd節點的kv中繼資料存放在/tidb-data目錄下

緊急級别 最高嚴重程度，服務不可用，通常由于服務停止或節點故障導緻，此時需要馬上進行人工幹預

嚴重級别 服務可用性下降，需要使用者密切關注異常名額

警告級别 對某一問題或錯誤的提醒

線上擴容tidb/tikv/pd一緻，tiflash需要額外的操作

滾動更新會逐個更新所有的元件。更新 tikv 期間，會逐個将 tikv 上的所有 leader 切走再停止該 tikv 執行個體。預設逾時時間為 5 分鐘，超過後會直接停止執行個體。

如果不希望驅逐 leader，而希望立刻更新，可以在上述指令中指定 --force，該方式會造成性能抖動，不會造成資料損失。

tidb 叢集可以在不中斷線上服務的情況下進行擴容和縮容。

方案一：通過 tiup 縮容 tiflash 節點

方案二：手動縮容 tiflash 節點

在特殊情況下（比如需要強制下線節點），或者 tiup 操作失敗的情況下，可以使用手動下線 tiflash節點。

從 mysql 複制：tidb data migration (dm) 是将 mysql/mariadb 資料遷移到 tidb 的工具，可用于增量資料的複制。

向 mysql 複制：ticdc 是一款通過拉取 tikv 變更日志實作的 tidb 增量資料同步工具，可通過mysqlsink 将 tidb 增量資料複制到 mysql。

增量資料同步工具，支援多種下遊 (tidb/mysql/mq)。相比于 tidb binlog，ticdc 有延遲更低、天然高可用等優點。

推薦 tikv 部署目标機器的資料目錄使用 ext4 檔案系統格式。相比于 xfs 檔案系統格式，ext4檔案系統格式在 tidb 叢集部署案例較多，生産環境優先選擇使用 ext4 檔案系統格式。

dumpling & tidb lightning适合 mysql 全量資料的大小大于 1tb 的場景。該方案隻能遷移全量資料，如果需要繼續同步增量資料，需要

再使用 tidb data migration (dm) 建立增量同步任務。

dm适合遷移 mysql 全量資料并同步增量資料的場景，且全量資料的大小小于 1tb。如果全量資料的大小大于 1tb，

建議使用 dumpling 和 tidb lightning 導入全量資料後，再使用 dm 同步增量資料。

支援通過 csv 和 sql 兩種格式檔案将資料遷移到 tidb。

啟動叢集操作會按 pd -> tikv -> pump -> tidb -> tiflash -> drainer 的順序啟動整個 tidb 叢集所有元件（同時也會啟

動監控元件）：

關閉叢集操作會按 drainer -> tiflash -> tidb -> pump -> tikv -> pd

雖然 tikv 将資料按照範圍切割成了多個 region，但是同一個節點的所有 region 資料仍然是不加區分地存儲于同一個 rocksdb 執行個體上，而用于 raft 協定複制所需要的日志則存儲于另一個 rocksdb 執行個體。這樣設計的原因是因為随機 i/o 的性能遠低于順序 i/o，是以 tikv 使用同一個 rocksdb 執行個體來存儲這些資料，以便不同 region 的寫入可以合并在一次 i/o 中。

region 與副本之間通過 raft 協定來維持資料一緻性，任何寫請求都隻能在 leader 上寫入，并且需要寫入多數副本後（預設配置為 3 副本，即所有請求必須至少寫入兩個副本成功）才會傳回用戶端寫入成功。

ispark 深度整合了 spark catalyst 引擎, 可以對計算提供精确的控制，使 spark 能夠高效的讀取 tikv 中的資料，提供索引支援以實作高速的點查。

謂詞下推将查詢語句中的過濾表達式計算盡可能下推到距離資料源最近的地方，以盡早完成資料的過濾，進

而顯著地減少資料傳輸或計算的開銷。

分區裁剪是隻有當目标表為分區表時，才可以進行的一種優化方式。分區裁剪通過分析查詢語句中的過濾條件，隻選擇可能滿足條件的分區，不掃描比對不上的分區，進而顯著地減少計算的資料量。

​分區表有 range 分區和 hash 分區兩種形式

range分區可以用于解決業務中大量删除帶來的性能問題，支援快速删除分區

hash分區則可以用于大量寫入場景下的資料打散​

• 任何一個資料中心失效後，不會産生任何資料丢失 (rpo = 0)

• 任何一個資料中心失效後，其他兩個資料中心會自動發起 leader election，并在合理長的時間内（通常情

況 20s 以内）自動恢複服務

tikv是一個multi-raft 系統，其資料按 region（預設 96m）切分，每個 region 的3個副本構成了一個raft group。假設一個3副本 tidb 叢集，由于region的副本數與tikv執行個體數量無關，則一個region的3個副本隻會被排程

到其中3個tikv 執行個體上，也就是說即使叢集擴容 n個tikv 執行個體，其本質仍是一個3副本叢集。由于3副本的raft group隻能容忍1副本故障，當叢集被擴容到 n個tikv 執行個體時，這個叢集依然隻能容忍一個tikv執行個體的故障。2個tikv執行個體的故障可能會導緻某些 region 丢失多個副本，整個叢集的資料也不再完整，通路到這些region上的資料的sql請求将會失敗。而n個tikv執行個體中同時有兩個發生故障的機率是遠遠高于3個tikv 中同時有兩個發生故障的機率的，也就是說multi-raft系統叢集擴容tikv執行個體越多，其可用性是逐漸降

低的。

适合場景

适合将不相容 mysql 協定的異構資料庫的資料遷移到 tidb。

遷移方法

将全量資料導出到 csv 格式的檔案中，将 csv 檔案導入到 tidb 有以下兩種方法：

1、使用 tidb lightning 将 csv 格式的資料導入到 tidb

tidb lightning 導入速度快，适合 csv 檔案資料量較大的場景。  

2、使用 load data 語句将 csv 格式的資料導入到 tidb

在 tidb 中執行 load data sql 語句導入 csv 格式的資料，這種導入方法使用比較友善，但是如果在導入

過程中出現錯誤或者中斷，需要人工介入，檢查資料的一緻性和完整性，是以不建議在生産環境中使用。

該部分内容與使用 dumpling 和 tidb lightning 遷移全量資料相同。

備份的類型

熱備份

在讀取和修改資料時進行，幾乎不會中斷您與資料互動或操作資料的能力

對于讀取和修改資料的操作，系統仍可通路

通過以下方式鎖定資料庫：

使用mvcc

鎖定在較低級别，例如行級

完全不鎖定，以便應用程式可以繼續通路資料

備份技術

實體備份：

通過複制資料檔案建立

必須還原到相同的存儲引擎和tidb版本

可以跨機器架構還原

比邏輯備份和恢複執行和還原速度更快

實體備份條件

備份期間，伺服器不得修改資料檔案

如果您複制實時資料檔案，請防止寫入這些檔案

還可以通過使用即将要備份的資料檔案與tidb資料庫伺服器分開的技術來最大程度的降低對tidb和應用程式的影響

 快照

 複制

備份恢複技術對比

10g以上：複制、快照、br

10g以下：dumpling

隻支援在 tidb v3.1 及以上版本使用。

大資料量、速度較快、sst檔案、隻能恢複到tidb資料庫

br 可以直接将指令下發到 tikv 叢集來執行備份和恢複

br 将備份或恢複操作指令下發到各個 tikv 節點。tikv 收到指令後執行相應的備份或恢複操作。

在一次備份或恢複中，各個 tikv 節點都會有一個對應的備份路徑，tikv 備份時産生的備份檔案将會儲存在該路徑下，恢複時也會從該路徑讀取相應的備份檔案。

備份路徑下會生成以下兩種類型檔案：

• sst 檔案：存儲 tikv 備份下來的資料資訊

• backupmeta 檔案：存儲本次備份的元資訊，包括備份檔案數、備份檔案的 key 區間、備份檔案大小和備份檔案 hash (sha256) 值 • backup.lock 檔案：用于防止多次備份到同一目錄

使用 br restore 指令來恢複備份資料。可選擇添加 full、db 或 table 子指令來指定恢複操作的範圍：全部叢集資料、某個資料庫或某張資料表。

增量備份，在備份的時候指定上一次備份時間戳--lastbackupts

增量恢複的方法和全量恢複的方法并無差别，恢複增量資料時，需要保證之前備份資料已經全部恢複到叢集

如果使用本地存儲，在恢複前必須将所有備份的 sst 檔案複制到各個 tikv 節點上 --storage 指定的目錄下。

即使每個 tikv 節點最後隻需要讀取部分 sst 檔案，這些節點也需要有所有 sst 檔案的完全通路

權限。原因如下：

• 資料被複制到了多個 peer 中。在讀取 sst 檔案時，這些檔案必須要存在于所有 peer 中。

這與資料的備份不同，在備份時，隻需從單個節點讀取。

• 在資料恢複的時候，每個 peer 分布的位置是随機的，事先并不知道哪個節點将讀取哪個

檔案。

使用共享存儲可以避免這些情況。例如，在本地路徑上安裝 nfs，或使用 s3。利用這些網絡存儲，各個節點都可以自動讀取每個 sst 檔案，此時上述注意事項不再适用。

在恢複的時候，每個節點都必須能夠通路到所有的備份檔案（sst files），預設情況下，假如使用 local storage，

備份檔案會分散在各個節點中，此時是無法直接恢複的，必須将每個 tikv 節點的備份檔案拷貝到其它所有tikv 節點才能恢複。

全量備份的時候會過濾掉系統庫（information_schema，performance_schema，mysql）

資料導出工具dumping可以把存儲在tidb/mysql中的資料導出為sql或者csv格式，可以用于完成邏輯上的全量備份或者導出

支援導出多種資料格式，包括sql或者csv

邏輯導出

支援全新的表過濾和資料過濾，篩選資料更加友善

支援導出到amazon s3雲盤

針對tidb進行的優化

dumpling所需權限

最小權限要求

select、reload、lock tables、replication client

where filter對導出資料進行篩選

通過consistency <consistency level>标志控制導出資料“一緻性保證”；

metadata此檔案包含導出的起始時間，以及master binary log的位置

-t用于指定導出的線程數

-r用于指定單個檔案的最大記錄數（資料庫中的行數）

tidb lightning運作後，tidb将無法正常對外提供服務

若tidb-lightning崩潰，叢集會停留在導入模式，若忘記轉回普通模式，叢集會産生大量未壓縮的檔案，消耗cpu并導緻延遲，需要手動切換

可以将全量資料高速倒入tidb叢集

導入模式--建立schema和表--分割表--讀取sql dump--寫入本地臨時存儲檔案--倒入資料到tikv叢集--檢驗與分析--普通模式

如何選擇後端模式

導入完畢後tidb lightning會自動退出

tidb-backend支援全部tidb版本

tidb lightning的斷點續傳功能可以将斷點存儲在其他資料庫中

tidb lightning可以隻導入某個schema的資料

是一體化的資料遷移任務管理工具，支援從與mysql協定相容的資料庫到tidb的資料遷移，支援全量的資料載入和增量的資料傳輸，同時可以進行表與操作的過濾，并且可以進行分庫分表的合并遷移

dmctl用來控制dm叢集的指令行工具

dm-master負責管理和排程資料遷移任務的各項操作

dm-worker負責執行具體的資料遷移任務

1、不相容ddl語句 handle-error skip

2、自增主鍵沖突

去掉自增主鍵主鍵屬性

使用聯合主鍵

遷移任務管理

check-task用于檢查指定的資料遷移任務配置檔案是否合法，以及上下遊資料庫的配置、權限、表結構是否滿足遷移要求

start-task執行遷移任務時，dm也會執行check-task所做的全部檢查

可以收集tidb資料庫的日志，并提供資料同步和準實時備份功能

多個pump收集，并排序，然後彙總給某個drainer，排序，然後發送給下遊

一個成功的事務會寫兩條binlog，包括一條prewrite binlog和一條commit binlog

如果事務失敗，會發一條rollback binlog

多個pump組成一個叢集，可以水準擴容

tidb通過内置的pump client将binlog分發到各個pump

pump複雜存儲binlog，并将binlog按順序提供給drainer

drainer負責讀取各個pump的binlog，歸并排序後發送到下面

drainer支援relay log功能，通過relay log保證下遊叢集的一緻性狀态

drainer支援将binlog同步到mysql、tidb、kafka或者本地檔案

tidb binlog在啟動前需要保證上遊和下遊資料一緻

 同步出現故障/檢查運作情況，需要檢視pump和drainer的狀态

 維護叢集，需要暫停/下線pump和drainer

 pump和drainer異常退出，狀态沒有更新，或者狀态不符合預期，對業務造成影響

ticdc 是 4.0 版本開始支援的 tidb

是一款通過拉取tikv變更日志（tikv change log）實作的tidb增量資料同步工具，具有将資料還原到與上遊任意時刻一緻狀态的能力，同時提供開放資料協定（ticdc open protocol），支援

其他系統訂閱資料變更

1、高可用

2、性能

3、支援豐富的下遊資料格式

ticdc适合源資料庫（上遊資料庫）為tidb，目标資料庫（下遊資料庫）支援mysql相容的任何資料庫和kafka，同時ticdc open protocol是一種行級别的資料變更通知協定，

為監控、緩存、全文索引、分析引擎、異構資料庫的主從複制等提供資料源

ticdc從4.0.4開始支援非動态修改同步任務配置，修改changefeed配置需要按照暫停任務--》修改配置--》恢複任務的流程

ticdc限制：

ticdc隻能同步至少存在一個有效索引的表，包括如下表可以正常同步

 主鍵（primary key）為有效索引

 同時滿足下列條件的唯一索引（unique index）為有效索引：

     索引中每一列在表結構中明确定義非空（not null）

  索引中不存在虛拟生成列（virtual generated columes）

ticdc不支援的場景：

ticdc相容性問題

 使用ticdc v5.0.0-rc版本的cdc cli工具操作v4.0x叢集導緻不相容問題

ticdc叢集中capture元件必須>=1個

start-ts預設為目前時間

一套ticdc叢集可以開啟多個任務

changefeed-id可以自動生成

更新同步任務自動操執行，無法線上操作