Upgrade from percona 5.7.44 to 8.0.39 will not complete

MySQL & MariaDB Percona XtraDB Cluster 8.x
1

Hello,

We’ve tried this process a couple of times and all works well, but now we are running into a weird issue where no matter what we do we run into:

2025-03-11T18:03:24.400180Z 3 [ERROR] [MY-011006] [Server] Got error 197 from SE while migrating tablespaces.
2025-03-11T18:03:24.406636Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2025-03-11T18:03:24.406701Z 0 [ERROR] [MY-010119] [Server] Aborting
....
2025-03-11T18:03:26.410220Z 1 [ERROR] [MY-000000] [Galera] Exception: State wait was interrupted
2025-03-11T18:03:26.410311Z 1 [ERROR] [MY-000000] [Galera] View callback failed. This is unrecoverable, restart required. (FATAL)
	 at /mnt/jenkins/workspace/pxc80-autobuild-RELEASE/test/rpmbuild/BUILD/Percona-XtraDB-Cluster-8.0.39/percona-xtradb-cluster-galera/galera/src/replicator_smm.cpp:submit_view_info():2633

Unfortunately there’s nothing more in the logs to describe what is actually going on. There’s nothing telling us what tables/dbs are failing to convert.

We are taking a backup using xtrabackup, and restoring it to a new host, then running mysql 5.7 (this works and stands up fine) then we do an in-place upgrade to 8.0 and thats where we run into the logs below. (We use docker and mounted FS, so the data does not change between the two and we’ve used the mysql 8.0 container before without issues.

Here’s what we’ve done so far:

  1. Tried running mysqlsh util.checkForUpgrade() on the live side, this passes, and has 0 errors.
  2. Stood up mysql 5.7 from the restored data without problems.

Any ideas on how to fix this besides mysqldumps?

We haven’t modified anything on disk, and as noted we can create a cluster using mysql5.7 but 8.0 won’t convert it.

It does seem somewhat related to mysql8 won't start after migration from 5.7 and MySQL 8.0.26 won't start after upgrading from MySQL 5.7

But I went through both and couldn’t find a working solution from them.

2

Hey @sgales,
how does the setup of your live server look like and what docker image do you use for testing?
I am asking cause i am not sure if the issue could be caused by starting a galera cluster on a single node.
I have to warn you, i am not 100% if i can help you but i want to at least try to help you in that case and find a solution with you.

3

@sgales Please have a look at these two bug reports:

There is some additional context with SQL to run and check that might help your situation.

1 Like
4

Hey Jostrus,

Thanks for the response, we use a custom docker image that we build on our own. This has been used in several instances to migrate from Mysql5.7 to Mysql8.0.

To answer your question, we have 3 node clusters, single writer setup with a synchronous replica and an async replica.

I’m not sure exactly what to share here, so let me know.

5

Hey MatthewB, thanks for your response.

We sorta solved it by mysql dumps and restoring, but would be good to understand what’s going on.

here’s the commands from the two threads:

mysql -u... -p... -e "select * from information_schema.innodb_sys_tablespaces where name like '%#sql%';"
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@db /]# mysql -u... -p... -e "select * from information_schema.innodb_sys_datafiles where path like '%#sql%';"
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@db /]# mysql -u... -p... -e "SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE '%#sql%';"
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@db /]# mysql -u... -p... -e "SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES WHERE NAME LIKE '%#sql%';"
mysql: [Warning] Using a password on the command line interface can be insecure.
6

So I found a workaround, I had to mysqldump out the tables I wanted and import into an empty mysql8.0 cluster. I still don’t know why we were getting error 197, there’s no clear error logging here to tell me what happened.

Data seems to be intact but the workaround was somewhat difficult. In addition that spawn an additional question.

  1. I accidentally exported and imported system tables, so in mysql8 the import converted the mysql.users table to MyISAM, but given that its defaultly InnoDB in Mysql8, is there a reason why it converted it? I am guessing its not something you folks have a direct hand in, but figured I’d ask in any case.
7

If you used mysqldump on 5.7 to export the tables, then the mysql.users table would contain “ENGINE=MyISAM” which on import would have created it as such. I would ALTER these tables back to InnoDB ASAP.