BR 设计原理

本文介绍了 Backup & Restore (BR) 的设计原理，包括架构、设计原理及备份文件。

BR 架构

BR 将备份或恢复操作命令下发到各个 TiKV 节点。TiKV 收到命令后执行相应的备份或恢复操作。

在一次备份或恢复中，各个 TiKV 节点都会有一个对应的备份路径，TiKV 备份时产生的备份文件将会保存在该路径下，恢复时也会从该路径读取相应的备份文件。

br-arch

BR 设计

备份恢复流程的详细设计可以参考备份恢复设计方案。

备份文件

本小节介绍 BR 生成的备份文件格式设计。

备份文件的类型

备份路径下会生成以下几种类型文件：

SST 文件：存储 TiKV 备份下来的数据信息
backupmeta 文件：存储本次备份的元信息，包括备份文件数、备份文件的 Key 区间、备份文件大小和备份文件 Hash (sha256) 值
backup.lock 文件：用于防止多次备份到同一目录

SST 文件的命名格式

当备份数据到 Google Cloud Storage 或 Azure Blob Storage 时，SST 文件以 storeID_regionID_regionEpoch_keyHash_timestamp_cf 的格式命名。格式名的解释如下：

storeID：TiKV 节点编号
regionID：Region 编号
regionEpoch：Region 版本号
keyHash：Range startKey 的 Hash (sha256) 值，确保唯一性
timestamp：TiKV 节点生成 SST 文件名时刻的 Unix 时间戳
cf：RocksDB 的 ColumnFamily（只备份 cf 为 default 或 write 的数据）

当备份数据到 Amazon S3 或网络盘上时，SST 文件以 regionID_regionEpoch_keyHash_timestamp_cf 的格式命名。

regionID：Region 编号
regionEpoch：Region 版本号
keyHash：Range startKey 的 Hash (sha256) 值，确保唯一性
timestamp：TiKV 节点生成 SST 文件名时刻的 Unix 时间戳
cf：RocksDB 的 ColumnFamily（只备份 cf 为 default 或 write 的数据）

SST 文件存储格式

关于 SST 文件存储格式，可以参考 RocksDB SST table 介绍。
关于 SST 文件中存储的备份数据编码格式，可以参考 TiDB 表数据与 Key-Value 的映射关系。

备份文件布局

将数据备份到 Google Cloud Storage 或 Azure Blob Storage 上时，SST 文件、 backupmeta 文件和 backup.lock 文件在同一目录下。布局如下：

.
└── 20220621
    ├── backupmeta
    |—— backup.lock
    ├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    └── {storeID}-{regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst

将数据备份到 Amazon S3 或网络盘上时，SST 文件会根据 storeID 划分子目录。布局如下：

.
└── 20220621
    ├── backupmeta
    |—— backup.lock
    ├── store1
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store100
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store2
    │   └── {regionID}-{regionEpoch}-{keyHash}-{timestamp}-{cf}.sst
    ├── store3
    ├── store4
    └── store5