點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了?。?！

接上篇《TiDB運維文檔（上）》，我們今天講一下TIDB數據庫的日常運維。

1.1 升級 TiUP 或更新 TiUP 離線鏡像

1.2 檢查當前集群的健康狀況

tiup cluster check name>

執行結束后，最后會輸出 region status 檢查結果。

• 如果結果為 "All regions are healthy"，則說明當前集群中所有 region 均為健康狀態，可以繼續執行升級；

• 如果結果為 "Regions are not fully healthy: m miss-peer, n pending-peer" 并提示 "Please fix unhealthy regions before other operations."，則說明當前集群中有 region 處在異常狀態，應先排除相應異常狀態，并再次檢查結果為 "All regions are healthy" 后再繼續升級。

1.3 升級 TiDB 集群

tiup cluster upgrade  

tiup cluster upgrade <cluster-name> v5.1.2

注意：

• a) 滾動升級會逐個升級所有的組件。升級 TiKV 期間，會逐個將 TiKV 上的所有 leader 切走再停止該 TiKV 實例。默認超時時間為 5 分鐘（300 秒），超時后會直接停止該實例。
• b) 如果不希望驅逐 leader，而希望快速升級集群至新版本，可以在上述命令中指定 --force，該方式會造成性能抖動，不會造成數據損失。

• c) 如果希望保持性能穩定，則需要保證 TiKV 上的所有 leader 驅逐完成后再停止該 TiKV 實例，可以指定 --transfer-timeout 為一個更大的值，如 --transfer-timeout 3600，單位為秒。

2.1 擴容 TiDB/PD/TiKV 節點

2.1.1 在 scale-out.yaml 文件添加擴容拓撲配置

• TiDB 配置文件參考：

tidb_servers:
- 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

• TiKV 配置文件參考：

tikv_servers:
- host: 10.0.1.5
ssh_port: 22
port: 20160
status_port: 20180
deploy_dir: /data/deploy/install/deploy/tikv-20160
data_dir: /data/deploy/install/data/tikv-20160
log_dir: /data/deploy/install/log/tikv-20160

• PD 配置文件參考：

pd_servers:
- host: 10.0.1.5
ssh_port: 22
name: pd-1
client_port: 2379
peer_port: 2380
deploy_dir: /data/deploy/install/deploy/pd-2379
data_dir: /data/deploy/install/data/pd-2379
log_dir: /data/deploy/install/log/pd-2379

2.1.2 執行擴容命令

tiup cluster scale-out  scale-out.yaml

2.2 擴容 TiFlash 節點

2.2.1 添加節點信息到 scale-out.yaml 文件

tiflash_servers:
- host: 10.0.1.4

2.2.2 運行擴容命令

tiup cluster scaltiup cluster scale-out  
scale-out.yamle-out  scale-out.yaml

2.3 擴容 TiCDC 節點

2.3.1 添加節點信息到 scale-out.yaml 文件

cdc_servers:
- host: 10.0.1.3
- host: 10.0.1.4

2.3.2 運行擴容命令

tiup cluster scale-out  scale-out.yaml

2.4 縮容 TiDB/PD/TiKV 節點

2.4.1 查看節點 ID 信息

tiup cluster display 

2.4.2 執行縮容操作

tiup cluster scale-in <cluster-name> --node 10.0.1.5:20160

2.4.3 檢查集群狀態

tiup cluster display 

2.5.1 根據 TiFlash 剩余節點數調整數據表的副本數

alter table name>.<table-name> set tiflash replica 0;

2.5.2 執行縮容操作

tiup cluster display 

tiup cluster scale-in <cluster-name> --node 10.0.1.4:9000

2.6 縮容 TiCDC 節點

tiup cluster scale-in <cluster-name> --node 10.0.1.4:8300

3.1 BR備份恢復

備份路徑下會生成以下幾種類型文件：

• SST 文件：存儲 TiKV 備份下來的數據信息。
• backupmeta 文件：存儲本次備份的元信息，包括備份文件數、備份文件的 Key 區間、備份文件大小和備份文件 Hash (sha256) 值。
• backup.lock 文件：用于防止多次備份到同一目錄。

1) 推薦部署配置

2) 備份數據

• i) 備份全庫

br backup full 
--pd "${PDIP}:2379" 
--storage "local:///tmp/backup" 
--ratelimit 128 
--log-file backupfull.log

• ii) 備份單庫

br backup db 
--pd "${PDIP}:2379" 
--db test 
--storage "local:///tmp/backup" 
--ratelimit 128 
--log-file backuptable.log

• iii) 備份單表

br backup table 
--pd "${PDIP}:2379" 
--db test 
--table usertable 
--storage "local:///tmp/backup" 
--ratelimit 128 
--log-file backuptable.log

• iv) 使用表庫功能過濾備份多表

br backup full 
--pd "${PDIP}:2379" 
--filter db*.tbl* 
--storage "local:///tmp/backup" 
--ratelimit 128 
--log-file backupfull.log

3) 恢復數據

• i) 恢復全部備份數據

br restore full 
--pd "${PDIP}:2379" 
--storage "local:///tmp/backup" 
--ratelimit 128 
--log-file restorefull.log

• ii) 恢復單個數據庫的數據

br restore db 
--pd "${PDIP}:2379" 
--db "test" 
--ratelimit 128 
--storage "local:///tmp/backup" 
--log-file restorefull.log

• iii) 恢復單張表的數據

br restore table 
--pd "${PDIP}:2379" 
--db "test" 
--table "usertable" 
--ratelimit 128 
--storage "local:///tmp/backup" 
--log-file restorefull.log

• iv) 使用表庫功能過濾恢復數據

br restore full 
--pd "${PDIP}:2379" 
--filter db*.tbl* 
--storage "local:///tmp/backup" 
--log-file restorefull.log

3.2 TiCDC異地庫備份

3.3 DumplingTiDB Lightning備份恢復

輸出文件格式:

• metadata：此文件包含導出的起始時間，以及 master binary log 的位置。

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

• {schema}-schema-create.sql：創建 schema 的 SQL 文件。

CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;

• {schema}.{table}-schema.sql：創建 table 的 SQL 文件。

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

• {schema}.{table}.{0001}.{sql|csv}：數據源文件。

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

1) 備份工具Dumpling

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

• --filetype:導出文件類型，sql|csv。
• -o:用于選擇存儲導出文件的目錄。
• -t:用于指定導出的線程數。增加線程數會增加 Dumpling 并發度提高導出速度，但也會加大數據庫內存消耗，因此不宜設置過大。
• -r:用于指定單個文件的最大行數，指定該參數后 Dumpling 會開啟表內并發加速導出，同時減少內存使用。
• -F:選項用于指定單個文件的最大大小（單位為 MiB，可接受類似 5GiB 或 8KB 的輸入）。
• --filter:表庫過濾。

參數列表：

2) 恢復工具Tidb Lightning

tidb-lightning --config cfg.toml --backend tidb -tidb-
host 127.0.0.1 -tidb-user root --tidb-password passwd -
tidb-port 4000 -d /home/tidb/bakfile/9

Local-backend 工作原理：

TiDB Lightning 整體工作原理如下：

• i) 在導入數據之前，tidb-lightning 會自動將 TiKV 集群切換為“導入模式” (import mode)，優化寫入效率并停止自動壓縮。
• ii) tidb-lightning 會在目標數據庫建立架構和表，并獲取其元數據。
• iii) 每張表都會被分割為多個連續的區塊，這樣來自大表 (200 GB+) 的數據就可以用增量方式并行導入。
• iv) tidb-lightning 會為每一個區塊準備一個“引擎文件 (engine file)”來處理鍵值對。tidb-lightning 會并發讀取 SQL dump，將數據源轉換成與 TiDB 相同編碼的鍵值對，然后將這些鍵值對排序寫入本地臨時存儲文件中。
• v) 當一個引擎文件數據寫入完畢時，tidb-lightning 便開始對目標 TiKV 集群數據進行分裂和調度，然后導入數據到 TiKV 集群。
• vi) 引擎文件包含兩種：數據引擎與索引引擎，各自又對應兩種鍵值對：行數據和次級索引。通常行數據在數據源里是完全有序的，而次級索引是無序的。因此，數據引擎文件在對應區塊寫入完成后會被立即上傳，而所有的索引引擎文件只有在整張表所有區塊編碼完成后才會執行導入。
• vii) 整張表相關聯的所有引擎文件完成導入后，tidb-lightning 會對比本地數據源及下游集群的校驗和 (checksum)，確保導入的數據無損，然后讓 TiDB 分析 (ANALYZE) 這些新增的數據，以優化日后的操作。同時，tidb-lightning 調整 AUTO_INCREMENT 值防止之后新增數據時發生沖突。
• viii) 表的自增 ID 是通過行數的上界估計值得到的，與表的數據文件總大小成正比。因此，最后的自增 ID 通常比實際行數大得多。這屬于正?，F象，因為在 TiDB 中自增 ID 不一定是連續分配的。
• viiii) 在所有步驟完畢后，tidb-lightning 自動將 TiKV 切換回“普通模式” (normal mode)，此后 TiDB 集群可以正常對外提供服務。

參數列表：

backend各模式區別：

4.1 誤drop庫

1) 確認刪除時間

2) 確認數據的有效性

3) 備份數據

dumpling -h 172.21.xx.xx -P 4000 -uroot -p xxx -t 32 -F 64MiB -B xxx_ods --snapshot "2020-11-17 08:26:35" -o ./da

4) 恢復數據

myloader -h 172.21.xx.xx -u root -P 4000 -t 32 -d ./da -p xxx

1) 確認操作時間

2) 將數據寫入到臨時表

FLASHBACK TABLE xxx_comment TO xxx_comment_bak_20201117;

drop table xxx_comment ;
rename table xxx_comment_bak_20201117 to xxx_comment;

insert into xxx_comment select * from xxx_comment_bak_20201117;

1) 確認操作時間

2) 恢復表

RECOVER TABLE xxx_comment ;

4.4 誤 delete、update表

1) 確認操作時間

2) 確認數據的有效性

3) 備份數據

dumpling -h 172.21.xx.xx -P 4000 -uroot -p xxx -t 32 -F 
64MiB -B xxx_ods -T xxx_ods.xxx_comment --snapshot "2020-
11-17 09:55:00" -o ./da

4) 恢復數據

myloader -h 172.21.xx.xx -u root -P 4001 -t 32 -d ./da -p xxx

5.1 中控有備份

1) 中控備份

2) 恢復方法

• i) 把 tiup.tar.gz 拷貝到目標機器home目錄。
• ii) 在目標機器 home 目錄下執行 tar xzvf tiup.tar.gz。
• iii) 添加 .tiup 目錄到 PATH 環境變量。

5.2 中控沒有備份

恢復方法：

• i) 在新的中控機器上，重新部署tiup。
• ii) 根據運行的集群組件，重新配置一個集群的拓撲文件。
• iii) 執行deploy命令：tiup cluster deploy tidb-xxx ./topology.yaml。
• iv) 執行完成之后，不需要start集群，因為集群本身是在運行的，執行display查看一下集群的節點狀態即可。

5.3 注意事項

• ssh互信

  新的中控節點，必須要包括和各個節點網絡都是通的，并且ssh也是互通的。

• 網絡互通

  無論是通過備份恢復還是重新編寫拓撲配置文件在新的節點恢復中控，如果恢復完成后，查看集群的節點狀態顯示down或N/A的狀態，請檢查新的中控節點和集群各節點之間的網絡是否是通的。

6.1 集群狀態

1) 實例

2) 主機

3) 磁盤

4) 存儲拓撲

5) 監控告警

6.2 Sql語句

• 統計選項

6.3 慢查詢

6.4 流量可視化

6.5 集群診斷報告