- Key Features
- Horizontal Scalability
- MySQL Compatible Syntax
- Replicate from and to MySQL
- Distributed Transactions with Strong Consistency
- Cloud Native Architecture
- Minimize ETL with HTAP
- Fault Tolerance & Recovery with Raft
- Automatic Rebalancing
- Deployment and Orchestration with Ansible, Kubernetes, Docker
- JSON Support
- Spark Integration
- Read Historical Data Without Restoring from Backup
- Fast Import and Restore of Data
- Hybrid of Column and Row Storage
- SQL Plan Management
- Open Source
- Online Schema Changes
- Get Started
- MySQL Compatibility
- SQL Language Structure
- Data Types
- Functions and Operators
- Function and Operator Reference
- Type Conversion in Expression Evaluation
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Window Functions
- Miscellaneous Functions
- Precision Math
- List of Expressions for Pushdown
- SQL Statements
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
CREATE TABLE LIKE
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW CHARACTER SET
SHOW [FULL] COLUMNS FROM
SHOW CREATE TABLE
SHOW CREATE USER
SHOW [FULL] FIELDS FROM
SHOW INDEXES [FROM|IN]
SHOW INDEX [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW [FULL] PROCESSSLIST
SHOW [FULL] TABLES
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [GLOBAL|SESSION] VARIABLES
- Generated Columns
- Character Set
- SQL Mode
- System Databases
- Errors Codes
- Supported Client Drivers
- Garbage Collection (GC)
- Understanding the Query Execution Plan
- The Blocklist of Optimization Rules and Expression Pushdown
- Introduction to Statistics
- TopN and Limit Push Down
- Optimizer Hints
- Follower Read
- Check the TiDB Cluster Status Using SQL Statements
- Execution Plan Binding
- Statement Summary Table
- Tune TiKV
- Operating System Tuning
- Column Pruning
- Key Monitoring Metrics
- Alert Rules
- Best Practices
- TiDB Binlog
- Use Cases
- TiDB Operator
- Table Filter
- Backup & Restore (BR)
- Data Migration
- TiDB Lightning
- PD Control
- PD Recover
- TiKV Control
- TiDB Control
- TiDB in Kubernetes
- All Releases
You are viewing the documentation of an older version of the TiDB database (TiDB v3.1).
This document lists the frequently asked questions (FAQs) and the solutions about Backup & Restore (BR).
What should I do if the error message
could not read local://...:download sst failed is returned during data restoration?
When you restore data, each node must have access to all backup files (SST files). By default, if
local storage is used, you cannot restore data because the backup files are scattered among different nodes. Therefore, you have to copy the backup file of each TiKV node to the other TiKV nodes.
It is recommended to mount an NFS disk as a backup disk during backup. For details, see Back up a single table to a network disk.
When you use the
oltp_read_only scenario of
sysbench to back up to a disk (make sure the backup disk and the service disk are different) at full rate, the cluster QPS is decreased by 15%-25%. The impact on the cluster depends on the table schema.
To reduce the impact on the cluster, you can use the
--ratelimit parameter to limit the backup rate.
The system libraries (
mysql) are filtered out during full backup. For more details, refer to the Backup Principle.
Because these system libraries do not exist in the backup files, no conflict occurs among system tables during data restoration.
What should I do to resolve the
Permission denied error, even if I have tried to run BR using root in vain?
You need to confirm whether TiKV has access to the backup directory. To back up data, confirm whether TiKV has the write permission. To restore data, confirm whether it has the read permission.
Running BR with the root access might fail due to the disk permission, because the backup files (SST files) are saved by TiKV.
You might encounter the same problem during data restoration. When the SST files are read for the first time, the read permission is verified. The execution duration of DDL suggests that there might be a long interval between checking the permission and running BR. You might receive the error message
Permission denied after waiting for a long time.
Therefore, It is recommended to check the permission before data restoration.
Almost all of these problems are system call errors that occur when TiKV writes data to the disk. You can check the mounting method and the file system of the backup directory, and try to back up data to another folder or another hard disk.
For example, you might encounter the
Code: 22(invalid argument) error when backing up data to the network disk built by
When you use
backupmeta is generated on the node where BR is running, and backup files are generated on the Leader nodes of each Region.
During data backup, backup files are generated on the Leader nodes of each Region. The size of the backup is equal to the data size, with no redundant replicas. Therefore, the total data size is approximately the total number of TiKV data divided by the number of replicas.
However, if you want to restore data from local storage, the number of replicas is equal to that of the TiKV nodes, because each TiKV must have access to all backup files.
The data restored using BR cannot be replicated to the downstream. This is because BR directly imports SST files but the downstream cluster currently cannot obtain these files from the upstream.
DDL jobs generated during the BR restore might cause unexpected DDL executions in Drainer. Therefore, if you need to perform restore on the upstream cluster of TiCDC/Drainer, add all tables restored using BR to the Drainer block list.
You can use
syncer.ignore-table to configure the block list for Drainer.
- What should I do if the error message could not read local://...:download sst failed is returned during data restoration?
- How much does it affect the cluster during backup using BR?
- Does BR back up system tables? During data restoration, do they raise conflict?
- What should I do to resolve the Permission denied error, even if I have tried to run BR using root in vain?
- What should I do to resolve the Io(Os...) error?
- Where are the backed up files stored when I use local storage?
- How about the size of the backup data? Are there replicas of the backup?
- What should I do when BR restores data to the upstream cluster of Drainer?