Should TiDB production version 5.2.2 be upgraded directly to 7.1.0 or follow the minor version upgrade path? Any suggestions and things to note during the upgrade process?

Translated
1

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

Original topic: tidb 生产版本5.2.2想在线升级到7.1.0 是直接升级到7.1.0 还是按照小版本最低最高的路线（5.2.2 → 5.2.4 → 5.3.0 → 5.3.4 → 5.4.0 → 5.4.3 → 6.1.0 → 6.1.7 → 6.5.0 → 6.5.10 → 7.1.0）升级呢？大佬们有什么建议和升级过程需要注意哪些事情呢？

| username: 老鹰506

[TiDB Usage Environment] Production Environment
[TiDB Version] 5.2.2
Due to the large amount of data in the production cluster, which is used for core business, there are currently no extra resources to set up a mirror cluster for the upgrade. I want to upgrade directly online to version 7.1.0. I seek advice on the matters that need attention.

Current TiDB cluster information is as follows:

Cluster type: tidb
Cluster name: social-tidb
Cluster version: v5.2.2
Deploy user: tidb
SSH type: builtin
Dashboard URL: http://192.168.3.59:2379/dashboard
Grafana URL: http://192.168.3.15:3000
ID Role Host Ports OS/Arch Status Data Dir Deploy Dir

192.168.3.21:9093 alertmanager 192.168.3.21 9093/9094 linux/x86_64 Up /data/tidb/data.alertmanager /data/tidb
192.168.3.131:8300 cdc 192.168.3.131 8300 linux/x86_64 Up /data/tidb-data/cdc-8300 /opt/app/tidb-deploy/cdc-8300
192.168.3.132:8300 cdc 192.168.3.132 8300 linux/x86_64 Up /home/tidb/deploy/cdc-8300/data /home/tidb/deploy/cdc-8300
192.168.3.128:8249 drainer 192.168.3.128 8249 linux/x86_64 Up /data/tidb-data/drainer-8249 /opt/app/tidb-deploy/drainer-8249
192.168.3.15:3000 grafana 192.168.3.15 3000 linux/x86_64 Up - /opt/app/tidb-deploy/grafana-3000
192.168.3.57:2379 pd 192.168.3.57 2379/2380 linux/x86_64 Up /data/tidb/data.pd /data/tidb
192.168.3.58:2379 pd 192.168.3.58 2379/2380 linux/x86_64 Up|L /data/tidb/data.pd /data/tidb
192.168.3.59:2379 pd 192.168.3.59 2379/2380 linux/x86_64 Up|UI /data/tidb/data.pd /data/tidb
192.168.3.25:9090 prometheus 192.168.3.25 9090 linux/x86_64 Up /data/tidb/prometheus2.0.0.data.metrics /data/tidb
192.168.3.134:8250 pump 192.168.3.134 8250 linux/x86_64 Up /data/tidb-data/pump-8250 /opt/app/tidb-deploy/pump-8250
192.168.3.135:8250 pump 192.168.3.135 8250 linux/x86_64 Up /data/tidb-data/pump-8250 /opt/app/tidb-deploy/pump-8250
192.168.1.32:4000 tidb 192.168.1.32 4000/10080 linux/x86_64 Up - /data/tidb
192.168.2.176:4000 tidb 192.168.2.176 4000/10080 linux/x86_64 Up - /data/tidb
192.168.1.105:20160 tikv 192.168.1.105 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.178:20160 tikv 192.168.1.178 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.179:20160 tikv 192.168.1.179 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.74:20160 tikv 192.168.1.74 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.93:20160 tikv 192.168.1.93 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.94:20160 tikv 192.168.1.94 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.98:20160 tikv 192.168.1.98 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160
192.168.1.99:20160 tikv 192.168.1.99 20160/20180 linux/x86_64 Up /data1/tidb-data /opt/app/tidb-deploy/tikv-20160

2
| username: Kongdom | Original post link

It is recommended not to upgrade across major versions. You can upgrade from 5.2.2 to 6.1.0, then from 6.1.0 to 6.5.0, and finally from 6.5.0 to 7.1.5 to be more stable.

image
image841×632 45.7 KB

3
| username: Kongdom | Original post link

This event has been postponed, you can participate for more security :muscle:

4
| username: tidb菜鸟一只 | Original post link

I’m really hesitant about 5.2. A couple of days ago, I upgraded one of my 5.4.3 databases to 6.5.10. I originally planned to upgrade to 7.5.2, but in the end, I didn’t dare to.

5
| username: ShawnYan | Original post link

Plus,

Upgrading TiDB is relatively stable, but it is also necessary to perform business function verification before going into production.

6
| username: xfworld | Original post link

Try to get two sets, it will be safer. If you can’t back up the data, you can also give it a try, but it will be more time-consuming.

7
| username: 希希希望啊 | Original post link

Directly upgrade to 7, and solve any issues according to the error messages one by one. Otherwise, upgrading minor versions one by one will take forever.

8
| username: Kongdom | Original post link

This step might take longer than upgrading one by one. Specific cases require specific analysis. It’s better to practice first and see which method suits you best.

9
| username: Jellybean | Original post link

The version span is quite large, considering the stability of online services and data security, it is not recommended to upgrade in place directly.

It is recommended to set up a master-slave cluster for switching upgrades, and you can consider using binlog or TiCDC to set up the master-slave.

10
| username: Kongdom | Original post link

:laughing: OP, the situation here is the same as mine, resources are tight.

11
| username: 连连看db | Original post link

Safety first. I don’t believe we can’t squeeze out these temporary resources.

12
| username: Kongdom | Original post link

:joy: You don’t realize how hard it is to manage until you do it yourself. Even the best housewife cannot cook without rice.

13
| username: TiDBer_7S8XqKfl | Original post link

Thank you for sharing, teacher.

14
| username: tony5413 | Original post link

Don’t you even have a testing environment?

15
| username: Kongdom | Original post link

:joy: In some cases, there’s really no other way. You can only make a backup, then upgrade, and if any issues arise, redeploy and restore.

16
| username: 庙小妖风大 | Original post link

I directly upgraded from 522 to 712.

17
| username: TIDB-Learner | Original post link

Previously upgraded from 5.4 to 6.5

18
| username: tony5413 | Original post link

In this situation, how should it be handled? It’s difficult for a clever housewife to cook without rice. If there are issues with the upgrade, I might have to take the blame. Should we not upgrade if resources are not provided?

19
| username: zhaokede | Original post link

Upgrade one major version at a time, for example, upgrade to 6.5 first, then to 7.51.

20
| username: Kongdom | Original post link

:yum: We first create a backup, then proceed with the upgrade. If there are issues with the upgrade, we destroy the cluster and set up a new one, then restore the backup. However, we generally don’t upgrade unless we encounter a bottleneck.