Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: TiDB 如何实现 PITR （按时间点恢复）
|
username: TiDBer_rdb3y58G
It seems that TIDB does not have binlog, so how can point-in-time recovery be achieved? Is there any related process documentation?
TiDB has binlog logs, check the official documentation.
Take a look here:
TiDB Log Backup and PITR Architecture | PingCAP Documentation Center
TiDB Log Backup and PITR User Guide | PingCAP Documentation Center
BR+log backup doesn’t have very high real-time performance; in extreme cases, it may lose more than 2 minutes of data.
For the point-in-time recovery feature, it is recommended to use TiDB Binlog before v6.5, and BR’s PITR feature for versions v6.5 and later. From the usage scenario perspective, PITR is typically used to restore the cluster’s data to a specified point in time when the cluster has completely stopped service or the data is corrupted and cannot be recovered using other methods. When using PITR, you need to complete the data recovery through a new cluster.
You can refer to the article: 专栏 - 坚如磐石：TiDB 基于时间点的恢复（PiTR）特性优化之路丨6.5 新特性解析 | TiDB 社区
Additionally, for real-time master-slave synchronization scenarios, there is a similar situation. It is recommended to use TiDB Binlog before v6.5, and TiCDC tool for versions v6.5 and later.
PITR only supports restoring to a brand new empty cluster.
PITR only supports cluster-level restoration and does not support restoring individual databases or tables.
PITR does not support restoring user tables and permission tables in system tables.
During a PITR data restoration task, log backup tasks cannot run simultaneously, nor can data be synchronized to downstream clusters via TiCDC.
If restoring to the same machine, delete the databases before restoration:
drop database lightning_task_info;
drop database dm_meta;
drop database test;
Perform the restoration:
tiup br restore point --pd xx.xx.xx.xx:2379 --storage=‘local:///backup/brbak/tidb-test/logbackup’ --full-backup-storage=‘local:///backup/brbak/tidb-test/fullbackup-20240702’ --restored-ts ‘2024-07-02 08:42:00+0800’
FULL_BACKUP_TS=tiup br validate decode --field="end-version" --storage "local:///backup/brbak/tidb-test/fullbackup-20240702"| tail -n1
tiup br log truncate --until=${FULL_BACKUP_TS} --storage “local:///backup/brbak/tidb-test/logbackup”
Point can only restore to an empty database (that is, the database must be empty to proceed).
tiup br restore point xxx
TiDB itself does not use traditional binary logs (binlog) for data persistence and replication but instead employs its own data replication mechanism. In the early versions of TiDB, TiDB Binlog could be used to achieve functionality similar to traditional database binlogs. However, starting from TiDB version 7.5.0, the data synchronization feature of TiDB Binlog is no longer technically supported, and TiCDC is recommended as an alternative for data synchronization.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: