What is the fastest and safest way to migrate TiDB from version 5.3.0 to a new cluster version 6.5.5?

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

Original topic: tidb从5.3.0迁移到新集群6.5.5,用什么方案比较快和安全些

| username: 扬仔_tidb

[TiDB Usage Environment] Production Environment
[TiDB Version] Old cluster v5.3.0, new cluster v6.5.5
[Reproduction Path] Operations performed that caused the issue
[Encountered Issue: Problem Phenomenon and Impact]
According to the requirements, we need to migrate the old cluster tidb5.3.0 to the new cluster v6.5.5. Does anyone have any good recommendations for this? Since it is a production requirement, the data must be consistent. Thank you, thank you :pray: :pray: :pray:
[Resource Configuration]
[Attachment: Screenshot/Log/Monitoring]

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

Depending on the data volume, if it’s small, you can use Dumpling to export and then import it into the new cluster. If the volume is large, use BR for export and import. Different versions of TiDB have different versions of the BR tool, so you need to test compatibility yourself.

| username: 芮芮是产品 | Original post link

You can upgrade all the way.

| username: 扬仔_tidb | Original post link

For this BR tool, the documentation doesn’t mention compatibility issues between version 5 and version 6. Moreover, the BR tool can only perform full recovery, what about incremental recovery?

| username: waeng | Original post link

I upgraded from 3.x to 6.x. After preparing the new environment, I synchronized a portion of the data for verification. Then, I synchronized most of the data, stopped the system, completed the synchronization of the remaining incremental data, and went live.

| username: zxgaa | Original post link

First, synchronize the existing data, and then you can look into master-slave synchronization for the incremental data.

| username: 扬仔_tidb | Original post link

What tool did you use for migrating the existing and incremental data to the new cluster after upgrading the old cluster to a higher version?

| username: TiDBer_OB4kHrS7 | Original post link

Dumpling export.

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

dumpling+lightning for full data, binlog for incremental data

| username: Fly-bird | Original post link

It is recommended to first complete the upgrade in a testing environment, and then upgrade the production environment.

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

Use ticdc for incremental updates.

| username: TiDBer_小阿飞 | Original post link

Full migration, then incremental migration
Full migration: Dumpling exports data
Incremental migration: TiCDC

| username: 扬仔_tidb | Original post link

Regarding Dumpling and Lightning during restoration, it seems they will check the storage of the target cluster. The original cluster is 5T, but Lightning might require the target cluster to have 20T before allowing restoration. Has anyone encountered this?

| username: TiDBer_小阿飞 | Original post link

When using the default setting of 3 replicas, TiDB Lightning requires the TiKV cluster to reserve 6 times the size of the data source. The additional 2 times is a conservative estimate accounting for the following factors not stored in the data source:

  • Indexes will occupy additional space
  • RocksDB’s space amplification effect

tidb-lightning task configuration

Does disabling this parameter in the task configuration of [lightning] work?
Check if the cluster meets the minimum requirements before starting.
#check-requirements = true

| username: heiwandou | Original post link

tidb-lightning, cdc, etc.

| username: zxgaa | Original post link

All the way through the upgrade, use force commands when necessary. During previous upgrades, all other components were successfully upgraded except for the monitoring component, which only succeeded after a forced upgrade.

| username: Jellybean | Original post link

Option 1: Direct in-place upgrade. Convenient and quick, but cannot be rolled back.

Option 2: Deploy a new high-version cluster and switch the business cluster address to complete the upgrade. This requires using BR+TiCDC to achieve both full and incremental data synchronization, and using the sync_diff tool to verify consistency before switching. The operation steps are numerous and relatively complex, but it can be rolled back.

Both options require prior verification of compatibility and performance issues in a test environment.

| username: Kongdom | Original post link

You can consider directly upgrading the old cluster. If the performance of the old cluster’s servers is not as good as the new cluster, you can migrate the cluster to the new servers through scaling in and out.

| username: andone | Original post link

Rolling upgrade