If i'm not mistaken, mariadb-upgrade only modifies the structure of the "mysql" database so storing and comparing only one "structure version" for this database would be enough. Having a structure versioning of the database could allow more granular upgrade process that would not require to ALTER the whole database for potentially modifying only one column or unused tables and it would be easier to pinpoint/document what has been modified between two versions of the structure. It would also make it simpler to display a warning on the packaging side for upgrade/downgrades if there is a structure change between the current running server and the one packaged ; it would also simply "mariadb-upgrade" and in-server checks. -- My idea about the storage plugins was not per table but per datadir/plugin by storing for example a "compatibility version" of the plugin once the server started successfully but it's indeed flawed as most of the incompatible changes might only happen on a table basis with non-standard options like InnoDB compression. -- In my case, downgrading has always been done because of bugs making the new version totally unusable or at least really unsafe or unstable to run, downgrading to a previous minor version is most of the time good enough. Not keeping downgrade possible between minor version would be quite problematic as those upgrades are often done automatically and/or without checking the release notes or doing full backups before upgrading. On 8/2/23 15:49, Sergei Golubchik wrote:
Hi, Jean,
How granular it should be?
Currently every frm stores the server version that created it. So if all tables in the mysql schema were created before the current server version - the downgrade is safe (with one exception).
Except for mysql.global_priv - this one stores the version in every row, so if all rows are old, the downgrade is safe.
I don't think there's any per storage data format version though. Neither in MyISAM or Aria nor in InnoDB.
But let's assume they all store the version format. How would the server know the upgrade is safe? Checking all tables on startup is impractical.
It can check the format version whenever the table is opened. This way compatible tables will work, incompatible tables will produce an error "Incompatible storage format". This is technically safe, but from the user point of view the application still doesn't work, so the downgrade can be hardly called successful.
I think such a schema version and a storage format version will prevent crashes on downgrades, which is good. It won't solve user's problem of "downgrade and everything works" - this is likely impossible to do in a general case.
On Aug 01, Jean Weisbuch via developers wrote:
Having an internal schema version that would be incremented only on internal tables schema changes (and not linked to major/minor versioning of MariaDB) in addition to per-storage data format versions would allow a relatively safe downgrade even between major versions if there has been no changes of internal schemas and of data format of the currently used storage plugins.
It would make it easy to block the execution of MariaDB only if one of the structure is newer than the server expects and it could be bypassed with a startup variable forcing the execution even if the schemas and/or data format might not be compatible.