Upgrading TiDB 5.4 to 6/7

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

Original topic: TIDB 5.4升级至6/7

| username: chengzi

[TiDB Usage Environment] Production Environment
[TiDB Version] 5.4.0
I see that the latest version is already 7, but we are currently using version 5.4.

  1. Is it necessary to upgrade to version 6 or 7?
  2. Do we need to stop the service during the upgrade process?
  3. Are there corresponding documents for the upgrade? How should I proceed, and are there any risks involved?
| username: Kongdom | Original post link

  1. It depends on the business. Upgrade if there is a need. Upgrade if allowed.
  2. Online upgrade is supported. However, if conditions permit, a shutdown upgrade is faster.
  3. Upgrade documentation.
    使用 TiUP 升级 TiDB | PingCAP 文档中心
| username: tidb菜鸟一只 | Original post link

  1. If the current version has bugs affecting business, insufficient performance, or requires new features from version 6/7, consider upgrading.
  2. Online rolling upgrades are possible.
  3. Documentation is here: 使用 TiUP 升级 TiDB | PingCAP 文档中心
    If you have a test environment, it is recommended to first test the upgrade steps and check for any issues after the upgrade; it is advisable to back up before upgrading the production environment; upgrades cannot be rolled back, so caution is needed; when rolling upgrading TiKV, leader migration is required, which may be time-consuming. The default timeout is 5 minutes, so it is recommended to change --transfer-timeout to a larger value.
| username: ffeenn | Original post link

Unless there are special circumstances or significant improvements to the program’s functionality or performance, upgrading is not recommended.

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

Database security comes first. As long as it works, there’s no motivation to upgrade without special requirements.

| username: TiDBer_vfJBUcxl | Original post link

If there are no business requirements, there is no need to upgrade.

| username: zhanggame1 | Original post link

The database is usable, and there is no need to upgrade if there are no necessary requirements.

| username: Fly-bird | Original post link

Performance has improved significantly after the upgrade, I recommend upgrading.

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

  1. Higher versions offer significant performance improvements. Depending on current business needs, if stability is required, upgrading is not recommended. If performance is a priority, upgrading is advised.
  2. Upgrading does not require downtime.
  3. If the business cannot be stopped, it is recommended to create a new high-version cluster and upgrade through full and incremental data import.
| username: 大飞哥online | Original post link

If it’s working fine and there are no bugs or issues, there’s no need to upgrade.

| username: chengzi | Original post link

Okay, I’ll look into it. Our business core database is on MySQL, and considering the development cost of sharding, we are gradually migrating to TiDB. The cluster was set up in version 5 before, and now we are definitely considering better performance, hoping to upgrade.

| username: chengzi | Original post link

I only have three nodes, can I upgrade without downtime?

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


Upgrading the Cluster to a Specified Version

There are two ways to upgrade: rolling upgrade and offline upgrade. By default, TiUP Cluster upgrades the TiDB cluster using a rolling upgrade, meaning the cluster can still provide services during the upgrade process. During the upgrade, leaders on each node are migrated one by one before upgrading and restarting, so it takes a long time to complete the entire upgrade operation for large-scale clusters. If there is a maintenance window available for database downtime, you can use the offline upgrade method to quickly perform the upgrade.

Rolling Upgrade

tiup cluster upgrade <cluster-name> <version>

For example, to upgrade to version v7.1.1:

tiup cluster upgrade <cluster-name> v7.1.1


  • Rolling upgrade will upgrade all components one by one. During the TiKV upgrade, all leaders on TiKV will be migrated one by one before stopping the TiKV instance. The default timeout is 5 minutes (300 seconds), and the instance will be stopped directly after the timeout.
  • Using the --force parameter can quickly upgrade the cluster to the new version without evicting leaders, but this method will ignore all errors during the upgrade and will not provide effective prompts after the upgrade fails, so use it with caution.
  • If you want to maintain stable performance, you need to ensure that all leaders on TiKV are evicted before stopping the TiKV instance. You can specify --transfer-timeout to a larger value, such as --transfer-timeout 3600, in seconds.
  • If you want to upgrade TiFlash from a version before 5.3 to a version after 5.3, you must perform an offline upgrade for TiFlash. Refer to the following steps to upgrade TiFlash while ensuring other components run normally:
    1. Stop the TiFlash instance: tiup cluster stop <cluster-name> -R tiflash
    2. Use the --offline parameter to upgrade the cluster without restarting (only updating files): tiup cluster upgrade <cluster-name> <version> --offline, for example, tiup cluster upgrade <cluster-name> v6.3.0 --offline
    3. Reload the entire cluster: tiup cluster reload <cluster-name>. At this point, TiFlash will also start normally without additional operations.
  • During the rolling upgrade of a cluster using TiDB Binlog, avoid creating new clustered index tables.
| username: chengzi | Original post link

During the entire upgrade process, read and write operations should proceed normally since the production business is still running.

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

Each node is upgraded in rotation. During the upgrade, the overall database performance will definitely fluctuate. It is best to conduct tests in advance and perform the upgrade during off-peak business hours in the production environment.

| username: chengzi | Original post link

Sure, thank you for your support.

| username: Fly-bird | Original post link

Performance has improved significantly.

| username: zhanggame1 | Original post link

Any upgrade carries risks, so it’s best to make a backup before upgrading. If you’re unsure about the benefits of the upgrade, it’s better not to upgrade.

| username: system | Original post link

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