Version Upgrade

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

Original topic: 版本升级

| username: 等一分钟

Can the TiDB version be directly upgraded from 4.0.4 to 6.1?

| username: Kongdom | Original post link

I strongly advise against doing this.

The most stable and labor-saving method is to set up a 6.1 cluster, then use the TiCDC synchronization tool to sync the data from 4.0. During the cutover, pause the business to perform data comparison, and if there are any issues, you can roll back.

| username: 裤衩儿飞上天 | Original post link

The official description is acceptable, but for such a large version leap, it is recommended to install a new version of the cluster and upgrade using logical export and import.

Using TiUP to Upgrade TiDB | PingCAP Documentation Center

| username: ffeenn | Original post link

If it’s not a production environment or you don’t need to directly destroy the cluster, you can deploy a 6.1 cluster. If it’s a production environment upgrade, it’s recommended to create a new cluster for the upgrade. The steps are as follows:

  1. Create a new cluster with the same version as the production environment.
  2. Import the data from the production environment into the new cluster and upgrade it to version 6.1. Then export the data from the upgraded version.
  3. Destroy the new cluster, recreate it with the new 6.1 version, and import the data.

Alternatively, you can follow the suggestion in the first post. When I was doing the upgrade, I encountered issues with TiCDC because our structure is somewhat special.

| username: 啦啦啦啦啦 | Original post link

We are planning to upgrade directly from 3.0 to 6.1 by setting up a new 6.1 cluster and using binlog synchronization for the switch. This is also the method recommended by the official documentation for production environments.

| username: 等一分钟 | Original post link

In that case, there are no more machines to set up a new cluster.

| username: ffeenn | Original post link

You can only create a new cluster. Personal experience tells you not to think about upgrading directly, otherwise, there will be many problems. Also, in production, you need to ensure a good rollback strategy in case the upgrade fails.

| username: 等一分钟 | Original post link

Using a cloud server, took a snapshot before upgrading, can restore if there are any issues.

| username: liuis | Original post link

The test environment was directly upgraded before, causing a crash.

| username: 等一分钟 | Original post link

“Region is unavailable. After the upgrade, this error was reported. Could it be caused by the upgrade?”

| username: xingzhenxiang | Original post link

I currently want to upgrade directly from v4.0.11 to v6.5.1, but I’m not sure how to proceed.

| username: xingzhenxiang | Original post link

Where is the tipping point for the avalanche?

| username: liuis | Original post link

The cluster got messed up~ ended up reinstalling it.

| username: liuis | Original post link

Fortunately, we have now switched our test cluster to k8s, making deployment and maintenance much more enjoyable. It was unbearable when we were using Ansible before.

| username: xingzhenxiang | Original post link

Alright, I still don’t understand the point of the avalanche. The logical export is indeed relatively stable, but exporting nearly 40TB of data is not very realistic for me.

| username: liuis | Original post link

40T is indeed a bit much.

| username: ffeenn | Original post link

Use blog or TiCDC for synchronization.

| username: 海石花47 | Original post link

What about minor versions? Is it recommended to upgrade directly?

| username: ffeenn | Original post link

Minor versions should be fine. Normally, versions before 6.0 should also be upgradable, but strict testing is still necessary. If it’s virtual, be prepared for rollback.

| username: lmdb | Original post link

I tested the upgrade from 6.4.0 to 6.6.0 in a test environment. It took about 10 minutes.