Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: pitr没有写文件
Started an incremental backup task with tiup br log status --task-name=pitr --pd "***:2479" --storage '/tidb-data5/brlog/'
. The directory /tidb-data5/brlog/
is a local directory. There are a total of 48 TiKV instances, and the backup directory was created on a single TiKV instance. The task is running normally, and there are DML operations on the database, but no related data files are being generated.
If there are no directories on other nodes, the task cannot run properly, right?
It is necessary to create a backup directory on other instances. The task will run on each TiKV node, and specifying only one instance’s local directory will not allow data transfer.
I switched to a new NAS and mounted it on all servers. Now it seems to be generating files normally, but I have a few questions:
- I found that PITR does not have an automatic file deletion feature according to the official documentation, and files need to be manually cleaned up periodically. Is there any other parameter to control this?
- It seems that PITR runs in the background indefinitely as long as there is no failure. If it is manually killed one day, does it need to be manually restarted?
- It seems that PITR does not have a database table filtering feature.
One strange thing is that the other TiKV instances did not create directories, and no errors were reported when starting the tasks.
The log backup of BR needs to be used in conjunction with snapshot backup, similar to the incremental and full backups in Oracle’s RMAN. For example, if you perform snapshot backups on your cluster every Monday, Wednesday, and Friday, there is no way to restore data to Tuesday or Thursday, so log backups are needed.
- Currently, there is indeed no automatic deletion function because you need to confirm that your snapshot backup is completed correctly before you can choose to delete the log backups prior to the snapshot backup.
- Yes.
- PITR (Point-In-Time Recovery) is only for the entire cluster. To restore, you can only set up an empty cluster and perform a full recovery to a specific point in time.
You have a 23-minute gap here, which indicates an issue with the checkpoint not progressing, so no files are being generated. Check the ERROR logs in TiKV.
Okay, thank you, I learned something.
All nodes must have backup directories.
Ensure there is a backup directory and that the TiKV process has sufficient read and write permissions.
Are the directory permissions sufficient?