TiDB Backup Issues

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

Original topic: TiDB备份问题

| username: TiDB超级萌新

Hey guys, I want to ask how many backup solutions TiDB has?
What’s the difference between using the br tool and using SQL commands for backup?
What does TiCDC backup mean?

| username: TiDBer_jYQINSnf | Original post link

BR is a physical backup, SQL is a logical backup.
If the data volume is large, it is recommended to use BR. If the target end for import is not TiDB, then you can only use SQL.

| username: TiDB超级萌新 | Original post link

But the files backed up using BR and the files backed up using this SQL command are the same. BACKUP DATABASE * TO ‘local:///mnt/backup/full/’;
This is the file backed up using the SQL command:


This is the file backed up using the BR tool:

| username: Jasper | Original post link

The br command used in your example and the backup in SQL both call br at the underlying level. The logic is the same, only the entry point is different.

| username: TiDB超级萌新 | Original post link

Is BR a logical backup? What other solutions are there besides BR?

| username: MrSylar | Original post link

Currently, there are two official methods: BR is considered “physical backup,” and Dumpling is logical backup. BR can be invoked via the command line using the “BR executable program” or within the database using SQL; essentially, both use “BR.” Traditional tools like mysqldump, mydumper, and mysqlpump can barely be used, but they are strongly not recommended by the official sources.

| username: TiDBer_jYQINSnf | Original post link

The BR you called with SQL cannot be restored to MySQL; this is a physical backup. Logical backup means an SQL file that can be restored to MySQL, using tools like MySQL dump or Dumpling for logical backup.

| username: TiDB超级萌新 | Original post link

Oh, I see. Thank you!!

| username: xingzhenxiang | Original post link

Physical backups (br) have fast recovery speeds but can only be used with the same version. Dumpling logical backups generate SQL files, which can be migrated to other non-TiDB environments or different versions of TiDB.

| username: 江湖故人 | Original post link

The BACKUP statement uses the same engine 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.

| username: TiDB超级萌新 | Original post link

There is also a backup for TiCDC in the documentation I just read.

| username: TiDB超级萌新 | Original post link

It seems there is also a TiCDC backup.

| username: TiDBer_jYQINSnf | Original post link

TiCDC handles incremental changes by converting TiDB changes into SQL and executing them in downstream MySQL, or it can be switched to Kafka downstream.

| username: 这里介绍不了我 | Original post link

BR refers to physical backup. The SQL command you mentioned should be tools like Dumpling or MySQLDump. Physical backup is relatively faster, but it has limitations. For example, BR is TiDB’s physical backup and recovery tool, while XtraBackup is MySQL’s physical backup and recovery tool.

Additionally, you mentioned TiCDC, which can handle downstream systems like MySQL and Kafka. It is mainly used for data synchronization.

| username: dba远航 | Original post link

Backup methods are divided into physical backups and logical backups, and by type into full backups and incremental backups. BR is a physical backup, dumpling is a logical backup; one has good performance, the other has poor performance; one is inflexible, the other is flexible, etc. Watch the training videos 301 and 303 carefully and you’ll understand.

| username: TiDB超级萌新 | Original post link

Okay, thank you.

| username: MrSylar | Original post link

TiCDC is positioned as an incremental synchronization tool.

| username: system | Original post link

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