Data Migration

Translated
1

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

Original topic: 数据迁移

| username: 每天当牛马

Is there a way to migrate data between two standalone deployed TiDB databases by copying files? In which directory under tidb-data is the data stored?

2
| username: 像风一样的男子 | Original post link

It seems not working.
You should try exporting using the br or dumpling tool, it’s very fast.

3
| username: TIDB-Learner | Original post link

No, for example, the distribution of regions is not available in the new cluster PD.

4
| username: kelvin | Original post link

Export the database and then restore it.

5
| username: cassblanca | Original post link

Copying SST data files won’t work because PD lacks region and other metadata for scheduling. Use BR for backup and then restore.

6
| username: 每天当牛马 | Original post link

Copying the data directly like this can display normally, but what impact will it have?

7
| username: 路在何chu | Original post link

No, use BR backup and restore.

8
| username: 随缘天空 | Original post link

It’s not feasible. If data migration could be achieved this way, there wouldn’t be so many official migration tools. The tidb-data directory only contains data and metadata information, but it may involve environmental factors that cannot be identified, and the machine still cannot run properly.

9
| username: ffeenn | Original post link

Testing can be done this way, but not in production.

10
| username: 普罗米修斯 | Original post link

Use the backup tool.

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

I’ve never seen it played like this, bro.

12
| username: zhanggame1 | Original post link

For single-machine deployment, obviously using BR for backup is the most convenient.

13
| username: 春风十里 | Original post link

For a single-machine deployment, you can try shutting down all TiDB, TiKV, and PD, then manually back up all the TiKV and PD data files to another single machine for recovery. You can give it a try; I think it might work, although I haven’t tried it myself. However, this should only be done in a test environment. For a production environment, it’s better to stick to BR backup and recovery.

14
| username: linnana | Original post link

There is also cluster-related information under the operating system user directory.

15
| username: Kongdom | Original post link

It’s not supported. It’s better to use the official tool for migration.

16
| username: linnana | Original post link

I think the test environment can try physical copying, which should be considered cloning the instance.

17
| username: dba远航 | Original post link

Use tools for migration, such as BR, DUMPLING+TIGHTLING, etc.

18
| username: FutureDB | Original post link

The two most commonly used offline migration methods are:

  1. Migration using the BR tool;
  2. Exporting the source database into files (including table structure files and data files) using the TiDB Lightning tool, and then importing them into the target database using the Dumpling tool.
19
| username: 江湖故人 | Original post link

Are you considering a physical cold backup at the system level? In theory, it’s the fastest, but configuration differences might take more time. I still recommend using BR; physical hot backup is also very fast.

20
| username: Kongdom | Original post link

:yum: He probably means server backup, just a full backup, regardless of what’s on it, everything is backed up.