Operation method: In the production TiDB cluster, use the br backup full -f "db1.t1" -f "db2.t2" mode to back up table data to S3. I want to import the data into the test 7.5 cluster. However, when executing br restore full, an error occurred (this operation was feasible in 6.X and even 7.1), but in 7.5, a mandatory check was added, requiring the cluster to be new without any databases or tables. (Previously, it would only check if the restored tables conflicted with existing tables in the cluster, and as long as there was no conflict, it would not report an error.)
Even after using --filter to actively set several tables, I still couldn’t restore successfully.
l_balance -f ying99_fundtxn.cust_capital_balance_history -f ying99_fundtxn.offline_execute_info -f ying99_fundtxn.offline_remit_history -f ying99_fundtxn.capital_history -f ying99_payment.payment_info -f ying99_payment.regulatory_jymx_info -f ying99_payment.regulatory_task -f ying99_payment.regulatory_transfer_info -f ying99_payment.regulatory_zjqt_info --storage=s3://mysql-dts-migrate/capital-20240204 --s3.endpoint=https://oss-cn-shenzhen-internal.aliyuncs.com --s3.provider alibaba --log-file restore.log
Detail BR log in restore.log
[2024/02/04 10:32:49.506 +08:00] [INFO] [collector.go:77] ["Full Restore failed summary"] [total-ranges=0] [ranges-succeed=0] [ranges-failed=0]
#######################################################################
# the target cluster is not fresh, cannot restore.
# you can drop existing databases and tables and start restore again
#######################################################################
Error: user db/tables: tpcc_test, warehouse, district, customer, history, new_order, orders, order_line, stock, item, ...: [BR:Restore:ErrRestoreNotFreshCluster]cluster is not fresh
Because it only involves two databases, I temporarily bypassed it by executing br restore db multiple times. However, I still hope that in the future, support for br restore full --filter can be considered to restore multiple tables at once (which may involve tables under different databases. Neither br restore table nor br restore db supports regular expressions, which is very inconvenient to use).
Previously, it was required to restore to an empty cluster. If it was a non-empty cluster, there would be data logic confusion. I restored it once before, for example, the where condition was 1=1, but the result filtered out had 1=2, everything was messed up.
In version 7.1.3, when the table contains the same data as the backup, there is still a chance that the restore will not report an error
However, for example, if table t1 has value 1, and before restoring, you first insert 2 and then delete 2. Although the table still only has value 1, the restore will report an error:
Error: failed to validate checksum: [BR:Restore:ErrRestoreChecksumMismatch] restore checksum mismatch
insert 1; backup; truncate; insert 1; restore does not report an error.
The br backup/restore full is suitable for backing up and restoring the entire cluster. It is recommended to perform a full restore operation on an empty cluster. For restoring specific tables or databases, it is recommended to use br restore db/table.
Adding empty cluster detection for br restore full without --filter is to avoid restoring on a cluster with existing data, which could lead to issues such as overwriting online data by mistake, inconsistencies between the restored table structure and the existing table structure, and other data inconsistencies.
The br restore full with --filter essentially performs multi-database/table restoration and should not be blocked by empty cluster detection. This is an unexpected behavior bug: https://github.com/pingcap/tidb/issues/51009, which needs to be fixed in higher versions.
Additionally, starting from BR v6.5 LTS, incremental backup and incremental restore using BR are no longer recommended: https://docs.pingcap.com/zh/tidb/v6.5/br-incremental-guide. It is recommended to use PITR logs to replace incremental backup and restore.
Great , it would be good if it can be fixed later. This is basically how I use it. --db, --table does not support regex, making it very inconvenient to use.
|
username: dba-kit
|
username: 
|
username: 
|
username: 
Previously, it was required to restore to an empty cluster. If it was a non-empty cluster, there would be data logic confusion. I restored it once before, for example, the where condition was 1=1, but the result filtered out had 1=2, everything was messed up.
|
username: 
|
username: 
|
username: 
, it would be good if it can be fixed later. This is basically how I use it.