Considerations for Downgrading from 7.1.1 to 6.5

Note:
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

3e81d12aa456aab04154b7ec51274162b8c95bde_2_690x401
ac249eea222211deb624d19ff2947a82f97af3a9_2_690x307
71619781acf7bc72506cfe09805643ab626bd2ed_2_690x204
c034889f73ebc5ed70382c36efedff8c5a79cc39_2_690x482
9acc417c11f1819b018812a15f6205040202c5e3_2_690x422
394861c9d36c65ee7acbf267a76a68ee219841dd_2_689x500

| 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?