[MDEV-23008] store mysql_upgrade version info in system table instead of local file Created: 2020-06-24  Updated: 2023-11-30

Status: Open
Project: MariaDB Server
Component/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Ralf Gebhardt
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Relates
relates to MDEV-25670 mariadb container needs to run mysql_... Closed
relates to MDEV-32166 mysql_install_db creates mysql_upgrad... Closed
relates to MDEV-15207 mysql_upgrade cannot create file mysq... Closed

 Description   

Currently mysql_upgrade stores version info in file $datadir/mysql_upgrade_info

This has a set of disadvantages:

  • information is not accessible from the SQL level
  • when restoring a backup from an older server version the file information will not match the actual database version state
  • mysql_upgrade can only be executed successfully by an OS user with write access to the datadir
  • mysql_upgrade can perfectly perform its upgrade tasks while running remotely on a different host, but will write the version info file locally then

All of these points would be solved if upgrade version information would be stored in a system table instead of a local file ...

 Comments   
Comment by Daniel Black [ 2021-02-02 ]

The MYSQL_VERSION_ID is already stored in the frm (sql/handler.cc:update_frm_version) 4 bytes at offset 51L. Some successful `CHECK TABLE` operation will update this.

On exposing this, information_schema.tables seems the logical way. If adding columns is too unstable maybe it could be added as a 10.3 invisible column.

Then the remaining requirement is mysqldump exposing this and CREATE TABLE extension for it.

Missing use cases? Problems? Alternatives?

Comment by Oli Sennhauser [ 2021-02-02 ]

One use case we have in our Ops Center is, that we want to check if server version is in line with the data dictionary version to see if proper mariadb-upgrade was done.
Currently we have to do it as follows: Compare @@version with mysql_upgrade_info. If miss match complain. If file does NOT exist we have 2 possible cases:
1) it is a fresh install or
2) it is an old install, never experienced any mariadb-upgrade.
So we have to guess because mariadb does not automatically run mariadb-upgrade like some competitive products.

Comment by Daniel Black [ 2021-02-02 ]

valerii (in out of band email) suggested a history of upgrades.

Seems like a extension of a mysql.upgrade as a table to which mysql_upgrade inserts that maintains a historical record of what was done. Could go as far as storing dates, MYSQL_VERSION_ID on tables, individual mysql_upgrade SQL commands run, return codes, warnings.

Generated at Thu Feb 08 09:19:09 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.