forked from pingcap/docs
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This is an automated cherry-pick of pingcap#8628
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
- Loading branch information
1 parent
e2b010a
commit dd167bc
Showing
34 changed files
with
1,278 additions
and
925 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
--- | ||
title: BR Design Principles | ||
summary: Learn about the design details of BR. | ||
--- | ||
|
||
# BR Design Principles | ||
|
||
This document describes the design principles of Backup & Restore (BR), including its architecture and backup files. | ||
|
||
## BR architecture | ||
|
||
BR sends a backup or restoration command to each TiKV node. After receiving the command, TiKV performs the corresponding backup or restoration operation. | ||
|
||
Each TiKV node has a path in which the backup files generated in the backup operation are stored and from which the stored backup files are read during the restoration. | ||
|
||
![br-arch](/media/br-arch.png) | ||
|
||
## Backup files | ||
|
||
This section describes the design of backup files generated by BR. | ||
|
||
### Types of backup files | ||
|
||
BR can generate the following types of backup files: | ||
|
||
- `SST` file: stores the data that the TiKV node backs up. | ||
- `backupmeta` file: stores the metadata of a backup operation, including the number, the key range, the size, and the Hash (sha256) value of the backup files. | ||
- `backup.lock` file: prevents multiple backup operations from storing data to the same directory. | ||
|
||
### Naming format of SST files | ||
|
||
SST files are named in the format of `storeID_regionID_regionEpoch_keyHash_cf`. The fields in the format are explained as follows: | ||
|
||
- `storeID` is the TiKV node ID. | ||
- `regionID` is the Region ID. | ||
- `regionEpoch` is the version number of a Region. | ||
- `keyHash` is the Hash (sha256) value of the startKey of a range, which ensures the uniqueness of a key. | ||
- `cf` indicates the Column Family of RocksDB (`default` or `write` by default). | ||
|
||
### Storage format of SST files | ||
|
||
- For details about the storage format of SST files, see [Rocksdb BlockBasedTable Format](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format). | ||
- For details about the encoding format of backup data in SST files, see [Mapping of table data to Key-Value](/tidb-computing.md#mapping-of-table-data-to-key-value). |
Oops, something went wrong.