Today's sid upgrade tried to install the new mysql-server (9.7.1-1),
however it failed with:

dpkg: error processing package mysql-server (--configure):
 old mysql-server package postinst maintainer script subprocess failed with exit status 1
Errors were encountered while processing:
 mysql-server

and /var/log/mysql/error.log says:
026-07-19T12:33:13.141476Z 1 [ERROR] [MY-014060] [Server] Invalid MySQL server upgrade: Cannot upgrade from 80046 to 90701. Upgrade to next major version is only allowed from the last LTS release, which version 80046 is not.

cu Andreas

Thanks for reporting this Andreas.

I think the best option for transitioning existing MySQL 8.0 servers would be
making MySQL 8.4 available in Debian unstable. From there you can stay on that
LTS which is currently supported or upgrade to 9.7 afterward. Working on that now.

Dear Maintainer,

I upgraded mysql from 8.0.46-1 to 9.7.2-1 on an Unstable server running
Mediawiki. This installation dates back to 2007.

I can confirm I ran into the "no upgrade path" issue reported in this
bug. Five hours later (following any number of unsound decisions on my
part, including installing the mysql-community-8.0 packages from the
MySQL upstream), I was able to get my database running again by building
the 8.0 packages from source, installing them, and restoring a backup of
my /var/lib/mysql taken before the update. This was obviously
undesirable.

I couldn't simply reinstall the 8.0 packages, since those are no longer
in the archive. Once I rebuilt them, though, that sufficed.

I ran into two other problems prior to exposing this one:

- 9.7 refused to start, complaining about an unknown command line option
  character_set=utf8. To eliminate this, I commented out some
  "character_set_server=utf8" and "collation_server=utf8_unicode_ci"
  lines that had been in my my.cnf for well over a decade, and
  apparently had been ignored for at least one major release cycle.

- 9.7 failed to start complaining about "error 22 on posix_fallocate()
  when reserving space for [some file]." To get around this, I had to
  enable extents and dir_index on the underlying ext3 filesystem with:

    tune2fs -O extents,dir_index /dev/sda

  After doing this, I no longer saw the error.

So you might want NEWS entries regarding those two issues. Obviously the
"no upgrade path" is the more severe problem.

Hi,

Just checking that you are aware that on a Debian/Ubuntu system
(still) running MySQL 8.0 you can simply run `apt install
mariadb-server` and the upgrade will work?

You might have specific reasons to stay on MySQL of course but just
wanted to mention here that the option to migrate to MariaDB exists,
and most of Debian users did that years ago. Also wikipedia.org itself
has been running MariaDB for 10+ years.

i only became aware that i was running mysql proper upon seeing
the upgrade to 9.7, at which point i recalled mariadb was at 11,
and was prompted to look into it. i planned to upgrade to 9.7
and then convert to mariadb. i will now likely convert to
mariadb without the upgrade to 9.7.

it was *not* my understanding that apt handled everything; i was
under the impression that authentication had to be reproduced
manually in the new mariadb, for instance. is this inaccurate?

Hi,

It is so long ago I last saw a MySQL 8.0 instance that I don't recall
the upgrade details, but in general upgrades from MySQL 5.5, 5.6, 5.7
and 8.0 start having more divergence, and in-place upgrades no longer
work for 8.4+. I recommend taking a backup, restoring the backup to a
test machine and trying it out before doing it in production.

i performed the migration from debian's mysql 8.0 to mariadb
11.8.8 this evening. it was definitely not handsfree, but it
wasn't difficult, either. i suffered about 25 minutes of
downtime total, and am no database expert. everything seems to
be working fine now.