-
Notifications
You must be signed in to change notification settings - Fork 657
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
7e3c145
commit 20561da
Showing
33 changed files
with
1,273 additions
and
1,172 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.