天天看點
傳回

TiDB 操作實踐 -- 備份與恢複

作者： G7尹裕皓 ​

前言

這幾天在整理我的檔案的時候，發現這篇半年前寫的備份恢複的筆記。

這個筆記是參照官方文檔做的實踐，并結合了自己的一些了解寫出來的，感覺還有點用處，另外也是怕存到本地檔案丢了，是以還是發一下吧，供各位參考。

操作

本次所有步驟都在tidb使用者下操作

本次操作叢集結構：

Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.8.0/tiup-cluster display tidb-test
Cluster type:       tidb
Cluster name:       tidb-test
Cluster version:    v5.1.0
Deploy user:        tidb
SSH type:           builtin
Dashboard URL:      http://172.24.74.69:2379/dashboard
ID                  Role          Host          Ports        OS/Arch       Status  Data Dir                           Deploy Dir
--                  ----          ----          -----        -------       ------  --------                           ----------
172.24.74.68:9093   alertmanager  172.24.74.68  9093/9094    linux/x86_64  Up      /tidb/tidb-data/alertmanager-9093  /tidb/tidb-deploy/alertmanager-9093
172.24.74.68:3000   grafana       172.24.74.68  3000         linux/x86_64  Up      -                                  /tidb/tidb-deploy/grafana-3000
172.24.74.67:2379   pd            172.24.74.67  2379/2380    linux/x86_64  Up|L    /tidb/tidb-data/pd-2379            /tidb/tidb-deploy/pd-2379
172.24.74.68:2379   pd            172.24.74.68  2379/2380    linux/x86_64  Up      /tidb/tidb-data/pd-2379            /tidb/tidb-deploy/pd-2379
172.24.74.69:2379   pd            172.24.74.69  2379/2380    linux/x86_64  Up|UI   /tidb/tidb-data/pd-2379            /tidb/tidb-deploy/pd-2379
172.24.74.67:9090   prometheus    172.24.74.67  9090         linux/x86_64  Up      /tidb/tidb-data/prometheus-9090    /tidb/tidb-deploy/prometheus-9090
172.24.74.67:4000   tidb          172.24.74.67  4000/10080   linux/x86_64  Up      -                                  /tidb/tidb-deploy/tidb-4000
172.24.74.68:4000   tidb          172.24.74.68  4000/10080   linux/x86_64  Up      -                                  /tidb/tidb-deploy/tidb-4000
172.24.74.69:4000   tidb          172.24.74.69  4000/10080   linux/x86_64  Up      -                                  /tidb/tidb-deploy/tidb-4000
172.24.74.67:20160  tikv          172.24.74.67  20160/20180  linux/x86_64  Up      /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
172.24.74.68:20160  tikv          172.24.74.68  20160/20180  linux/x86_64  Up      /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
172.24.74.69:20160  tikv          172.24.74.69  20160/20180  linux/x86_64  Up      /tidb/tidb-data/tikv-20160         /tidb/tidb-deploy/tikv-20160
Total nodes: 12

部署工具包

工具包建議部署在PD節點

工具包中包含的工具：br dumpling mydumper pd-tso-bench sync_diff_inspector tidb-lightning tidb-lightning-ctl tikv-importer

本次步驟在tidb使用者下的home目錄執行

下載下傳工具包 

wget https://download.pingcap.org/tidb-toolkit-v5.0.1-linux-amd64.tar.gz

解壓工具包，得到工具包目錄 

tar xvf tidb-toolkit-v5.0.1-linux-amd64.tar.gz

将工具包目錄配置到環境變量

打開環境變量配置檔案

vi ~/.bash_profile

追加以下内容

export PATH=/home/tidb/tidb-toolkit-v5.0.1-linux-amd64/bin:$PATH

儲存後source指令使環境變量生效

source ~/.bash_profile

BR

備份

BR工具備份推薦使用共享存儲，本次條件有限，使用本地存儲操作

全庫備份

在所有tikv節點建立備份目錄并修改備份目錄權限

mkdir /tidb/backup/20211214
chmod 755 /tidb/backup/20211214

在br工具包的安裝節點，如本次的pd節點172.24.74.67，執行備份指令：

br backup full --pd "172.24.74.67:2379" --storage "local:///tidb/backup/20211214" --ratelimit 120 --log-file backupfull.log      
參數解釋：
--pd : 任意pd節點id
--storage ：tikv節點的備份目錄，需保證目錄存在且為空 ，否則會報錯
--ratelimit ： 帶寬限速，120即為120M/S
--log-file ： 備份日志存放檔案

備份成功會得到`Full backup success summary`字樣的提示

單庫備份

在所有tikv節點建立備份目錄，并修改目錄權限

mkdir /tidb/backup/20211214-yyh
chmod 755 /tidb/backup/20211214-yyh

開始備份，指定庫備份較全庫備份略有變化

br backup db --pd "172.24.74.67:2379" --db yyh --storage "local:///tidb/backup/20211214-yyh" --ratelimit 120 --log-file backupdb.log      
參數解釋：
--db ：備份的庫

備份成功會得到`Full backup success summary`字樣的提示

單表備份

在所有tikv節點建立備份目錄，并修改目錄權限

mkdir /tidb/backup/20211214-test2
chmod 755 /tidb/backup/20211214-test2

開始備份，指定庫備份較全庫備份略有變化

br backup table --pd "172.24.74.67:2379" --db yhh --table test1 --storage "local:///tidb/backup/20211214-test2" --ratelimit 120 --log-file backuptable.log      
參數解釋：
--table ：備份的表

備份成功會得到`Full backup success summary`字樣的提示

恢複

本次條件有限，使用本地存儲操作，恢複時需将所有節點的備份合并，再分發到所有節點的備份目錄中

最優方案是共享存儲，可不用合并分發的操作直接恢複，因為備份時就備到了同一個目錄中

将本次需要恢複的所有節點上的備份合并到一個節點上

本例為全備份（單庫單表恢複同樣操作），合并到172.24.74.67 
cd /tidb/backup/20211214
scp 172.24.74.68:/tidb/backup/20211214/* .
scp 172.24.74.69:/tidb/backup/20211214/* .

将合并好的備份分發到所有節點原有位置

scp * 172.24.74.68:/tidb/backup/20211214/.
scp * 172.24.74.69:/tidb/backup/20211214/.

個人實驗結論：

隻要備份中包含需要恢複的對象，就可以選擇全部恢複或者隻恢複部分，如：備份為全備，可隻恢複yyh單庫，或者yhh庫的test單表

且無論備份指令是full、db、table，隻要保證備份集中有自己需要的對象，恢複時均可用full、db、table中的任意一個指令恢複的對象現在的狀态必須是不存在或者空的，否則會跳過，切最終結果會提示恢複錯誤。

舉個栗子：t1被删了，t2被清空了，t3還有資料，這種情況隻會恢複t1和t2，t3會跳過

全庫恢複

執行恢複指令

br restore full --pd "172.24.74.67:2379" --storage "local:///tidb/backup/20211214" --log-file restoredb.log

恢複成功會得到​

​Full backup success summary​

​字樣的提示，随後可進入mysql環境驗證恢複情況

單庫恢複

執行恢複指令

br restore db --pd "172.24.74.67:2379" --db yyh --storage "local:///tidb/backup/20211214-yyh" --log-file restoredb.log
參數說明： --db 參數隻能指定一個庫

恢複成功會得到​

​Full backup success summary​

​字樣的提示，随後可進入mysql環境驗證恢複情況

單表恢複

執行恢複指令

br restore table --pd "172.24.74.67:2379" --db yhh --table test2 --storage "local:///tidb/backup/20211214-test2" --log-file restoredb.log
參數說明： --db --table 隻能指定到一個庫的一個表

恢複成功會得到​

​Full backup success summary​

​字樣的提示，随後可進入mysql環境驗證恢複情況

指定對象恢複

執行恢複指令，本方法時full恢複指令的專有方法，db和table都沒有

例1： 恢複yyh庫中的所有表
br restore full --pd "172.24.74.67:2379" --filter yyh.* --storage "local:///tidb/backup/20211214" --log-file restoredb.log

例2： 恢複所有y開頭的庫中的test1表
br restore full --pd "172.24.74.67:2379" --filter y*.test1 --storage "local:///tidb/backup/20211214" --log-file restoredb.log

恢複成功會得到​

​Full backup success summary​

​字樣的提示，随後可進入mysql環境驗證恢複情況

Dumpling & Lightning

Dumpling:把存儲在 TiDB 或 MySQL 中的資料導出為 SQL 或 CSV 格式，用于邏輯全量備份

Lightning:是一個将全量資料高速導入到 TiDB 叢集的工具，可導入 ​​Dumpling​​​、CSV 或 ​​Amazon Aurora Parquet​​ 輸出格式的資料源

Dumpling

全量導出 

dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB

參數說明：

​

​-h​

​​、​

​-P​

​​、​

​-u​

​​ 、​

​-p​

​​分别代表連接配接tidb-server（任意一個）的位址、端口、使用者、密碼。如果沒有密碼，就去掉​

​-p​

​參數

​

​-o​

​ 用于選擇存儲導出檔案的目錄。可以是任意層級的目錄，隻要有上層目錄的操作權限就行

​

​-t​

​ 用于指定導出的線程數。增加線程數會增加 Dumpling 并發度提高導出速度，但也會加大資料庫記憶體消耗，是以不宜設定過大。一般不超過 64。

​

​-r​

​ 用于指定單個檔案的最大行數，指定該參數後 Dumpling 會開啟表内并發加速導出，同時減少記憶體使用。

​

​-F​

​​ 選項用于指定單個檔案的最大大小，機關為 ​

​MiB​

​​，可接受類似 ​

​5GiB​

​​ 或 ​

​8KB​

​​ 的輸入。如果你想使用 TiDB Lightning 将該檔案加載到 TiDB 執行個體中，建議将 ​

​-F​

​ 選項的值保持在 256 MiB 或以下

​

​--filetype​

​ 參數預設是sql，可選參數值 sql，csv。如導出sql可不指定本參數

帶sql條件導出 

dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype csv \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  --sql 'select * from yyh.test1 where id < 1000'

參數說明

​

​--sql​

​中寫查詢語句，本次隻導出你的查詢結果。本參數隻适用于導出csv格式

帶篩選條件導出

  • 使用​

    ​--where​

     ​ 選項篩選資料 
dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  --where 'id < 1000'

參數說明： ​

​--where​

​​ 本次條件即為導出所有表id<1000的值，本參數不可與​

​--sql​

​ 同時使用，導出格式可選sql和csv

  • 使用​

    ​--filter​

     ​ 選項篩選資料 
dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  --filter "yyh.*" \
  --filter "*.test1"

參數說明： ​

​--filter​

​​ 篩選需要的庫或表，上例表示導出yyh庫下所有表和所有庫中的test1表。可以和​

​--where​

​共用

  • 使用​

    ​-B​

     ​​ 或​

    ​-T​

     ​ 選項篩選資料 
dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  -B "yyh" \
  -B "yhh"      
dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  -T "yhh.test1" \
  -T "yyh.test1" \
  --where "id < 100"

參數說明： ​

​-B​

​​ 指定表導出的庫，如需導出多個庫，則指定多個​

​-B​

​​參數。參數值不支援模糊比對，如​

​yy*​

​​ ​

​-T​

​​ 指定導出的表，如需導出多個表，則指定多個​

​-T​

​​參數。同樣不支援模糊比對 ​

​-B​

​​ 、 ​

​-T​

​​、​

​--filter​

​​ 三個參數互斥，無法同時使用，即隻能選擇其中一個參數使用；三個參數都可與​

​--where​

​共用

導出曆史資料快照 

dumpling \
  -u root \
  -p root123\
  -P 4000 \
  -h 172.24.74.67 \
  --filetype sql \
  -t 8 \
  -o /tidb/backup/dumpbak \
  -r 200000 \
  -F 256MiB \
  --snapshot "2021-12-15 19:03:45"

參數說明：

​

​--snapshot​

​​ 可導出曆史版本資料，如上方指定的時間，還可以使用TSO（​

​SHOW MASTER STATUS​

​​ 輸出的 ​

​Position​

​ 字段），但前提條件是曆史版本還沒有GC。可以和其他參數共用。

Lightning

Lightning工具建議獨立部署，原因是比較吃硬體資源，混合部署容易影響其他業務

操作步驟

配置tidb-lightning.toml

恢複前請确認好各參數，特别是​

​backend​

 ​參數 
[lightning]
# 轉換資料并發數，預設為邏輯cpu數量，獨立部署可不用設定本參數，混合部署建議設定為邏輯cpu的75%
# region-concurrency = 

# 日志
level = "info"
file = "tidb-lightning.log"

[tikv-importer]
# 選擇使用的 local 後端模式 ,需根據需求調整模式
# 也可在指令行用參數方式指定，如：tidb-lightning -d /tmp/data --backend tidb
backend = "local"
# 設定排序的鍵值對的臨時存放位址，目标路徑需要是一個有權限的空目錄
sorted-kv-dir = "/tmp/sorted-kv-dir"

[checkpoint]
# 啟用斷點續傳，導入時會記錄目前進度
enable = true
# 斷點存儲方式，可選本地檔案（file）或者mysql伺服器（mysql），這裡以本地檔案作為參數
# 
driver = "file"
# 斷點的存放位置
#
# 若 driver = "file"，此參數為斷點資訊存放的檔案路徑。
# 如果不設定該參數則預設為 `/tmp/CHECKPOINT_SCHEMA.pb`
#
# 若 driver = "mysql"，此參數為資料庫連接配接參數 (DSN)，格式為“使用者:密碼@tcp(位址:端口)/”。
# 預設會重用 [tidb] 設定目标資料庫來存儲斷點。
# 為避免加重目标叢集的壓力，建議另外使用一個相容 MySQL 的資料庫伺服器。
dsn = "/tmp/tidb_lightning_checkpoint.pb"

[mydumper]
# 源資料目錄。
data-source-dir = "/tidb/backup/dumpbak"

# 配置通配符規則，預設規則會過濾 mysql、sys、INFORMATION_SCHEMA、PERFORMANCE_SCHEMA、METRICS_SCHEMA、INSPECTION_SCHEMA 系統資料庫下的所有表
# 也可通過指令行參數方式指定，如：tidb-lightning -f 'yyh.*' -f 'test*.test1' -d /tmp/data --backend tidb
filter = ['yyh.*','test*.test1']

[tidb]
# 目标叢集的資訊
host = "172.24.74.67"
port = 4000
user = "root"
password = "root123"
# 表架構資訊在從 TiDB 的“狀态端口”擷取。
status-port = 10080
# 叢集 pd 的位址
pd-addr = "172.24.74.67:2379"

後端模式對比：

後端 Local-backend Importer-backend TiDB-backend
速度 快 (~500 GB/小時) 快 (~400 GB/小時) 慢 (~50 GB/小時)
資源使用率 高 高 低
占用網絡帶寬 高 中 低
導入時是否滿足 ACID 否 否 是
目标表 必須為空 必須為空 可以不為空
額外元件 無 ​

​tikv-importer​

 ​ 		無
支援 TiDB 叢集版本 >= v4.0.0 全部 全部
是否影響 TiDB 對外提供服務 是 是 否

執行恢複

nohup tidb-lightning -config tidb-lightning.toml > nohup.out &
導入完畢後，TiDB Lightning 會自動退出。若導入成功，日志的最後一行會顯示 ​

​tidb lightning exit​

 ​。

導入中斷切回正常模式

lightning導入前會将tikv叢集切換為導入模式，優化寫入效率并停止自動壓縮，叢集将無法正常對外提供服務。如果導入異常中斷不會自動切回正常模式，此時需要手動操作切回

tidb-lightning-ctl --switch-mode=normal

切回正常模式後再去排查并解決異常，後續導入如需斷點續傳請參考下一步操作

斷點續傳的控制

若 ​

​tidb-lightning​

​​ 因不可恢複的錯誤而退出（例如資料出錯），重新開機時不會使用斷點，而是直接報錯離開。為保證已導入的資料安全，這些錯誤必須先解決掉才能繼續。使用 ​

​tidb-lightning-ctl​

​ 工具可以标示已經恢複。

​

​--checkpoint-error-destroy​

 ​ 

tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`'

該指令會讓失敗的表從頭開始整個導入過程。選項中的架構和表名必須以反引号 (​

​`​

​) 包裹，而且區分大小寫。

  • 如果導入​

    ​`schema`.`table`​

     ​ 這個表曾經出錯，這條指令會：
  1. 從目标資料庫移除 (DROP) 這個表，清除已導入的資料。
  2. 将斷點重設到“未開始”的狀态。
  • 如果​

    ​`schema`.`table`​

     ​ 沒有出錯，則無操作。

傳入 "all" 會對所有表進行上述操作。這是最友善、安全但保守的斷點錯誤解決方法：

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

​

​--checkpoint-error-ignore​

 ​ 

tidb-lightning-ctl --checkpoint-error-ignore='`schema`.`table`' && tidb-lightning-ctl --checkpoint-error-ignore=all

如果導入 ​

​`schema`.`table`​

​ 這個表曾經出錯，這條指令會清除出錯狀态，如同沒事發生過一樣。傳入 "all" 會對所有表進行上述操作。

注意：

除非确定錯誤可以忽略，否則不要使用這個選項。如果錯誤是真實的話，可能會導緻資料不完全。啟用校驗和 (CHECKSUM) 可以防止資料出錯被忽略。

​

​--checkpoint-remove​

 ​ 

tidb-lightning-ctl --checkpoint-remove='`schema`.`table`' && tidb-lightning-ctl --checkpoint-remove=all
sql Linux mysql
上一篇: “System自動打包”工具——劃分系統邊界的利器
下一篇: SonarQube篇-SonarLint+IDEA使用手冊一 手冊說明二 SonarLint簡介三 IDEA安裝使用SonarLint插件

繼續閱讀