Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
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 ...
Attachments
Issue Links
- relates to
-
MDEV-25670 mariadb container needs to run mysql_upgrade
-
- Closed
-
-
MDEV-32166 mysql_install_db creates mysql_upgrade_info file with different owner
-
- Closed
-
-
MDEV-15207 mysql_upgrade cannot create file mysql_upgrade_info
-
- Closed
-
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?