Considerations for Downgrading from 7.1.1 to 6.5

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

Original topic: 7.1.1降级6.5注意事项

| username: TiDB_老表

[TiDB Usage Environment] Production Environment
[TiDB Version] 7.1.1
Two TiDB databases:
Database A (7.1.1): Data volume below 1T
Database B (7.1.0): Data volume below 6T
To solve the issue of CPU spikes caused by a small number of cross-shard SQL queries in version 7.1 (which can be triggered after executing SQL two or three times, even without concurrency or other business activities)

| username: 大飞哥online | Original post link

What environment was upgraded to 7.1?

| username: 大飞哥online | Original post link

It was already version 7.1 when deployed.

| username: 大飞哥online | Original post link

Version 6.5, did you test and verify that there is no such issue?
You still need to analyze the cause of the CPU spike problem.

| username: TiDB_老表 | Original post link

In the past month

| username: TiDB_老表 | Original post link

Previously, we were using version 6.5 without any issues. Recently, after upgrading to 7.1, we encountered this problem without making any changes to the business logic. We discovered the issue during performance stress testing on the business side. Therefore, we are currently downgrading to ensure business continuity, but we will keep version 7.1 to continue investigating this problem.

| username: TiDBer_yyy | Original post link

Could it be a GC issue?
How many days has it been since the upgrade?
You can try disabling gc.enable-compaction-filter.

| username: TiDB_老表 | Original post link

It’s been a month, and I just discovered it recently.

| username: TiDB_老表 | Original post link

The TiDB service has always been at 99% CPU usage.

| username: Jellybean | Original post link

Please post the issue monitoring charts and related logs, and we will analyze them together. It is speculated that some areas have not been properly adapted.

| username: 大飞哥online | Original post link

Yes, let’s analyze it first. Rolling back the version is the last resort.

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

Once it goes up, it’s hard to come back down.

| username: TiDB_老表 | Original post link


| username: xingzhenxiang | Original post link

The safest way to handle this data volume is to logically export and then import it.

| username: Kongdom | Original post link

Downgrading major versions can only be done through logical export and import. It’s unclear whether backup and restore are supported.

| username: 大飞哥online | Original post link

For this amount of data, a logical backup is definitely better.

| username: 路在何chu | Original post link

Downgrading can only be done through logical backup and migration, right?

| username: 有猫万事足 | Original post link

From the dashboard, go to the topsql interface and select this TiDB to see what it is executing.

If it can be stably reproduced, it is relatively easy to locate.

| username: 大飞哥online | Original post link

It can’t be said that only major versions are the best to use. It’s safer to use logical versions to prevent any physical anomalies.

| username: Fly-bird | Original post link

Questions about SQL?