# Percona cluster upgrades from 5.7.39 to 5.7.44 problems

**URL:** <https://forums.percona.com/t/percona-cluster-upgrades-from-5-7-39-to-5-7-44-problems/29042>\
**Category:** Percona XtraDB Cluster 5.x\
**Created:** [March 8, 2024, 9:49pm UTC](https://forums.percona.com/t/percona-cluster-upgrades-from-5-7-39-to-5-7-44-problems/29042 "2024-03-08T21:49:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgales](https://avatars.discourse-cdn.com/v4/letter/s/eada6e/32.png) [@sgales](https://forums.percona.com/u/sgales)\
**Post date:** [March 8, 2024, 9:49pm UTC](https://forums.percona.com/t/percona-cluster-upgrades-from-5-7-39-to-5-7-44-problems/29042/1 "2024-03-08T21:49:25Z")

</div>

Hello,

We’ve been trying to get to the latest release of percona cluster 5.7 - until we are able to spend time upgrading from 5.7 =\> 8.0.

We built the new image and deployed and we ran into an interesting issue where it causes the global variables table and the session\_variables tables to fail:

```auto
[ERROR] Incorrect definition of table performance_schema.global_variables: expected column 'VARIABLE_VALUE' at position 1 to have type varchar(4096), found type varchar(2
048).
[ERROR] Incorrect definition of table performance_schema.session_variables: expected column 'VARIABLE_VALUE' at position 1 to have type varchar(4096), found type varchar(
1024).

```

This causes the cluster to fall out of sync as well. More importantly is the only solution going forward to run mysql\_upgrade to fix this? Is there any other solution for this? Some information around this would be great, thank you.

---

<div class="post-metadata">

**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\
**Post date:** [March 9, 2024, 12:08am UTC](https://forums.percona.com/t/percona-cluster-upgrades-from-5-7-39-to-5-7-44-problems/29042/2 "2024-03-09T00:08:48Z")

</div>

> [@sgales](#):
>
> run mysql\_upgrade to fix this

That’s correct and is standard practice (ie: required) in the 5.7.\* branch. Starting in 8.0 you will not need to run mysql\_upgrade anymore.

Simply run mysql\_upgrade and then restart the entire cluster and you’ll be good to go.