Planning migration from MySQL 5.7 to 8.0

The upstream MySQL 5.7 release will be end of life in October 2023. David Stokes has a blog post about the upcoming EOL and suggestions for managing your upgrade from 5.7 to 8.0.

We’d love to hear from users still on 5.7, what blockers are keeping you on 5.7 and your plans for October and beyond. If you’re trying to upgrade from MySQL 5.7 to MySQL 8.0, we can help. If you need more time on MySQL 5.7 and need support after October 2023, we have a subscription for that where we can provide support up to three years for Percona Server for MySQL 5.7. You can learn more about that on

1 Like

We ran into this Data Dictionary upgrade problem:

The log file posted there is from MySQL 8.0.33 CE on Windows, but I get exactly the same with Percona 8.0.32-24 on Linux.

Anyone have any hints on what these “tmp/#sql5305_” tablespaces originated from, and how to clean them up?

Fixing these inconsistencies is always tricky. If you can afford it I suggest to fix it by provisioning a new replica by taking a logical dump/restore with mydumper/myloader.

Dump/reload is certainly not the preferred option; production is an XtraDB cluster. I would have to build up an entirely new cluster, would I not?

@stevew those are temporary tables, that should be deleted once the temporary operation is completed, how did you find out about that table?
Do you have any /tmp/#sql remaining file in your filesystem?
If you can share the files that you have in your filesystem like this, would give us a hint on what is causing the issue, maybe an unfinished temporary operation that left an ibd file in tmp
Or probably if the database has been already restarted, the file is gone already

I found them because they block the 8.0 upgrade; they are NOT in the file system. As noted, they almost certainly date back to an earlier 5.x release (5.5, 5.1, maybe even 5.0). Doing an instance dump and reload gets rid of them and unblocks the 8.0 upgrade, but it’s a bit of a hassle.