Consultation on Using BR with TiDB

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 请教tidb使用br的问题

| username: TiDBer_Lee

[TiDB Usage Environment] Production Environment / Testing / PoC
I have a few questions:

  1. What is the difference between using SQL commands for backup and restore statements and using the BR tool for backups?
  2. Where is the data shown by show backups stored, and how is it managed? If I continuously use the backup statement for backups, how do I delete the backup records when the expired backups are deleted?
  3. During the execution of a backup using the backup command, if I use show backups to check the progress multiple times, sometimes I can’t find any information.
| username: redgame | Original post link

According to the documentation:
Backup and restore are methods of performing backups and restores using TiDB’s built-in SQL commands.
The BR tool is a backup and restore tool provided by the TiDB ecosystem.

| username: xfworld | Original post link

The BACKUP statement is used to perform distributed backup operations on a TiDB cluster.

The engine used by the BACKUP statement is the same as BR, but the backup process is driven by TiDB itself rather than a separate BR tool. The advantages and warnings of the BR tool also apply to the BACKUP statement.

Executing BACKUP requires BACKUP_ADMIN or SUPER privileges. Additionally, the TiDB node executing the backup and all TiKV nodes in the cluster must have read or write access to the target storage.

Reference documentation:


Returning to the original question:
Is the desired backup method logical backup (hot, warm) or physical backup? (cold)

For logical backup, you can choose: dumping. For recovery, you can choose ordinary SQL recovery or use TiDB Lightning.
For physical backup, you can choose: BR.

| username: TiDBer_Lee | Original post link

According to the documentation, the BACKUP statement and br are the same, but I found that the results of the show backups query are periodically deleted. I don’t know what this mechanism is.

| username: xfworld | Original post link

The backed-up data definitely needs to be stored separately, which also meets the storage medium requirements of the BR tool.

Not sure about your specific scenario… It is recommended to refer to the BR requirements to set up the operation process…

| username: TiDBer_Lee | Original post link

You did not answer my question.

| username: TiDBer_Lee | Original post link

My question is, where is the progress information of the backup stored when using the “show backups” command?

| username: knull | Original post link

Since it’s similar to br, then this is a task. show backups should be a task status, i.e., the running status of the backup. I think it should be maintained in memory.

| username: 有猫万事足 | Original post link

Good question.
https://github.com/pingcap/tidb/blob/master/executor/show.go#L271
The execution of show backups will enter fetchShowBRIE here.

https://github.com/pingcap/tidb/blob/master/executor/brie.go#L610
You can see that it fetches data from globalBRIEQueue, so the information for show backups indeed exists in memory.

The content in the globalBRIEQueue queue seems to be set when registerTask is called.
The remaining content seems to involve disttask, and I can’t find the call chain.
I hope some development experts can enhance the technical depth of the community. :rofl:

| username: TiDBer_Lee | Original post link

This information is too easily lost. If there isn’t a proper way to maintain this data, using backup/restore commands for backup isn’t very effective.

| username: 有猫万事足 | Original post link

Actually, the problem lies in how to registerTask, which I don’t understand. Now I don’t know how this queue is maintained. :sweat_smile:

| username: Fly-bird | Original post link

BR is physical backup, SQL commands are logical backup.

| username: zhanggame1 | Original post link

SQL has an interface for physical backups.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.