本學習筆記由個人為備考 PCTP 認證整理而成，僅供個人學習記錄之用，並非官方教材，內容僅代表個人理解。
PingCAP 官方擁有所有核心內容的知識產權。本筆記嚴禁用於任何商業目的。若官方認為筆記內容存在侵權問題，請告知，我將立即刪除。

參考資料：TiDB 數據庫管理

TiDB Cluster 部署

01 部署準備

1. 什麼是 TiUP

• 定義：TiUP 是 TiDB 4.0 版本引入的集羣運維工具。
• 定位：管理 TiDB 集羣，用於處理 TiDB 的日常運維工作。

2. 核心功能

TiUP 涵蓋了 TiDB 集羣全生命週期的管理，具體包括：

• 部署與管理：支持集羣的部署、啓動、關閉以及銷燬。
• 彈性伸縮：支持集羣的彈性擴容和縮容。
• 升級維護：支持 TiDB 集羣的升級操作。
• 配置管理：支持管理 TiDB 集羣的配置參數。

3. 使用方式 (命令行)

TiUP 是一個命令行工具，放在中控機上，其基本語法結構如下：

• 執行命令：tiup [flags] <command> [args...]。
• 運行組件：tiup [flags] <component> [args...]。

常用命令示例：

• tiup list --installed（查看已安裝組件），
• tiup install tidb（安裝組件）。

4. 部署前的環境需求

部署 TiDB 集羣前，對硬件和軟件環境有明確要求。

• 硬件需求：

• TiDB/TiKV/TiCDC：推薦 16 核 CPU + 48GB/64GB 內存，網絡建議萬兆網卡。
• PD/監控：需求相對較低，PD 推薦 8 核 + 16GB 內存。
• TiFlash：計算密集型，推薦 48 核 + 128GB 內存。
• 磁盤：TiKV, PD, TiFlash, TiCDC 均推薦 SSD，TiDB 可用 SAS。

• 操作系統需求：支持 Red Hat, CentOS, Oracle Linux (7.3+), Ubuntu LTS (16.04+), Amazon Linux 2。
• 軟件配置：需要安裝 sshpass (1.06+), numa (2.0.12+), 以及 tar。
  收到，根據您的要求，這裏補充實例數量的最低要求，並重點介紹 TiUP 工具。
• 實例數量最低要求

02 部署

步驟1. 軟硬件環境需求及前置檢查

• 存儲參數配置。
• 關閉 SWAP。
• 關閉防火牆設置。
• 安裝 NTP 服務。
• 操作系統優化參數。
• SSH 互信與 sudo 免密碼配置。
• Numactl 工具安裝。

步驟2. 安裝 TiUP 組件

在滿足環境需求後，安裝 TiUP 工具及集羣組件主要包含以下三個操作指令：

1. 下載並安裝 TiUP 工具：
   使用 curl 命令從官方鏡像下載安裝腳本並運行：
   curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
2. 設置 TiUP 環境變量：
   source .bash_profile
3. 安裝 TiUP cluster 組件：
   安裝用於管理集羣的核心組件：
   tiup cluster

步驟3.初始化集羣拓撲文件

命令行操作 - 生成拓撲模版

調用 TiUP 的 cluster 組件，生成一個標準的集羣拓撲模版文件，並將其重定向保存為 topology.yaml。
執行命令：tiup cluster template > topology.yaml

拓撲文件解析

global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"
  server_configs: {}

pd_servers:
  - host: 10.0.1.4
  - host: 10.0.1.5
  - host: 10.0.1.6

tidb_servers:
  - host: 10.0.1.7
  - host: 10.0.1.8
  - host: 10.0.1.9

tikv_servers:
  - host: 10.0.1.1
  - host: 10.0.1.2
  - host: 10.0.1.3

monitoring_servers:
  - host: 10.0.1.4

grafana_servers:
  - host: 10.0.1.4

alertmanager_servers:
  - host: 10.0.1.4

1. 全局參數配置 (Global Parameter Configuration):

• 對應代碼塊中的 global: 部分。
• 定義了運行用户 (user)、SSH 端口、部署目錄 (deploy_dir) 和數據目錄 (data_dir) 等通用設置。

2. PD 參數配置 (PD Parameter Configuration):

• 對應代碼塊中的 pd_servers: 部分。
• 定義了 Placement Driver (PD) 節點的 IP 地址列表。

3. TiDB 參數配置 (TiDB Parameter Configuration):

• 對應代碼塊中的 tidb_servers: 部分。
• 定義了 SQL 計算節點 (TiDB) 的 IP 地址列表。

4. TiKV 參數配置 (TiKV Parameter Configuration):

• 對應代碼塊中的 tikv_servers: 部分。
• 定義了存儲節點 (TiKV) 的 IP 地址列表。

5. 監控服務器參數配置 (Monitoring Server Parameter Configuration):

• 對應代碼塊中的 monitoring_servers: 和 grafana_servers: 部分。
• 定義了 Prometheus 監控和 Grafana 面板所在的服務器 IP。

6. 報警服務器配置 (Alert Server Configuration):

• 對應代碼塊中的 alertmanager_servers: 部分。
• 定義了 Alertmanager 報警組件所在的服務器 IP。

步驟4. 執行部署命令

配置完成後，使用 TiUP 的 check 和 deploy 指令來驗證環境並執行安裝。

A. 檢查集羣潛在風險

在部署前，運行檢查命令掃描環境配置是否符合要求：

tiup cluster check ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

B. 自動修復潛在風險

如果上一步檢查出系統參數（如 sysctl）不合規，可添加 --apply 參數自動修復：

tiup cluster check ./topology.yaml --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa]

C. 部署 TiDB 集羣

確認環境無誤後，執行最終的部署命令（注意替換 ${cluster-name} 為集羣名稱，版本號示例為 v6.1.0）：

tiup cluster deploy ${cluster-name} v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]

步驟5. 查看TiUP管理的集羣情況

• 命令內容：tiup cluster list

列出安裝了哪幾個集羣

步驟6. 查看指定集羣的詳細信息：

將變量 ${cluster-name} 替換為實際的集羣名 tidb-test：

tiup cluster display ${cluster-name}

運行該命令後，將看到一張詳細的表格，列出了集羣中所有節點（PD、TiKV、TiDB 等）的狀態。

• Status（狀態）列：如果顯示 Up，説明該組件運行正常；如果顯示 Down 或 N/A，則説明有異常或未啓動。
• Host 和 Port：您將看到連接數據庫所需的具體 IP 地址和端口號。

步驟 7：啓動集羣

1. “安全啓動” (--init)

如果第一次啓動這個新部署的集羣，請務必使用帶 --init 參數的命令。這會初始化集羣並自動生成 TiDB root 用户的密碼。

執行命令：

tiup cluster start ${cluster-name} --init

• 重要提示： 命令執行成功後，終端會打印出 The new password is: XXXXXX 的信息。請務必立即複製並保存這個密碼，後面登錄數據庫時必須用到它。

2. 使用“普通啓動”

如果集羣以前已經初始化過（例如重啓服務器，或者之前已經運行過帶 --init 的命令），則不需要再次初始化，直接啓動即可。

命令為：

tiup cluster start ${cluster-name}

3. 集羣組件啓動順序

PD(集羣大腦) -> TiKV -> TiDB Server -> TiFlash -> 監控組件 （如Prometheus、Grafana等等）

步驟 8：驗證集羣運行狀態

啓動完成後需要確認所有組件是否都已正常運行。

1. 通過 TiUP 再次檢查：

tiup cluster display ${cluster-name}

2. 檢查 Dashboard 和 Grafana：

• 在上一步的輸出結果中，找到 Dashboard 和 Grafana 的 IP 和端口。
• 在瀏覽器中訪問這些地址，查看圖形化監控界面是否正常顯示。

步驟9：停止集羣

執行命令

tiup cluster stop ${cluster-name}

• 注意： 將 ${cluster-name} 替換為實際集羣名。

集羣組件停止順序

監控組件 ->TiFlash -> TiDB -> TiKV -> PD。

03 數據文件與日誌

組件與文件

集羣組件的“有狀態”或“無狀態”特性決定了它們擁有的文件類型：

1. TiDB Server（計算層）—— 無狀態

• 文件類型： 只有 配置文件 和 日誌文件。
• 含義： TiDB 節點只負責處理 SQL 請求和計算，它不存儲任何業務數據。

2. TiKV Server（存儲層）—— 有狀態

• 文件類型： 擁有 配置文件、數據文件 和 日誌文件。
• 含義： 這是集羣的核心存儲庫。您的業務數據（表數據、索引）都存儲在這裏的“數據文件”中。

3. PD Server（調度/元數據層）—— 有狀態

• 文件類型： 擁有 配置文件、數據文件 和 日誌文件。
• 含義： PD 存儲的是集羣的“大腦”信息（比如哪個節點存了哪些數據、節點狀態等）。

文件位置

這些文件通常位於在 topology.yaml 中配置的目錄，或者默認目錄下。

一般來説，目錄結構如下：

deploy_dir (部署目錄)

存放應用程序、二進制文件、腳本和 配置文件。

例如：/tidb-deploy/pd-2379/

以PD 節點的部署目錄為例，有以下四個關鍵子文件夾：

• bin/ (Binary)

• 文件： `pd-server
• 含義： 這是 PD 組件的可執行程序本身。

• conf/ (Config)

• 文件： pd.toml
• 含義： 這是 配置文件。裏面定義了端口、節點間通信規則等參數。

• log/ (Log)

• 文件： pd.log, pd_stderr.log
• 含義： 這是 日誌文件。
• 注意： pd.log 記錄主要運行信息，pd_stderr.log 記錄標準錯誤輸出（通常用於排查進程啓動瞬間的崩潰）。

• scripts/ (Scripts)

• 文件： run_pd.sh
• 含義： 這是 啓動腳本。TiUP 使用這個腳本來啓動 pd-server。如果打開它，可以看到完整的啓動命令和參數。

data_dir (數據目錄)

存放 數據文件（僅 TiKV 和 PD 有）。

例如：`/tidb-data/tikv-20160/。

以TiKV節點的數據目錄為例，

• 進入 tikv-20160 後，可以看到兩個核心文件夾：

• raft-engine/：

• 這是存放 Raft 協議日誌的地方，用於保證分佈式一致性。

• db/：

• 這是存放實際業務數據（Key-Value）的地方。

• 當進入 db/ 目錄後，列表中的文件揭示了 TiKV 的底層實現 —— RocksDB：

• .sst 文件（如 000014.sst）：

• 即 SSTable (Sorted String Table)，這是 RocksDB 存儲數據的核心文件格式。

• 輔助文件：

• MANIFEST、CURRENT、LOCK 等都是 RocksDB 運行所必需的元數據文件。

log_dir (日誌目錄）

存放 日誌文件，通常在部署目錄下的 log/ 文件夾。

例如 tidb.log, tikv.log。

TiDB 的連接管理

TiDB 的連接管理

TiDB Server的連接特性

• 支持 MySQL 協議

• 100% 兼容 MySQL 5.7 協議
• 支持 MySQL 5.7 常用的功能和語法
• 不支持的功能特性：存儲過程與函數，觸發器，外鍵，全文索引，空間函數，CTAS語法等，詳情見文檔。

• 無狀態，保證了高可用

命令行客户端連接

可以使用標準的 MySQL 命令行工具連接 TiDB，就像連接普通的 MySQL 數據庫一樣。

• 連接命令：
  需要指定用户名 (-u)、主機 IP (-h) 和端口 (-P)。

• 注意端口：TiDB 的默認服務端口通常是 4000，而 MySQL 默認為 3306。
• 命令示例：mysql -u root -h ${tidb_server_host_IP_address} -P 4000

• Mycli 工具：
  (https://www.mycli.net/)

常用的 GUI 連接工具

Mysql Workbench，navicat for mysql， phpAdmin

開發接口 (API) 支持

在應用程序開發方面，TiDB 支持廣泛的 MySQL 官方連接器和 API。這意味着應用代碼通常只需修改配置文件中的 IP 和端口即可遷移至 TiDB。

支持的列表包括：

• Python: MySQL Connector/Python, MySQL Python API
• Java/.NET: MySQL Connector/Net 等 (Java 通常使用 JDBC，雖未在列表中明確列出但通用)
• C/C++: MySQL C API
• PHP: MySQL PHP API
• Go: MySQL Go API
• 通用標準: ODBC 驅動 (MySQL Connector/ODBC)

TiDB Cloud 的連接

1. 通過 SQL Shell 連接

這是 TiDB Cloud 提供的一種“開箱即用”的連接方式，無需在本地安裝任何軟件。

• 功能位置：在 TiDB Cloud 控制枱的連接選項中，選擇 "Web SQL Shell" 標籤頁。
• 界面展示：點擊 "Open SQL Shell" 後會直接打開一個雲命令控制行。

2. 通過標準方式連接

如果想用本地的開發工具（如 IntelliJ IDEA, DBeaver）或應用程序代碼連接雲端的 TiDB，需要使用 通過標準方式連接。

• 第一步：設置網絡白名單 (Create traffic filter)

• 必須先配置 Traffic filters（流量過濾器），將你當前的 IP 地址（"Add Your Current IP Address"）添加到允許列表中，否則連接會被防火牆拒絕。

• 第二步：獲取連接字符串

• 配置好白名單後，控制枱會生成一行標準的 MySQL 連接命令。
• 命令格式：mysql --connect-timeout 15 -u root -h <雲端長域名> -P 4000 -p。

監控連接

• 執行命令 show processlist;

TiDB 的配置

TiDB 配置有兩大分類：

1. 系統配置 (System Configuration)

這部分主要對應標準的 MySQL 系統變量。

• 特點：通常可以通過 SQL 語句（如 SET GLOBAL 或 SET SESSION）在線動態調整，目的是為了保持與 MySQL 的行為兼容。對應TiDB Server組件。
• 例子：

• autocommit: 控制事務是否自動提交。
• auto_increment_increment / _offset: 控制自增 ID 的步長和起始偏移量（這在多節點寫入時非常重要）。
• max_execution_time: 限制一條 SQL 語句執行的最長時間，防止慢查詢拖垮系統。

• 適用範圍：

• 專指 TiDB Server 這一層的參數，不包含 底層的 TiKV 和 PD 組件。
• 具有 作用域 (Scope) 的概念，分為 GLOBAL（全局）和 SESSION（當前會話）。

• 存儲位置：

• 一部分信息持久化存儲在 TiDB 的 KV 存儲 (TiKV) 中，這意味着即使 TiDB Server 重啓，全局變量的修改也能保留。

• 修改方式：

• 直接通過 MySQL 客户端 執行 SQL 語句修改（例如 SET GLOBAL ...）。

• 生效方式：

• 一部分參數的修改 不需要重啓 即可持久化生效（在線修改）。

• 例子：

• autocommit: 控制事務是否自動提交。
• auto_increment_increment / _offset: 控制自增 ID 的步長和起始偏移量（這在多節點寫入時非常重要）。
• max_execution_time: 限制一條 SQL 語句執行的最長時間，防止慢查詢拖垮系統。

2. 集羣配置 (Cluster Configuration)

這部分是 TiDB 獨有的配置參數。

• 特點：用於控制 TiDB 服務器本身的底層行為、併發模型和網絡通信。這些配置通常寫在配置文件（如 config.toml）中，通過集羣管理工具（如 TiUP）進行修改，部分參數修改後可能需要重啓節點。
• 適用範圍：

• 包含 所有組件 (TiDB-Server, TiKV-Server, PD) 的配置參數。
• 沒有作用域 的概念（沒有 Session 級別的集羣參數）。

• 存儲位置：

• 全部以配置文件的形式存儲在各個服務器節點上 (TiDB, PD, TiKV, TiFlash)。

• 修改方式：

• 必須 通過運維工具 TiUP 進行管理。具體的命令是 tiup cluster edit-config 來修改配置，然後用 tiup cluster reload 來分發配置。

• 生效方式：

• 修改配置文件後，通常重啓節點方可生效,TiDB 5.0 之後可以進行在線修改。

• 例子：

• high-concurrency / normal-concurrency: 用於控制處理不同優先級任務的併發線程數。
• client-urls: 定義服務監聽或通信的地址 URL。
• index-limit: 與索引長度或數量限制相關的配置。

3. 總結對比表

4. 參數修改方式

1. 修改系統參數 (System Variables)

這是最常用的方式，用於調整 SQL 執行行為。完全使用標準的 MySQL 語法。

• Session 作用域 (當前會話生效)

• 場景：只想讓當前連接的這個窗口生效，不影響別人。比如你想臨時測試一個併發參數。
• 命令：

• SET tidb_distsql_scan_concurrency = 10;
• 或者 SET SESSION ...

• Global 作用域 (全局生效)

• 場景：想讓整個數據庫以後新建立的連接都默認使用這個配置。
• 命令：

• SET GLOBAL tidb_distsql_scan_concurrency = 10;

• 注意：修改 Global 變量通常不會影響 當前已經建立 的連接，只會影響 新建立 的連接。即 GLOBAL 級別的系統參數，修改後對於當前會話無效

2. 修改集羣參數 (Cluster Configuration - 推薦的標準方式)

這是修改 TiDB 底層（如 TiKV, PD）參數的標準做法，配置會持久化保存，但需要重啓。

• 工具：必須使用運維工具 TiUP。
• 操作三部曲：

1. 打開配置：

• 運行命令 tiup cluster edit-config ${cluster-name}。這會打開一個類似 vi/vim 的編輯器。

2. 修改 YAML 文件：

• 全局修改：在 server_configs 下修改（例如 tidb: log.slow-threshold: 300），這會應用到該組件的所有節點。
• 特定節點修改：在 tidb_servers 下指定具體的 host 和 port，然後在 config 塊中通過縮進進行配置（例如只修改 10.0.1.11 這台機器的配置）。

3. 生效配置 (Reload)：

• 修改完保存退出後，必須運行 tiup cluster reload ${cluster-name} ...。這個操作會滾動重啓相關組件，讓配置生效。

3. 集羣參數的“在線修改” (Online Modification)

雖然上面説集羣參數通常要重啓，但 TiDB 5.0 之後 提供了一個特有的 SQL 語法 SET CONFIG，允許你無需重啓就能動態調整部分 TiKV 和 PD 的參數。

• 修改 TiKV 配置：

• 全部實例：set config tikv split.qps-threshold = 1000
• 指定實例：set config "127.0.0.1:20180" split.qps-threshold = 1000 (精準控制某個 IP:Port 的節點)

• 修改 PD 配置：

• 例如動態調整日誌級別：set config pd log.level = 'info'

用户管理與安全

用户管理與安全

1. 認證與授權

• 第一步：認證 (Authentication) —— "你是誰？"

• 定義：對用户身份進行驗證。
• 時機：發生在用户 第一次嘗試連接 數據庫時。
• 後果：如果認證失敗（例如密碼錯、用户名不存在、來源 IP 不在允許列表），用户根本無法連接到數據庫，連接會被直接拒絕。

• 第二步：授權 (Authorization) —— "你能做什麼？"

• 定義：對用户的權限進行驗證。
• 時機：發生在用户 執行具體 SQL 查詢 時。
• 後果：TiDB 會檢查你是否有權限執行該操作（例如 SELECT 或 DROP）。如果授權失敗，連接不會斷開，只是這條特定的 SQL 語句會被拒絕執行。

2. 連接全流程

1. 連接請求：客户端發起 TCP 連接。
2. 認證環節：

• 失敗：直接走 連接拒絕 -> 斷開連接 的路徑。你連發 SQL 的機會都沒有。
• 成功：進入 查詢 等待狀態。

3. 查詢環節：

• 用户輸入 SQL 語句。
• 授權檢查：

• 無權限：走 拒絕查詢 路徑，然後返回到查詢狀態。注意，這裏連接依然保持活躍，你可以繼續嘗試其他 SQL。
• 有權限：走 執行查詢 路徑，執行完後返回結果，並回到查詢狀態等待下一條命令。

3. 如何發起遠程連接

• 架構原理：

• 客户端應用（Client Application）通過網絡連接到 TiDB Server 主機。
• 連接請求由 TiDB Server 進程內部的 連接層 (Connection layer) 進行處理。

• 命令語法：

• 需要同時指定四個關鍵信息：用户名 (-u)、密碼 (-p)、服務器地址 (-h) 和 端口 (-P)。
• 標準命令：mysql -u username -ppassword -h servername -P port。

4. 用户管理

1. 創建用户 (Create User)

創建用户時，你需要定義“用户名”和“允許連接的主機”。

• 基本語法：
  CREATE USER '用户名'@'主機域' IDENTIFIED BY '密碼';
• 常見示例：

• 僅限本地連接：
  CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY '1234';
• 指定網段連接 (例如只允許 192.168.10.x 網段)：
  CREATE USER 'test'@'192.168.10.%' IDENTIFIED BY '1234';
• 允許任意主機連接 (生產環境需謹慎)：
  如果不指定主機域，默認為 %（任意主機）。
  CREATE USER 'test';

2. 密碼管理 (Password Management)

如果需要修改現有用户的密碼，有幾種標準方式：

• 方式一 (SET PASSWORD)：
  SET PASSWORD FOR 'test'@'localhost' = 'new_password';
• 方式二 (ALTER USER - 推薦)：
  ALTER USER 'test'@'localhost' IDENTIFIED BY 'new_password';
• 注意：執行這些操作的用户本身必須擁有 CREATE USER 權限，或者直接擁有 MySQL 數據庫的 INSERT/UPDATE 權限。

3. 授權與回收 (Grant & Revoke)

創建用户後，默認他是沒有任何權限的。你需要顯式地授予權限。

• 授予特定權限 (例如只讀)：

• 只給 test 數據庫下的所有表授予查詢 (SELECT) 權限：
• GRANT SELECT ON test.* TO 'user1'@'localhost';

• 授予超級管理員權限：

• 授予所有庫的所有權限 (ALL PRIVILEGES)，並且允許該用户給別人授權 (WITH GRANT OPTION)：
• GRANT ALL PRIVILEGES ON *.* TO 'user2'@'localhost' WITH GRANT OPTION;

• 查看權限：

• SHOW GRANTS FOR 'admin'@'localhost';

• 回收權限：

• REVOKE ALL PRIVILEGES ON *.* FROM 'user2'@'localhost';

• 刪除用户：

• DROP USER 'user3'@'localhost';

5. 角色管理 (Role-Based Access Control)

TiDB 支持 RBAC（基於角色的訪問控制），便於管理大量用户權限。
角色 (Role) 本質上是一組權限的集合，它的用法和用户非常像。

角色的特點

• 角色被創建後默認是 Locked (被鎖住) 的狀態。
• 角色沒有密碼。
• 重要：用户登錄後，必須執行 SET ROLE ALL 命令，才能激活被授予的角色權限。

角色管理

• 創建角色：
  CREATE ROLE 'r_admin', 'r_dev'@'localhost';
• 給角色授權 (Grant Privileges to Role)：

• SQL 命令：

GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'app_developer';

• 創建用户並關聯角色 (Assign Role to Users)：

• SQL 命令：

-- 創建用户
CREATE USER 'bob'@'%' IDENTIFIED BY 'password_bob';
CREATE USER 'alice'@'%' IDENTIFIED BY 'password_alice';

-- 關鍵步驟：把角色賦予用户
GRANT 'app_developer' TO 'bob'@'%', 'alice'@'%';

• 激活角色 (Enable Role)：
  用户登錄後，必須使用 SET ROLE 命令開啓被賦予的角色，否則他們依然沒有任何權限。

SET ROLE ALL;

• 查看權限：
  用於驗證某個用户到底擁有什麼權限（包括他擁有的角色）。
  show grants for 'dev1'@'localhost';
• 權限回收 (Revoke Privileges)：
  如果業務變動，需要收回角色的某些權限，所有擁有該角色的用户都會自動受影響。

• 操作：從 r_dev 角色中收回 INSERT, UPDATE, DELETE 權限。
• 命令：revoke insert, update, delete on test.* from 'r_dev'@'localhost';
• 優勢：你只需要修改這一個角色，所有關聯的開發人員賬號都會立刻失去寫入權限，無需逐個通知。

• 刪除角色 (Drop Role)：
  當某個職位或項目組取消時，可以徹底刪除該角色。

• 命令：drop role 'r_admin', 'r_dev'@'localhost';
• 注意：刪除角色後，之前擁有該角色的用户將不再擁有該角色對應的權限。

6. 忘記 Root 密碼怎麼辦？

1. 修改配置文件：在 TiDB 的配置文件中找到 [security] 部分，添加 skip-grant-table = true。
2. 重啓數據庫：配置生效後重啓 TiDB 節點。
3. 免密登錄：此時你可以直接使用 mysql -h 127.0.0.1 -P 4000 -u root 無密碼登錄進去重置密碼。
   (注：操作完記得把這個配置改回去並重啓，否則系統極其不安全)

監控 TiDB

TiDB 數據庫監控系統架構

TiDB 採用的標準的、基於 Prometheus + Grafana 的開源監控方案。

以下是該架構的核心組件與數據流向解讀：

1. 數據採集核心：Prometheus

• 工作模式 (Pull Model)：

• Prometheus 主動向底下的各個組件（TiDB, TiKV, PD）“拉取”數據。
• 這意味着 TiDB 的各個組件不需要知道監控服務器在哪裏，它們只需要在本地暴露一個 HTTP 接口（通常是 /metrics），等待 Prometheus 來抓取即可。

2. 數據源：TiDB 集羣組件

• 它們內部集成了監控指標（Metrics）的代碼，會實時記錄諸如 "QPS"、"CPU 使用率"、"節點延遲" 等關鍵信息。
• 無需安裝 Agent：與傳統監控不同，TiDB 組件原生支持 Prometheus 標準，通常不需要額外安裝複雜的監控代理軟件。

3. 數據展示：Grafana

• 展示 (Display)：Grafana 從 Prometheus 查詢數據，並將其渲染成圖表和儀表盤（Dashboard）。
• TiDB 的優勢：使用 TiUP 部署集羣時，官方已經為你預置了非常詳細的 Grafana 模板（包括 Overview, TiKV-Details, PD-Details 等面板），你幾乎不需要自己畫圖，開箱即用。

4. 報警通知：Alerting

• 當 Prometheus 發現某個指標異常（例如：TiKV 磁盤剩餘空間小於 20%），它會觸發報警規則。
• 通常會配合 Alertmanager 組件，將報警通過郵件、釘釘、Slack 或企業微信發送給管理員。

TiDB Dashboard

TiDB Dashboard它是一個內置在 PD 組件中的 Web 界面，無需額外安裝。

以下是 TiDB Dashboard 的核心功能：

• 瞭解集羣整體運行概況
• 查看組件及主機運行狀態
• 分析集羣讀寫流量分佈及趨勢變化（通常是指 Key Visualizer 熱力圖功能）
• 列出所有 SQL 查詢的耗時等執行信息
• 詳細瞭解耗時較長的 SQL 語句的執行信息（慢查詢分析）
• 診斷常見集羣問題並生成報告（一鍵診斷功能）
• 查詢所有組件日誌（日誌搜索功能）
• 收集分析各個組件的性能數據（性能分析 Profiling）

TiDB 數據庫監控系統的訪問

• Prometheus + Grafana 監控：

• 這是通過 Grafana 可視化平台查看 Prometheus 採集的數據。
• 訪問地址： http://{Grafana 服務器IP地址}:3000

• TiDB Dashboard：

• 這是 TiDB 自帶的圖形化排查和診斷工具。
• 訪問地址： http://{pd-ip}:2379/dashboard

TiDB 數據庫的報警系統

• 具體報警規則示例：

• 指標名稱： PD_cluster_offline_tikv_nums
• 報警規則邏輯： sum(pd_cluster_status{type="store_down_count"}) > 0
• 含義描述： 該規則用於監測 PD（Placement Driver）在長時間內（默認配置為 30分鐘）沒有收到 TiKV 節點的心跳信號的情況。如果數值大於0，説明有節點離線。

• 警告級別定義：

• 緊急級別 (Emergency)： 最高嚴重程度。意味着服務不可用，通常由服務停止或節點故障導致，需要馬上進行人工干預。
• 嚴重級別 (Critical)： 服務可用性下降，需要用户密切關注異常指標。
• 警告級別 (Warning)： 對某一問題或錯誤的提醒。

常用監控指標

System-Info（系統信息） 面板中常用監控指標

主要用於監控服務器的硬件資源和運行狀態。

1. CPU 配置 (CPU Config)：

• 展示了集羣中各主機節點的 CPU 核數（Vcores/CPU Num）。

2. 內存配置 (Memory Config)：

• 展示了各主機節點的總內存大小（Total Memory）。

3. CPU 使用率 (CPU Usage)：

• 監控各節點的 CPU 負載百分比隨時間的變化趨勢，用於判斷計算資源是否緊張。

4. 網絡狀態 (Network Status)：

• 監控各節點的網絡流量，包括入站（Inbound）和出站（Outbound）的數據傳輸速率。

5. Memory Available（可用內存）：

• 它通過顯示剩餘可用內存的變化來反映內存的使用健康狀況（可用內存越低，使用率越高）。

Service Port Status 的常用監控指標

展示了集羣中各組件服務的存活狀態，用於快速排查服務是否宕機：

• 在線的節點數量 (Up)：

• 綠色列表區域。
• 顯示當前正常運行的服務節點個數。
• 監控的服務包括：TiDB, PD, TiKV, TiFlash, Node_exporter, Blackbox_exporter, Grafana 等。

• 不在線的節點數量 (Down)：

• 紅色列表區域。
• 顯示當前離線或宕機的服務節點個數。這是運維人員需要重點關注的報警區域。

PD（Placement Driver）常用監控指標

通常用於確認集羣調度和容量是否正常。

• 存儲概況：

• 總大小 (Storage capacity)：集羣的總存儲容量。
• 使用大小 (Current storage size)：當前已使用的存儲空間。

• Region 狀態：

• Region 數量 (Number of Regions)：當前集羣中 Region（數據分片）的總數。
• Region 的監控信息 (Region health)：底部的折線圖，用於監控 Region 的健康狀態（如缺副本、待處理等異常狀態）。

• 集羣健康度：

• 是否有錯誤 (Abnormal stores)：右側表格監控異常存儲節點的狀態，包括斷開連接 (Disconnect)、不健康 (Unhealth)、空間不足 (LowSpace) 等。圖中各項均為 0，顯示狀態正常。

TiDB-Server 常用監控指標

主要包含用於衡量數據庫處理能力和資源消耗的 4 個核心指標。

• 每秒執行 SQL 語句數量 (Statement OPS)：

• 即 QPS (Queries Per Second)，用於監控數據庫當前的吞吐量，反映業務請求的繁忙程度。

• SQL 語句的平均處理時間 (Duration)：

• 即 延遲 (Latency)，展示了 SQL 語句執行耗時的分佈情況（如 P99, P95 等），是判斷數據庫性能是否變慢的關鍵指標。

• 連接數量 (Connection Count)：

• 監控當前客户端連接到 TiDB Server 的總連接數，用於排查連接池是否爆滿或是否存在連接泄露。

• 內存使用量 (Memory Usage)：

• 監控 TiDB Server 進程佔用的內存大小，用於防止因內存泄漏或查詢過大導致 OOM (Out Of Memory) 問題。

TiKV 常用監控指標

該看板監控負責數據存儲的 TiKV 組件狀態，用於分析數據讀寫熱點和存儲層壓力。

• Leader 數量：監控各節點上的 Raft Leader 分佈情況，用於判斷讀寫壓力是否均衡。
• Region 數量：監控各節點承載的數據分片數量，判斷數據分佈是否均勻。
• CPU 負載 (CPU)：TiKV 進程的 CPU 使用率。
• 內存使用量 (Memory)：TiKV 進程佔用的內存大小。

TiDB Dashboard 界面常用的監控指標

TiDB Dashboard 相比 Grafana 更加圖形化和直觀，能幫助用户快速確認“有哪些節點在跑” (實例/主機狀況) 以及“業務跑得快不快” (QPS/延遲)。

• 集羣信息 (Cluster Info)
  這部分主要用於查看集羣的拓撲結構和節點運行狀態。

• 實例狀況 (Instances)：

• 展示了集羣中各組件實例（如 PD 節點）的詳細列表。
• 關鍵信息包括：實例地址 (Address)、運行狀態 (Status)（如 Up 表示正常）、啓動時長 (Up Time) 以及版本信息 (Version)。

• 主機狀況 (Hosts)：

• 展示了部署集羣的物理主機資源使用情況。
• 關鍵信息包括：主機 IP 地址、CPU 規格、CPU 使用率 (CPU Usage)、內存大小以及內存使用情況 (Memory Usage)。

• 核心性能指標
  這部分通常位於 Dashboard 的概覽 (Overview) 頁面，用於快速判斷業務流量和系統快慢。

• 集羣 QPS (Cluster QPS)：

• 監控整個集羣每秒處理的 SQL 請求數量。
• 圖表通過不同顏色區分 SQL 類型（如 Select, Insert, Update 等），幫助運維人員瞭解當前的業務負載類型。

• 監控延遲 (Latency)：

• 監控 SQL 語句的執行耗時。
• 圖表通常展示 P99.9, P99, P95 等分位線，用於評估數據庫響應速度是否變慢以及是否存在長尾延遲。

TiDB 集羣管理

在線擴容（TiDB/TiKV/PD）

步驟概述

1. 編輯擴容配置文件（scale-out topology）

• 配置文件示例：scale-out.yaml
• 使用編輯器（如vi）創建或修改配置文件，內容示例如下：

- host: 10.0.1.5
  ssh_port: 22
  port: 4000
  status_port: 10080
  deploy_dir: /data/deploy/install/deploy/tidb-4000
  log_dir: /data/deploy/install/log/tidb-4000

1. 運行擴容命令

• 在命令行中執行以下命令，啓動擴容過程：

tiup cluster scale-out <cluster-name> scale-out.yaml

• 注意：將<cluster-name>替換為您的實際集羣名稱。

1. 確認新節點是否加入

• 擴容完成後，運行以下命令檢查集羣狀態，確認新節點已成功加入：

tiup cluster display <cluster-name>

注意事項

• 確保配置文件中的IP、端口和路徑與您的環境匹配。
• 執行命令前，請備份重要數據以防意外。

TiFlash 在線擴容

擴容前準備

1. 確認版本兼容性

• 操作前，請首先確認當前 TiDB 集羣版本支持 TiFlash 組件。

2. 開啓必要參數

• 在擴容前，需要在集羣中開啓 enable-placement-rules 參數，此參數是部署 TiFlash 的必要前提。

擴容操作步驟

第三步：編輯擴容配置文件

• 使用 vi 或其他文本編輯器創建/編輯 scale-out.yaml 文件。
• 在配置文件中，需配置 tiflash_servers 字段，示例如下：

tiflash_servers:
- host: 10.0.1.4
  # 此處可根據實際需求，參考文檔補充其他配置項，如端口、部署目錄等

第四步：執行擴容命令

• 在終端中運行以下命令，開始擴容 TiFlash 節點：

tiup cluster scale-out <cluster-name> scale-out.yaml

• 請將 <cluster-name> 替換為你的實際集羣名稱。

第五步：驗證擴容結果

• 擴容命令執行完成後，運行以下命令檢查新 TiFlash 節點是否已成功加入集羣：

tiup cluster display <cluster-name>

• 在輸出信息中，確認新節點的狀態為 Up。

注意事項

• 確保配置文件中填寫的節點 IP、目錄等信息準確無誤，且新節點與集羣網絡互通。
• 建議在業務低峯期執行擴容操作。

在線縮容（TiDB/TiKV/PD）

以下是 TiDB/TiKV/PD 集羣在線縮容的操作步驟總結：

操作步驟

第一步：查看節點 ID 信息

• 執行以下命令，查看當前集羣的詳細狀態和所有節點的信息：

tiup cluster display <cluster-name>

• 請將 <cluster-name> 替換為您的實際集羣名稱。
• 從輸出結果中，確認並記錄您希望縮容移除的節點 IP 和 Port。

第二步：執行縮容操作

• 執行縮容命令，指定需要移除的節點：

tiup cluster scale-in <cluster-name> --node <node-IP>:<node-Port>

• 請將 <cluster-name> 替換為集羣名，將 <node-IP>:<node-Port> 替換為上一步中確認的節點地址與端口。

特別注意：--node 參數的值格式必須正確（IP:Port），這是命令執行成功的關鍵。

第三步：檢查集羣狀態

• 縮容操作完成後，再次運行查看命令，確認指定節點已被成功移除，且集羣狀態正常：

tiup cluster display <cluster-name>

注意事項

• 確保在第二步中填寫的節點IP和端口號準確無誤，錯誤的節點標識可能導致操作失敗或移除錯誤節點。
• 建議在業務低峯期執行縮容操作，並在操作前做好必要的數據備份。

TiFlash 在線縮容

TiFlash 的在線縮容流程包含關鍵的數據副本管理步驟，具體如下：

完整操作步驟

第一步：調整數據表的 TiFlash 副本數

• 操作目的：在縮容節點前，通知集羣不再在 TiFlash 上為特定表保存副本。
• 執行命令：

ALTER TABLE <db-name>.<table-name> SET TIFLASH REPLICA 0;

• 請將 <db-name> 和 <table-name> 替換為實際的數據庫名和表名。

第二步：確認副本已被刪除

• 操作目的：查詢系統表，驗證上一步操作已完成，對應表的 TiFlash 副本已成功移除。
• 執行命令：

SELECT * FROM information_schema.tiflash_replica 
WHERE TABLE_SCHEMA = '<db-name>' AND TABLE_NAME = '<table-name>';

• 執行後，應無相關記錄返回，表明副本已刪除。

第三步：查看節點信息

• 操作目的：確認集羣當前狀態，並獲取待縮容 TiFlash 節點的標識（IP:Port）。
• 執行命令：

tiup cluster display <cluster-name>

第四步：執行縮容命令

• 操作目的：通過 TiUP 工具下線指定的 TiFlash 節點。
• 執行命令：

tiup cluster scale-in <cluster-name> --node <node-IP>:<node-Port>

• 請將 <node-IP>:<node-Port> 替換為第三步中查到的目標 TiFlash 節點地址。

第五步：檢查最終集羣狀態

• 操作目的：驗證節點已被成功移除，集羣運行正常。
• 執行命令：

tiup cluster display <cluster-name>

核心要點

與縮容 TiDB/PD/TiKV 不同，縮容 TiFlash 前必須手動清除存儲在其上的數據副本（即執行第一、二步），這是確保數據一致性和操作安全的關鍵前提。

重命名 TiDB 集羣

在集羣啓動後，可以通過 TiUP 工具對其進行重命名。

操作命令

直接執行以下命令即可完成重命名：

tiup cluster rename ${cluster-name} ${new-name}

命令參數説明

• ${cluster-name}：請替換為集羣當前的名稱。
• ${new-name}：請替換為您為集羣設定的新名稱。

注意事項

• 該操作通常可以立即完成，僅更改集羣在 TiUP 管理中的標識符，不會影響集羣內正在運行的服務或數據。
• 執行後，請使用新的集羣名稱進行後續的管理和操作（如 display, scale-out 等）。

清理 TiDB 集羣數據

1. 核心命令

tiup cluster clean <cluster-name> [選項]

請將 <cluster-name> 替換為您的實際集羣名稱。

2. 命令選項詳解

• --log：僅清理所有節點的日誌文件。這通常不會影響集羣運行和數據，但會丟失歷史日誌。
• --data：僅清理所有節點的數據文件。此操作會刪除所有用户數據和集羣元數據，集羣將無法啓動，需要重新初始化部署。
• --all：同時清理日誌文件和數據文件。這是最徹底、最危險的清理方式。

3. 使用 --all 的真實後果
如果執行了 tiup cluster clean <集羣名> --all，將會導致：

1. 數據完全丟失：所有數據庫、表、用户數據被物理刪除，不可恢復。不用密碼可以直接登錄。

TiDB 時區設置

TiDB 的時區設置 time_zone 是系統參數，分為兩個層級，遵循以下規則：

1. 全局時區

• 在系統層面，TiDB 有一個全局時區設置。
• 此設置為所有會話提供了一個默認的時區基準。

2. 會話時區

• 每個客户端連接到 TiDB 後，會建立一個獨立的會話。
• 會話的時區處理有以下三種情況，如圖所示：

• 情況A（有會話時區）：會話顯式設置了自身的時區（例如 time_zone = ‘+8:00’）。該會話內的時間相關操作將以此設置為準。
• 情況B（無會話時區但是有全局時區）：會話未設置自身的時區。此時，該會話將自動繼承並使用全局時區。
• 情況C（無會話時區且無全局時區）：使用Linux操作系統的時區。
• 情況D（什麼都沒有）：默認UTC。

時區設置會影響 TIMESTAMP類型的存儲、顯示以及時間相關函數（如 NOW(),curtime()）的結果。這使得不同地區的用户或應用可以在同一數據庫中使用自己本地的時間設定。
注意：datetime類型不受時區設置影響。

升級 TiDB Cluster

TiDB 集羣補丁升級（HotFix）

適用於快速修復或替換特定組件的二進制文件。

1. 升級集羣中所有 TiDB 實例

此操作用於將補丁一次性應用到集羣內所有 TiDB 服務節點上。

命令格式：

tiup cluster patch ${cluster-name} /tmp/tidb-hotfix.tar.gz -R tidb

參數解析：

• ${cluster-name}：您的 TiDB 集羣的名稱。
• /tmp/tidb-hotfix.tar.gz：補丁包的本地文件路徑（請根據實際路徑修改）。
• -R tidb：指定要升級的組件角色為 tidb。-R 參數用於按角色批量升級。

使用場景：
當需要為所有 TiDB 服務（即計算層）應用一個統一的緊急修復補丁時使用此命令。

2. 替換其中一個 TiDB 實例

此操作用於將補丁僅應用到集羣內某一個指定的 TiDB 服務節點。

命令格式：

tiup cluster patch ${cluster-name} /tmp/tidb-hotfix.tar.gz -N ${Node_IP}:${Node_Port}

參數解析：

• ${cluster-name} 和 /tmp/tidb-hotfix.tar.gz
• -N ${Node_IP}:${Node_Port}：指定要升級的特定節點。-N 參數用於按節點精確升級，${Node_IP}:${Node_Port} 是目標節點的 IP 地址與服務端口。

使用場景：
適用於灰度更新、或僅某個特定節點需要修復的場景。

核心要點總結

• 命令選擇：使用 -R 對某一類角色的所有節點進行批量升級；使用 -N 對某一個特定節點進行精準升級。
• 補丁包：確保提供的 .tar.gz 包是為正確版本和架構編譯的補丁文件。
• 操作影響：patch 命令通常會重啓相關的服務實例以使補丁生效，請在業務低峯期操作，並確保有高可用或容錯能力。建議先在一個節點上測試補丁。

TiDB 集羣版本升級

整個升級流程按照以下步驟順序執行。對於版本號小於等於3.1的集羣，不能直接升級到6.1，必須選擇一個大於4.0的中間版本（如 v4.0.x 或 v5.x）作為跳板。

步驟1：升級 TiUP
首先，確保用於操作集羣的 TiUP 工具本身是最新版本。

# 更新 TiUP 自身
tiup update --self
# 更新 TiUP 的 cluster 組件
tiup update cluster

步驟2：修改TiUP 集羣拓撲配置文件
使用以下命令檢查並確認當前拓撲配置，為兼容目標版本做好準備。此步驟通常用於確認參數，無需修改時可直接退出。

tiup cluster edit-config <cluster-name>

步驟3：檢查集羣健康狀況
這是升級前的關鍵安全檢查，確保集羣當前狀態完全健康，滿足升級前提條件。

tiup cluster check <cluster-name> --cluster
tiup cluster display <cluster-name>  # 確認所有節點狀態為“Up”

步驟4：執行升級

• 不停機升級：使用上述命令，滾動重啓節點，對業務影響較小。5.3之前的TiFalsh不支持在線升級。

tiup cluster upgrade <cluster-name> <target-version>
# 示例：tiup cluster upgrade my-cluster v6.1.0

升級程序會先嚐試將目標 TiKV 實例上的所有 Region Leader 安全地遷移（驅逐）到集羣中的其他 TiKV 節點上,為了在停止該 TiKV 實例進行版本替換前，確保其承擔的讀寫流量（Leader 負責處理讀寫請求）已平滑轉移，從而最大程度避免性能抖動。

關鍵參數：--transfer-timeout（默認值：300秒，即5分鐘）。該參數定義了“等待 Leader 遷移完成”的最大時間。如果在設定的超時時間內，Leader 未能全部遷移完畢，升級程序將強制停止該 TiKV 實例。這可能引發短暫但更明顯的性能波動。

添加 --force（強制立即升級）後，升級命令將跳過 Leader 遷移等待過程，直接停止並重啓 TiKV 實例。優點是升級速度最快，不受 Leader 遷移進度影響。缺點是會導致該 TiKV 實例上的讀寫請求瞬間中斷，由集羣自動進行故障轉移，可能引發明顯的性能抖動。

通過將 --transfer-timeout 設置為一個極大的值（例如 --transfer-timeout 100000000），使升級程序無限期等待，直到所有 Leader 都被安全遷移走，才會執行停止操作。優點是在 Leader 完全驅逐後再操作，對業務性能的影響近乎為零，最為平滑。缺點是如果某些 Leader 因故無法遷移（如副本不足），升級過程可能會一直掛起。適用於對穩定性要求極高、不允許有任何性能抖動的核心生產業務。

• 停機升級：如果業務允許中斷，可以採用更快的離線方式。

tiup cluster stop <cluster-name>                    # 停止集羣
tiup cluster upgrade <cluster-name> v6.1.0 --offline # 離線升級
tiup cluster start <cluster-name>                   # 啓動集羣

步驟5：升級後驗證

升級完成後，必須進行全面的驗證，確保集羣功能和數據完全正常。

1. 集羣狀態驗證：再次運行 tiup cluster check 和 tiup cluster display。
2. 版本與功能驗證：

• 連接數據庫確認版本：SELECT VERSION();
• 檢查所有業務數據庫和表是否正常。
• 運行代表性業務查詢，對比結果。

3. 監控告警檢查：觀察集羣監控（如 Grafana）至少30分鐘，確保無新增錯誤告警，且關鍵指標（QPS、延遲、錯誤率）正常。

升級常見問題與解決方案

問題一：升級過程因報錯中斷，如何恢復？

問題描述：執行升級命令時遇到錯誤導致中斷，在解決問題（如修復配置、釋放磁盤空間等）後，需要繼續完成升級流程。

解決步驟：

1. 查看歷史操作記錄：
   執行以下命令，查看最近的操作日誌，找到那失敗的升級任務所對應的唯一 ID。

tiup cluster audit

1. 重試該次升級操作：
   使用 replay 命令，並指定上一步找到的操作 ID，即可從上次失敗的地方繼續執行升級。

tiup cluster replay <audit-id>

1. 提示：此方法可避免重新開始整個升級流程，節省時間。

問題二：升級 TiKV 時，驅逐 Leader 等待時間過長，如何加速？

問題描述：升級 TiKV 組件時，默認會先將其上的 Region Leader 安全遷移到其他節點，這個過程（evict leader）如果因數據量大或集羣負載高而較慢，會拖長升級時間。

快速升級方案：

• 在執行升級命令時，添加 --force 參數。

tiup cluster upgrade <cluster-name> <version> --force

• 作用：此參數會跳過等待 Leader 驅逐的步驟，直接重啓 TiKV 實例，從而大幅縮短升級耗時。
• 注意：這樣做會導致該 TiKV 節點上的請求處理髮生瞬時中斷，由集羣高可用機制進行故障轉移，可能引起短暫的業務性能抖動。建議在業務可接受的時間窗口內使用。

問題三：集羣升級完成後，如何更新配套的客户端工具版本？

問題描述：集羣（如升級到 v6.1.0）後，pd-ctl、tikv-ctl、tidb-ctl 等周邊命令行工具可能也需要更新到對應版本，以保證兼容性和功能正常。

更新方法：

• 通過 tiup install 命令安裝（或更新）指定版本的 ctl 組件包。該組件包內包含了所有控制工具。

tiup install ctl:v6.1.0

• 操作後：執行上述命令後，pd-ctl 等工具即會更新至 v6.1.0 版本。您可以通過 pd-ctl --version 來驗證版本是否已更新。

備份恢復策略

備份基礎知識

一、 備份的重要性

備份是數據庫管理中的核心任務，主要服務於以下三大目標：

1. 數據庫恢復：在數據丟失、損壞或誤操作後，將數據恢復到可用狀態。
2. 審計與分析：為合規性審計、歷史數據分析或故障排查提供數據快照。
3. 典型的DBA任務：是數據庫管理員（DBA）日常運維和災難恢復計劃中的基礎且關鍵的工作。

二、 備份的三種類型

根據備份期間應用程序對數據的訪問權限，備份可分為以下三類：

詳細説明：

• 熱備份：是併發性最高的備份方式。為了實現不鎖或最小化鎖定，常採用MVCC（多版本併發控制）、行級鎖等技術，允許應用程序在備份期間持續運行。
• 冷備份：通常在數據庫服務關閉或只讀掛載狀態下進行，能確保備份數據的一致性，但需要安排停機窗口。
• 温備份：折中方案。雖然用户可讀取數據，但備份期間的數據修改操作會被阻塞，可能引發性能問題或延遲。

三、 兩種備份技術

根據備份數據的形式，主要分為邏輯備份和物理備份。

物理備份的關鍵條件：
為確保備份數據的一致性，在進行物理備份時必須防止服務器寫入數據文件。常用的技術手段包括：

1. 快照：在瞬間創建數據卷的只讀副本進行備份，對生產系統影響極小。
2. 複製：將數據同步到備用服務器，在備用服務器上進行備份，實現讀寫分離。

根據您提供的圖片“備份恢復技術對比”，我將其中展示的四種TiDB備份恢復方法的核心特性總結如下，以幫助您清晰地理解和選擇：

TiDB 備份恢復技術對比一覽表

TiDB 備份恢復技術決策

數據導出工具 Dumpling

Dumpling 工具原理與適用場景

1. 定義

Dumpling 是一個邏輯數據導出工具，用於將 TiDB 或 MySQL 數據庫中的數據導出為 SQL 或 CSV 格式的文件。它主要用於完成邏輯上的全量備份或數據導出。

2. 架構與核心特點

• 架構：它是一個客户端工具，直接連接到正在運行的 TiDB 數據庫來執行導出任務。
• 核心特點：

• 支持導出 SQL 和 CSV 格式。
• 提供全新的 table-filter 功能，可以方便地篩選要導出的表。
• 支持將數據直接導出到 Amazon S3 等雲存儲。
• 針對 TiDB 進行了專項優化。

3. 適用場景

Dumpling 最適合在以下情況中使用：

1. 中小規模數據導出：適用於數據量較小的場景。因為導出文件為邏輯格式（SQL/CSV），如果文件過大，導出、傳輸和後續導入的成本會很高。
2. 需要邏輯格式的遷移：當需要將數據遷移到異構數據庫（如從 TiDB 遷至其他數據庫）或不同系統時，SQL 或 CSV 是通用格式。
3. 可接受較長的導出時間：由於需要讀取數據並進行格式轉換，其導出效率通常低於物理備份工具（如BR），適合對導出時間要求不高的場景。

4. 不適用場景

Dumpling 不適用於以下情況：

1. 需要物理文件：如果需要直接導出 TiDB 底層的原始鍵值對數據文件（SST 文件），應使用 BR 工具進行物理備份。
2. 需要增量備份：Dumpling 目前只支持全量導出，無法實現增量備份。如需持續增量同步，應使用 TiCDC 工具。
3. 大規模數據快速導出：當數據量大於 50GB 且對時間要求很高時，使用 Dumpling 的效率會很低，成本高昂，此時應優先選擇物理備份。

總結

Dumpling 是 TiDB 生態中重要的邏輯導出工具，在數據量不大、需要跨系統遷移或進行邏輯分析時是理想選擇。但在面對超大規模數據、要求極速備份恢復或需要增量能力的場景時，應選用 BR 或 TiCDC 等其他工具。

Dumpling 工具的使用

部署方式

1. 通過 TiUP 安裝（推薦）：

tiup install dumpling

1. 通過工具包安裝：
   從 TiDB 官方發佈的 tidb-toolkit 安裝包中獲取。

所需數據庫權限

運行 Dumpling 的數據庫用户賬户至少需要以下權限：

• SELECT
• RELOAD
• LOCK TABLES
• REPLICATION CLIENT
• PROCESS

基礎導出命令

1. 導出為 SQL 文件：

dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 200000 -F 256MiB

常用參數説明：

• -u：用户名
• -P：端口
• -h：主機
• --filetype：指定導出格式（sql 或 csv）
• -t：併發線程數
• -o：輸出文件目錄
• -r：每個文件的最大行數
• -F：每個文件的最大大小

1. 導出為 CSV 文件：

dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv

關鍵：通過 --filetype csv 指定格式。

數據篩選（導出部分數據）

Dumpling 提供三種強大的篩選方式：

1. 使用 --where 按行篩選（過濾符合條件的數據行）：

dumpling ... --where 'id < 100'

1. 使用 --filter 按表篩選（支持通配符 *）：

dumpling ... --filter "employees.*" --filter "*.WorkOrder"

示例説明：導出 employees 庫的所有表，以及所有庫中名為 WorkOrder 的表。

1. 使用 -B 或 -T 按庫/表篩選：

# 導出整個數據庫
dumpling ... -B employees
# 導出單張表
dumpling ... -T employees.WorkOrder

導出文件的格式

Dumpling 的輸出文件組織清晰，包含三類文件：

1. Metadata 元數據文件：

• 記錄導出的起始時間、結束時間和Master二進制日誌位置。
• 內容示例：

Started dump at: 2020-11-10 10:40:19
SHOW MASTER STATUS:
    Log: tidb-binlog
    Pos: 420747102018863124
Finished dump at: 2020-11-10 10:40:20

1. Schema 表結構文件（{schema}.{table}-schema.sql）：

• 包含創建該表的 SQL 語句。
• 文件示例：

CREATE TABLE `t1` (
    `id` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

1. Data 數據文件（{schema}.{table}.{0001}.{sql|csv}）：

• 包含實際的數據內容，格式為 SQL 插入語句或 CSV 行。
• SQL 格式文件示例：

/*!40101 SET NAMES binary*/;
INSERT INTO `t1` VALUES(1);

Dumpling 數據導出一致性

Dumpling 通過 --consistency <level> 參數來控制數據導出的一致性保證級別，主要包含以下五種模式：

模式説明與示例

1. Snapshot（快照）模式（TiDB 默認）
這是 TiDB 的默認模式，通過指定一個邏輯時間點來保證數據的一致性視圖。

• 指定 TSO（時間戳）：

./dumpling --snapshot 417773951312461825

• 指定具體時間點：

./dumpling --snapshot "2020-07-02 17:12:45"

如果不指定 --snapshot 參數，Dumpling 會自動獲取導出開始時刻的一致性快照。

2. Flush 模式（適用於MySQL）
此模式通過瞬間的全局鎖來獲取精確的二進制日誌位置，適合用於建立主從複製。

選型與最佳實踐建議

• 對於 TiDB：優先使用默認的 snapshot
• 對於 MySQL 或需要建立複製：可使用 flush
• 需要避免鎖：如果導出操作不允許任何鎖，並且可以接受最終一致性的數據，可以考慮使用 none
• 簡單通用：如果不確定數據庫類型，可以使用 auto

Dumpling 性能優化

為了提升數據導出的速度，Dumpling 提供了兩個關鍵的併發控制參數：

• 總結與操作指南

1. 理解分工：

• -t 參數控制 “表間”併發，適合在需要導出多個表時提升整體效率。
• -r 參數控制 “表內”併發，專門用於解決單個超大表的導出瓶頸。

2. 典型優化命令示例：

# 使用16個線程進行導出，並設置每個文件最多包含50萬行數據，以提升大表導出效率
dumpling -u root -P 4000 -h 127.0.0.1 -t 16 -r 500000 -o /tmp/backup

1. 調整策略：

• 首先根據服務器的 CPU 核心數和數據庫負載 來設置 -t（通常建議從等於或略高於CPU核心數開始嘗試）。
• 如果存在非常大的表，則務必通過 -r 參數啓用表內拆分，值可以根據表的總行數和希望得到的文件大小來決定（例如，一個100億行的表，設置 -r 20000000 會生成大約50個文件進行併發導出）。

使用 TiDB Lightning 導入數據

TiDB Lightning 核心解析

TiDB Lightning 是一個用於將大規模數據快速、高效導入 TiDB 集羣的工具。它支持從 Dumpling 導出的文件、CSV 文件或 Amazon Aurora Parquet 文件讀取數據，並支持從本地磁盤或 Amazon S3 讀取數據源。

一、 兩種導入模式核心對比

TiDB Lightning 提供兩種後端模式，適用於不同場景：

簡要總結：

• 追求速度、初始化空集羣 → 選擇 Physical Import Mode。
• 需要事務保證、向已有表導入、希望業務不停服 → 選擇 Logical Import Mode。

二、 完整工作流程

TiDB Lightning 通過繞過 SQL 層，直接將數據轉換為 Key-Value 鍵值對並導入 TiKV，從而實現極致的導入速度。

Lightning 的數據導入過程是一個流水線作業，主要分為以下幾個階段：

• 準備階段 (Setup):

• 切換導入模式: 將集羣切換至“導入模式”（通常指 Backend 模式，優化寫入性能）。
• Schema & 表創建: 解析數據源的建表語句，在目標 TiDB 集羣中創建數據庫和表結構。

• 數據處理階段 (Process):

• 分割源數據: 讀取數據源（Data Source），將大文件分割為更小的部分以便並行處理。
• 讀取 Dump 文件: 讀取分割後的數據文件（通常是 SQL 或 CSV）。
• 寫入本地臨時文件: 將數據轉換（Encode）為 TiKV 能夠識別的 Key-Value 鍵值對，並排序寫入本地臨時文件（SST 文件）。

• 導入階段 (Ingest):

• 導入臨時文件到 TiKV 集羣: 將生成的 SST 文件直接“Ingest”（加載）到 TiKV 節點中。這是物理導入，速度極快。

• 收尾階段 (Finish):

• 檢驗與分析 (Checksum & Analyze): 對導入的數據進行校驗（Checksum）確保一致性，並運行 ANALYZE TABLE 更新統計信息，確保後續查詢計劃準確。
• 切換普通模式: 導入完成後，將集羣恢復為正常服務的“普通模式”。

Lightning 在整個導入過程中充當了協調者和執行者的角色：

• TiDB Lightning (核心組件):

• 它是獨立的組件，連接數據源和 TiDB 集羣。
• 它負責將原始數據轉換為 TiKV 的底層存儲格式。

• PD Cluster (調度中心):

• Lightning 會與 PD 交互，獲取集羣的 Region 分佈信息。
• 在導入過程中，Lightning 可能會請求 PD 暫停部分調度，以減少導入時的干擾。

• TiKV Cluster (存儲層):

• 關鍵點: Lightning 繞過了 TiDB Server（SQL 解析層），直接與 TiKV 通信。
• 它將處理好的 SST 文件直接發送給各個 TiKV 節點，極大地提高了吞吐量。

• TiDB Cluster (SQL 層):

• 主要用於前期的表結構創建（Schema 階段）和最後的元數據管理，實際的大規模數據寫入不經過它。

總結與關鍵點

• 物理導入 (Physical Import): 圖中展示的是 Lightning 的 Local-backend 模式原理。它的核心在於“先編碼排序，再直接注入”，避免了 SQL 的 INSERT 語句帶來的解析和事務開銷。
• 並行處理: 流程中的“分割源數據”表明 Lightning 支持併發讀取和處理，能夠充分利用機器資源。
• 對在線業務的影響: 由於導入過程涉及“導入模式”切換和大量的 IO/CPU 佔用，這種模式通常建議在初始化集羣或離線遷移時使用。

三、 適用場景

• 快速大量數據初始化：使用 Physical Import Mode，為全新的 TiDB 集羣快速載入數百GB甚至TB級的數據。
• 邏輯備份恢復：使用 Logical Import Mode，將 Dumpling 等工具的邏輯備份文件恢復到 TiDB 集羣。

四、 重要限制

在使用 TiDB Lightning 時，請注意以下限制：

1. 與 TiFlash 共存：如果集羣中存在 TiFlash 副本，導入時間會延長。
2. GBK 字符集：從 TiDB v5.4.0 版本開始，官方才正式支持 GBK 字符集。這意味着，如果你嘗試將包含 CHARACTER SET = GBK定義的表導入到 v5.4.0 之前的 TiDB 集羣中，操作將會失敗
3. Apache Parquet 源文件：TiDB Lightning 主要支持從 Amazon Aurora 數據庫導出的 Apache Parquet 文件。

TiDB Lightning 使用指南

1. 硬件需求

• 部署方式：建議單獨部署，以避免資源競爭。
• CPU 與內存：

• Physical Import Mode (物理導入模式)：需 32 核以上 CPU 與 64 GB 以上內存。
• Logical Import Mode (邏輯導入模式)：需 4 核以上 CPU 與 8 GB 以上內存。

• 存儲：建議獨佔 I/O 並採用閃存等高性能存儲介質。
• 網絡：建議網絡帶寬大於等於 10 Gbps。

2. 前置檢查

在執行導入前，應進行以下檢查：

• 集羣版本/狀態是否正常。
• 是否有權限讀取數據。
• 導入空間是否足夠。
• Region 分佈狀態是否良好。
• 數據文件中是否有大 CSV 文件（可能影響處理效率）。
• 是否可以從斷點恢復（對於中斷的任務）。
• 是否可以導入數據到已存在的數據表中（邏輯模式支持，物理模式要求空表）。
• 導入的目標表是否為空（物理導入模式的強制要求）。

3. 並行導入

為了處理海量數據，TiDB Lightning 支持並行導入以提升吞吐量。

• 工作原理：可以啓動多個 TiDB Lightning 實例，同時處理不同的數據源分片，並行導入到同一個目標 TiDB 集羣。
• 架構示意：多個數據源 (Data source_1...Data source_n) 分別由不同的 Lightning 實例 (TiDB Lightning_1...TiDB Lightning_n) 處理，最終導入到 TiDB 的同一張表中。
• 容量與實例數建議：

• 當總數據量 > 2 TB 時，可啓動多個實例並行處理。
• 並行實例數量建議 < 10 個。

• 重要限制：

1. 並行導入只支持空表。
2. 建議使用 Physical Import Mode 模式以獲得最佳性能。
3. 不可同時使用 Physical Import Mode 和 Logical Import Mode 導入同一 TiDB 集羣。

4. 獲取安裝包

有兩種主要方式獲取 TiDB Lightning：

• 方法一（推薦）：使用 TiUP 包管理器安裝。

tiup install lightning

• 方法二：從 TiDB-community-toolkit 軟件包中獲取。

5. 配置

配置通過 TOML 格式的文件完成，主要區塊包括：

[lightning]
# 數據轉換的併發數，默認為邏輯CPU數。混合部署時可設為邏輯CPU的75%。
# region-concurrency = 
level = "info"  # 日誌級別
file = "tidb-lightning.log"  # 日誌文件

[tikv-importer]
backend = "local"  # 設置為 local 模式（即物理導入模式）
sorted-kv-dir = "/mnt/ssd/sorted-kv-dir"  # 本地臨時存儲路徑，必須為空且容量足夠

[mydumper]
data-source-dir = "/data/my_database"  # 源數據所在的目錄

[tidb]
# 目標 TiDB 集羣連接信息
host = "172.16.31.1"
port = 4000
user = "root"
password = ""
status-port = 10080  # 用於獲取表結構信息
pd-addr = "172.16.31.4:2379"  # PD 服務地址

6. 啓動與退出

• 啓動：使用 nohup 命令在後台運行 TiDB Lightning。

#!/bin/bash
nohup ./tidb-lightning -config tidb-lightning.toml > nohup.out &

• 退出：程序運行結束後自動退出。如需中斷，可使用 Ctrl+C 或發送終止信號。

7. 數據過濾

可以僅導入指定的表，過濾規則支持通配符 *。

• 通過命令行參數指定：

./tidb-lightning -f 'foo*.*' -f 'bar*.*' -d /tmp/data/

• 通過配置文件指定：

[mydumper]
filter = ['foo*.*', 'bar*.*']

• 以上兩種方式均表示：導入所有以 foo 或 bar 開頭的數據庫中的任意表。

8. 斷點續傳

此功能可在任務意外中斷後，重啓時跳過已導入的數據，避免重複工作。

[checkpoint]
enable = true  # 啓用斷點續傳
driver = "file"  # 斷點存儲方式，可選 "file"（本地文件）或 "mysql"（數據庫）
# 當 driver = "mysql" 時，需配置數據庫連接參數 (DSN)
# 為避免給目標 TiDB 集羣增加壓力，建議使用單獨的 MySQL 兼容數據庫存儲斷點。
# dsn = "user:password@tcp(127.0.0.1:4000)/"

keep-after-success = false  # 導入成功後是否保留斷點，默認為 false（刪除），調試時可設為 true

當啓用斷點續傳功能後，如果導入任務因某些表的錯誤而中斷，您可以使用 tidb-lightning-ctl 工具執行以下命令來修復：

參數説明：

• {schema}.{table}：指定具體的數據庫名和表名（例如 mydb.mytable）。
• all：一個特殊參數，表示對所有因錯誤而中斷的表執行該操作。

使用示例：

1. 重置並重試單張表 (test.users 表因錯誤中斷)：

tidb-lightning-ctl --checkpoint-error-destroy='test.users'

1. 忽略所有表的錯誤（繼續執行，跳過所有出錯表）：

tidb-lightning-ctl --checkpoint-error-ignore=all

1. 清除單張表的檢查點（讓其下次完全重新開始）：

tidb-lightning-ctl --checkpoint-remove='test.orders'

使用 BR 進行備份恢復

一、BR 原理與特性

BR 是 TiDB 的備份恢復工具，其核心特點與工作原理如下：

1. 核心特性：BR 支持熱備份、物理備份，並具備增量備份與恢復、數據對象備份與恢復、遠程備份及備份數據加密等功能。
2. 工作原理：

• 備份流程：BR 組件連接到 TiDB 集羣，繞過TIDB Server,直接問PD數據所在位置，從 TiKV 節點直接讀取底層數據，並將其打包為特定格式文件，存儲到本地路徑或外部存儲（External Storage，如 S3、NAS）中。
• 恢復流程：BR 從外部存儲讀取備份文件，繞過 SQL 層，直接將數據文件“注入”到 TiKV 存儲引擎中，實現高速恢復。

二、適用場景

BR 主要適用於以下場景：

• 常規的一致性備份恢復：需要為整個集羣或指定數據庫/表創建一致性快照備份。
• 大規模數據快速遷移：當數據量龐大（如TB級）且遷移時間窗口有限時，BR 的物理備份恢復速度遠超邏輯工具。
• 專用於 TiDB 的數據恢復：備份文件為 TiDB 專用格式，只能恢復到 TiDB 數據庫中。

備份輸出文件：
備份完成後，在外部存儲中會生成以下核心文件：

• SST 文件：存儲實際表數據的鍵值對文件。
• backupmeta 文件：存儲本次備份的元信息，如備份集合、備份時間、數據庫架構。
• backup.lock 文件：用於防止多個備份操作同時寫入同一位置。

三、物理備份與邏輯備份對比

四、重要限制與注意事項

使用 BR 前，必須瞭解以下關鍵限制：

1. 字符集 GBK 兼容性：無法將字符集為 GBK 的表恢復到 v5.4.0 之前的 TiDB 集羣。
2. 功能兼容性問題：備份與恢復時，需確保集羣的特定功能開關狀態一致，否則可能導致表結構或數據不一致。需特別注意：

• 聚簇索引 (tidb_enable_clustered_index)
• 新排序規則 (new_collations_enabled_on_first_bootstrap)
• 全局臨時表 (BR v5.3.0 開始支持)
• 使用 check-requirements 命令檢查版本兼容性，check-requirements可設置為False跳過版本檢查

3. 與增量同步工具不兼容：通過 BR 恢復的數據，無法通過 TiCDC 或 TiDB Binlog 同步到下游。因為 BR 恢復的數據不會產生邏輯變更日誌。如果下游需要這些數據，必須在恢復完成後重新進行全量同步。