博客 / 詳情

返回

【趙渝強老師】TiDB的備份恢復策略

數據庫在運行過程中會出現各種故障，因此對數據庫進行必要的備份是非常重要的。有了數據庫的備份就可以在數據庫出現錯誤時保證數據的安全。因此TiDB數據庫提供了強大的數據庫備份與恢復機制。

基於Raft協議和合理的部署拓撲規劃，TiDB實現了集羣的高可用，當集羣中少數節點掛掉時，集羣依然能對外提供服務。在此基礎上，為了更進一步保證用户數據的安全，TiDB還提供了集羣的備份與恢復(Backup & Restore,BR)功能，作為數據安全的最後一道防線，使得集羣能夠免於嚴重的自然災害，提供業務誤操作“復原”的能力。

TiDB備份恢復功能可以用於滿足以下業務的需求：

  • 備份集羣數據到災備系統，並保證Recovery Point Objective(RPO)低至5分鐘，減少災難場景下數據的丟失。
  • 處理業務數據寫錯的案例，提供業務操作的“復原”能力。
  • 審計業務的歷史數據，滿足司法審查的需求。
  • 複製(Clone)生產環境，方便問題診斷、性能調優驗證、仿真測試等。

TiDB支持四種備份恢復策略，分別是：全量（快照）備份與恢復、日誌備份與恢復、數據的邏輯導出和導入和閃回。下面分別進行介紹。

視頻講解如下：
https://www.bilibili.com/video/BV1ph2rBKEJG/?aid=115682142328...

一、 全量（快照）備份與恢復

全量備份是對集羣某個時間點的全量數據進行備份，TiDB的全量備份也可以叫做快照備份。因為TiDB集羣快照數據包含某個物理時間點上集羣滿足事務一致性的所有數據。

全量備份一般會佔用較大的存儲空間，且只包含某個時間點的集羣數據。執行tiup br backup full命令，可以備份TiDB最新的或者指定時間點的快照數據。執行tiup br backup full --help可獲取該命令的使用幫助。下面的步驟將對數據庫集羣進行全量備份。

（1）創建一個目錄用於保存集羣快照備份產生的文件

mkdir -p /backup/snapshot/full
chown -R tidb:tidb /backup/snapshot/full

（2）執行備份集羣快照

tiup br backup full \
    --pd "192.168.79.10:2379" \
    --storage "local:///backup/snapshot/full" \
    --log-file /backup/snapshot/full/backupfull.log
    
# 輸出的信息如下：
Starting component br: 
         /root/.tiup/components/br/v8.5.1/br backup full \
         --pd 192.168.79.10:2379 \
         --storage local:///backup/snapshot/full \
         --log-file /backup/snapshot/full/backupfull.log
Detail BR log in /backup/snapshot/full/backupfull.log 
Full Backup <-------------------------------> 100.00%
Checksum <----------------------------------> 100.00%

（3）查看產生的快照備份文件。

tree /backup/snapshot/full/

# 輸出的信息如下：
/backup/snapshot/full/
├── 5
│   ├── ......
│   ├── 32_235_e4f50bb7685_1739865447022_write.sst
│   ├── 32_235_e5f8771bee7_1739865446968_write.sst
│   ├── 32_235_ea38515343d_1739865446917_write.sst
│   ├── 32_235_ed85b58a2c9_1739865447042_default.sst
│   ├── 32_235_ed85b58a2c9_1739865447042_write.sst
│   ├── 32_235_f0f9b1a4aa3_1739865446926_write.sst
│   ├── 32_235_f4dd8b9e556_1739865446922_write.sst
│   ├── 32_235_f70c98a950f_1739865446864_write.sst
│   ├── 32_235_fd54db249c0_1739865446984_write.sst
│   ├── ......
│   └── 32_235_fe4f4fe208b_1739865446841_write.sst
├── backupfull.log
├── backup.lock
├── backupmeta
├── backupmeta.datafile.000000001
├── backupmeta.json
├── backupmeta.schema.000000002
└── checkpoints
    └── backup

快照備份會產生如下類型文件：

  • SST文件：存儲TiKV備份下來的數據信息。單個SST文件大小等於TiKV Region的大小。SST是Static Sorted Table的縮寫。
  • Backup meta文件：存儲本次備份的元信息，包括備份文件數、備份文件的Key區間、備份文件大小和備份文件Hash(sha256)值。
  • backup.lock文件：用於防止多次備份到同一目錄。

當備份數據到本地磁盤上時，SST文件以下面的格式命名。其中

  • regionID：Region編號
  • regionEpoch：Region版本號
  • keyHash：Range startKey的Hash(sha256)值，以確保唯一性
  • timestamp：TiKV節點生成SST文件名時刻的Unix時間戳
  • cf：RocksDB的列族信息，取值：default或者write

完整的SST文件名格式如下：

<regionID>_<regionEpoch>_<keyHash>_<timestamp>_<cf>.sst

二、 日誌備份與恢復

全量備份一般會佔用較大的存儲空間，且只包含某個時間點的集羣數據。如果需要靈活地選擇恢復的時間點（即：實現PITR，Point in Time Recovery），可以使用日誌備份和日誌恢復。有了日誌備份後，通過tiup br restore point功能，可以指定要恢復的時間點。BR會自動判斷和讀取恢復需要的數據，然後將這些數據依次恢復到指定的集羣。執行tiup br log命令來開啓和管理日誌備份任務，下面展示了該命令的幫助信息：

# tiup br log --help

Usage:
  br log [command]

Available Commands:
  metadata    查詢備份存儲中備份數據的元信息
  pause       暫停日誌備份任務
  resume      重啓暫停的備份任務
  start       啓動一個日誌備份任務
  status      查詢日誌備份任務狀態
  stop        停止備份任務
  truncate    從備份存儲中清理日誌備份數據

執行tiup br log start命令可以在備份集羣啓動一個日誌備份任務。該任務在TiDB集羣持續地運行，及時地將KV變更日誌保存到備份存儲中。執行tiup br log start --help命令可獲取該子命令使用介紹：

# tiup br log start --help

start a log backup task

Usage:
  br log start [flags]

Flags:
  -h, --help               展示幫助信息
      --start-ts string   指定開始備份日誌的起始時間點。
如果未指定，則選取當前時間作為start-ts
      --task-name string  指定日誌備份任務名。
該名稱也用於查詢備份狀態、暫停、重啓
和恢復備份任務等操作

Global Flags:
  -u, --pd strings        指定備份集羣的PD訪問地址。
  -s, --storage string   指定備份存儲地址。
  ......

下面的步驟將啓動一個日誌備份任務。
（1）創建一個目錄用於保存日誌備份產生的文件

mkdir -p /backup/log
chown -R tidb:tidb /backup/log

（2）啓動日誌備份任務

tiup br log start \
  --task-name=pitr \
  --pd="192.168.79.10:2379" \
  --storage='local:///backup/log'

# 輸出的信息如下：
Starting component br: 
  br log start --task-name=pitr \
               --pd=192.168.79.10:2379 \
               --storage=local:///backup/log
Detail BR log in /tmp/br.log.2025-02-18T18.04.50+0800 
[2025/02/18 18:04:50.647 +08:00] [INFO] ["log start success summary"]

（3）查看目錄/backup/log

tree /backup/log

# 輸出的信息如下：
/backup/log
├── backup.lock
└── backupmeta

（4）查看日誌備份任務的狀態信息。

tiup br log status --task-name=pitr --pd="192.168.79.10:2379"

# 輸出的信息如下：
● Total 1 Tasks.
> #1 <
              name: pitr
            status: ● NORMAL
             start: 2025-02-18 18:04:50.561 +0800
               end: 2090-11-18 22:07:45.624 +0800
           storage: local:///backup/log
       speed(est.): 0.00 ops/s
checkpoint[global]: 2025-02-18 18:07:18.411 +0800; gap=47s

命令輸出中的字段含義如下：
● status：任務狀態，包括NORMAL（正常）、ERROR（異常）和PAUSE（暫停）三種狀態。
● start：日誌備份任務開始的時間，該值為備份任務啓動時候指定的start-ts。
● storage：備份存儲。
● speed：日誌備份任務的總QPS（每秒備份的日誌個數）。
● checkpoint[global]：集羣中早於該checkpoint的數據都已經保存到備份存儲，它也是備份數據可恢復的最近時間點。

（5）再次查看目錄/backup/log

tree /backup/log

# 輸出的信息如下：
/backup/log
├── backup.lock
├── backupmeta
└── v1
    ├── 20250218
    │   └── 10
    │       └── 1
    │           ├── 456097302173712388-2dd0ae7b-e8c7-4656-a497-e0e02d0e4fe4.log
    │           └── 456097333619195905-7bd1f194-ba97-4824-94e9-45f223382d82.log
    ├── backupmeta
    │   ├── 456097317141872643-0af28b08-6cc4-4123-af8a-f8798e967378.meta
    │   └── 456097332870512641-ce854c81-95ab-444e-91fd-e9e9fb8d2e58.meta
    └── global_checkpoint
        ├── 1.ts
        ├── 4.ts
        └── 5.ts

6 directories, 9 files

日誌備份會產生如下類型文件：

  • {min_ts}-{uuid}.log文件：存儲備份下來的kv數據變更記錄。其中{min_ts}是該文件中所有kv數據變更記錄數對應的最小ts；{uuid}是生成該文件的時候隨機生成的。
  • {checkpoint_ts}-{uuid}.meta文件：每個TiKV節點每次上傳日誌備份數據時會生成一個該文件，保存本次上傳的所有日誌備份數據文件。其中{checkpoint_ts}是本節點的日誌備份的checkpoint，所有TiKV節點的最小的checkpoint就是日誌備份任務最新的checkpoint；{uuid}是生成該文件的時候隨機生成的。
  • {store_id}.ts文件：每個TiKV節點每次上傳日誌備份數據時會使用global checkpoint ts更新該文件。其中{store_id}是TiKV的storeID。
  • v1_stream_truncate_safepoint.txt文件：保存最近一次通過br log truncate刪除日誌備份數據後，存儲中最早的日誌備份數據對應的ts。

三、 數據的邏輯導出和導入

在備份與恢復場景中，如果需要全量備份少量數據且不要求備份速度，還可以使用Dumpling從TiDB數據庫導出數據進行備份，再使用TiDB Lightning將數據導入至TiDB數據庫實現恢復。

Dumpling和TiDB Lightning屬於邏輯備份與邏輯恢復，因此適用於數據量較小的情況，例如小於50G的數據。

數據導出工具Dumpling可以把存儲在TiDB或MySQL中的數據導出為SQL或CSV格式，用於邏輯全量備份。Dumpling也支持將數據導出到Amazon S3中。

TiDB Lightning是用於從靜態文件導入TB級數據到TiDB集羣的工具，常用於TiDB集羣的初始化數據導入。TiDB Lightning 支持的文件類型有：Dumpling生成的文件、CSV文件和Parquet文件

四、 TiDB的閃回

TiDB修改數據時並不會將舊版本數據之間刪除，而是在新舊數據上打上不同的版本號，從而實現了MVCC基準。當舊版本數據滿足了GC垃圾回收的觸發條件時，TiDB才會將舊版本數據徹底刪除。換句話説，在GC垃圾回收舊版本數據之前，任然可以讀取舊版本數據從而達到恢復的目的。這就是閃回的核心機制，它是一種輕量級的恢復技術，不需要備份即可完成。通過查詢系統變量tidb_gc_life_time可以獲取舊版本數據保留的時間，默認10分鐘。

tidb> select @@tidb_gc_life_time ;
+---------------------+
| @@tidb_gc_life_time |
+---------------------+
| 10m0s               |
+---------------------+

下面的查詢語句將查詢當前的安全點（safePoint），即GC已經清理到的時間點。換句話説，該時間點以後的數據都可以恢復。

tidb> select * from mysql.tidb where variable_name = 'tikv_gc_safe_point' \G;
*************************** 1. row ***************************
 VARIABLE_NAME: tikv_gc_safe_point
VARIABLE_VALUE: 20250307-21:50:44.781 +0800
       COMMENT: All versions after safe point can be accessed. (DO NOT EDIT)
1 row in set (0.01 sec)

TiDB中支持閃回集羣、閃回數據庫和閃回表三種不同的閃回。

MySQL , 數據庫 , tidb
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.