Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 我误删了几条数据了,已经过了6个小时了,备份集很大很大,怎么能恢复呢这几条数据呢?

How to restore it?
Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 我误删了几条数据了,已经过了6个小时了,备份集很大很大,怎么能恢复呢这几条数据呢?
How to restore it?
If the GC’s snapshot time is still within range, see if you can restore it. This should be the simplest method. However, the prerequisite is that the snapshot still exists.
If the snapshot time point that can be flushed happens to be,
flush to the new table, query it, and update it back.
What is the architecture like? Does it include CDC, binlog, etc., or is it just a simple cluster?
Binlog is enabled, but I’m not sure if it’s really enabled, and I don’t know where the directory is.
According to the official website, there are configuration options. Check what your configuration looks like, the positions of pumper and drainer, and where the output goes.
This solution is feasible. Output to a file. You are performing a keyword search.
We only need those few pieces of data. We can set the start time and end time. Approximately a few time periods should be enough.
You can use the Flashback feature introduced in TiDB v6.4.0 to quickly restore data. You can restore data to a specified point in time, as long as it is within the GC time. For specific operations, please refer to Flashback Cluster and Flashback Database.
If you have a BR backup, you can directly use the BR backup data to restore the table with the deleted data. To be safe, you can set up a separate single-node cluster for the restoration.
Isn’t the default GC time for TiDB 5 minutes? It passed so quickly.
However, does the incremental data also need to be restored using binlog? It’s uncertain whether there have been any changes recorded during the period from backup to deletion.
Setting the GC time too long will affect performance, won’t it?