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

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

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

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

tiup cluster check name>

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

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

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

1.3 升級 TiDB 集群

tiup cluster upgrade  

tiup cluster upgrade <cluster-name> v5.1.2

注意：

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

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

2.1 擴容 TiDB/PD/TiKV 節(jié)點

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 執(zhí)行擴容命令

tiup cluster scale-out  scale-out.yaml

2.2 擴容 TiFlash 節(jié)點

2.2.1 添加節(jié)點信息到 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 節(jié)點

2.3.1 添加節(jié)點信息到 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 節(jié)點

2.4.1 查看節(jié)點 ID 信息

tiup cluster display 

2.4.2 執(zhí)行縮容操作

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

2.4.3 檢查集群狀態(tài)

tiup cluster display 

2.5.1 根據(jù) TiFlash 剩余節(jié)點數(shù)調整數(shù)據(jù)表的副本數(shù)

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

2.5.2 執(zhí)行縮容操作

tiup cluster display 

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

2.6 縮容 TiCDC 節(jié)點

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

3.1 BR備份恢復

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

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

1) 推薦部署配置

2) 備份數(shù)據(jù)

• 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) 恢復數(shù)據(jù)

• i) 恢復全部備份數(shù)據(jù)

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

• ii) 恢復單個數(shù)據(jù)庫的數(shù)據(jù)

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

• iii) 恢復單張表的數(shù)據(jù)

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

• iv) 使用表庫功能過濾恢復數(shù)據(jù)

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：創(chuàng)建 schema 的 SQL 文件。

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

• {schema}.{table}-schema.sql：創(chuàng)建 table 的 SQL 文件。

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

• {schema}.{table}.{0001}.{sql|csv}：數(shù)據(jù)源文件。

/*!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:用于指定導出的線程數(shù)。增加線程數(shù)會增加 Dumpling 并發(fā)度提高導出速度，但也會加大數(shù)據(jù)庫內存消耗，因此不宜設置過大。
• -r:用于指定單個文件的最大行數(shù)，指定該參數(shù)后 Dumpling 會開啟表內并發(fā)加速導出，同時減少內存使用。
• -F:選項用于指定單個文件的最大大小（單位為 MiB，可接受類似 5GiB 或 8KB 的輸入）。
• --filter:表庫過濾。

參數(shù)列表：

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

參數(shù)列表：

backend各模式區(qū)別：

4.1 誤drop庫

1) 確認刪除時間

2) 確認數(shù)據(jù)的有效性

3) 備份數(shù)據(jù)

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) 恢復數(shù)據(jù)

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

1) 確認操作時間

2) 將數(shù)據(jù)寫入到臨時表

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) 確認數(shù)據(jù)的有效性

3) 備份數(shù)據(jù)

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) 恢復數(shù)據(jù)

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 目錄下執(zhí)行 tar xzvf tiup.tar.gz。
• iii) 添加 .tiup 目錄到 PATH 環(huán)境變量。

5.2 中控沒有備份

恢復方法：

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

5.3 注意事項

• ssh互信

  新的中控節(jié)點，必須要包括和各個節(jié)點網(wǎng)絡都是通的，并且ssh也是互通的。

• 網(wǎng)絡互通

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

6.1 集群狀態(tài)

1) 實例

2) 主機

3) 磁盤

4) 存儲拓撲

5) 監(jiān)控告警

6.2 Sql語句

• 統(tǒng)計選項

6.3 慢查詢

6.4 流量可視化

6.5 集群診斷報告