Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23008

store mysql_upgrade version info in system table instead of local file

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

          Activity

            danblack Daniel Black added a comment -

            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?

            danblack Daniel Black added a comment - 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?

            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.

            oli Oli Sennhauser added a comment - 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.
            danblack Daniel Black added a comment -

            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.

            danblack Daniel Black added a comment - 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.

            Where are we with this?

            It should be a rather simple change only, changing from writing to a file to writing to a table (which actually requires less privileges, only SQL level write access being needed but no direct file system access), and an additional check whether the table already exists, creating it if not (which is what the upgrade tool does for other system tables, anyway).

            Right now we are pretty much at risk, or even have it guaranteed, that restoring a mysqldump taken from an older version leads to non-upgraded system tables while the information stored in the magic file still says "all fine, no upgrade needed to be done"; which pretty much renders the whole storing of the version information pretty much useless, and the feedback given by the tool harmful.

            hholzgra Hartmut Holzgraefe added a comment - Where are we with this? It should be a rather simple change only, changing from writing to a file to writing to a table (which actually requires less privileges, only SQL level write access being needed but no direct file system access), and an additional check whether the table already exists, creating it if not (which is what the upgrade tool does for other system tables, anyway). Right now we are pretty much at risk, or even have it guaranteed, that restoring a mysqldump taken from an older version leads to non-upgraded system tables while the information stored in the magic file still says "all fine, no upgrade needed to be done"; which pretty much renders the whole storing of the version information pretty much useless, and the feedback given by the tool harmful.

            People

              ralf.gebhardt Ralf Gebhardt
              hholzgra Hartmut Holzgraefe
              Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.