Proposal: mariadbd should automatically upgrade system tables and data directory on startup
Hi!
I frequently see users running into various problems after upgrading MariaDB and starting the upgraded mariadbd server:
- Server might refuse to start, asking users to manually run mariadb-upgrade - Server might start, but misbehave as on-disk data format for regular tables or the system tables has not updated - On systems where mariadb-upgrade runs automatically on MariaDB service startup there might be unnecessary delay if mariadb-upgrade is run multiple times - If running mariadb-upgrade fails or is slow, users might end up in a situation where they re-restart the server and have two mariadb-upgrade scripts running and blocking each other - In some cases user might attempt to run mariadb-upgrade but it fails it the MariaDB server was not running, forcing user to figure out how to manually start the server for upgrades - Users might end up starting server in a mode that does not accept connections with the intent to only run mariadb-upgrade, but then don't understand they need to restart the server to have it serve connections again - Users planning upgrades get confused because because reading about Fedora based distros the DBA is requires to manually run mariadb-upgrade themselves, and reading about Debian based distros DBAs are not required to do this as it is automatic, but they might end up trying to run it manually anyway because of prior experience with Fedora
Some of the above issues can be remediated by running 'mariadb_upgrade --check-if-upgrade-is-needed' before actually running mariadb_upgrade in service scripts, but it does not work if server is offline (https://jira.mariadb.org/browse/MDEV-27636). Making users aware that their database is running but mariadb-upgrade has not run can be done via https://github.com/MariaDB/server/pull/2464. However this are just duct tape to the original problem.
All of the above could be permanently solved if mariadbd simply did the upgrade by itself automatically.
Can we please have this?
Can we agree that this would be a desired feature in next MariaDB 11.x version, and if somebody implements this, it would be timely reviewed and merged?
There is already design outlined at https://jira.mariadb.org/browse/MDEV-30499
On Tue, Jul 25, 2023 at 11:39 PM Otto Kekäläinen otto@kekalainen.net wrote:
Hi!
I frequently see users running into various problems after upgrading MariaDB and starting the upgraded mariadbd server:
- Server might refuse to start, asking users to manually run mariadb-upgrade
Can you describe this one more, mariadb-upgrade requires the server started which is the point of this request to fix.
- Server might start, but misbehave as on-disk data format for regular tables or the system tables has not updated - On systems where mariadb-upgrade runs automatically on MariaDB service startup there might be unnecessary delay if mariadb-upgrade is run multiple times
This should be picked up by file locks and quick, but it is unnecessary.
- If running mariadb-upgrade fails or is slow, users might end up in a situation where they re-restart the server and have two mariadb-upgrade scripts running and blocking each other
They shouldn't be able to lock each other, file locks mean a block can be one way, and the later one will fail on acquiring the file lock.
- In some cases user might attempt to run mariadb-upgrade but it fails it the MariaDB server was not running, forcing user to figure out how to manually start the server for upgrades - Users might end up starting server in a mode that does not accept connections with the intent to only run mariadb-upgrade, but then don't understand they need to restart the server to have it serve connections again - Users planning upgrades get confused because because reading about Fedora based distros the DBA is requires to manually run mariadb-upgrade themselves, and reading about Debian based distros DBAs are not required to do this as it is automatic, but they might end up trying to run it manually anyway because of prior experience with Fedora
To add to this list: * Users change root credentials breaking packaging system upgrades that call mariadb-upgrade * Users end up without features which require mariadb-update to exist (there was a recent MDEV of this) * While performing a mariadb-upgrade, innodb doing recovery/applying redo logs. When mariadb-upgrade is finishes, scripted changes will shut the server down. innodb may not be finished, meaning the entire recovery/redo is lost and will need to start on the next recovery. * Running online is dangerous - MDEV-27606, running offline requires restarts
Some of the above issues can be remediated by running 'mariadb_upgrade --check-if-upgrade-is-needed' before actually running mariadb_upgrade in service scripts, but it does not work if server is offline (https://jira.mariadb.org/browse/MDEV-27636).
Agree, it's such a broken feature without being offline that Docker Official Images implement their own version check. I haven't seen a case of its use. https://github.com/MariaDB/mariadb-docker/blob/148b0e5d33be0eeb1bd4ef5cfccb3...
Making users aware that their database is running but mariadb-upgrade has not run can be done via https://github.com/MariaDB/server/pull/2464. However this are just duct tape to the original problem.
All of the above could be permanently solved if mariadbd simply did the upgrade by itself automatically.
It would be a great improvement to the ease of use that MariaDB already has some reputation for.
While some attempt to hide this complexity in packaging like https://github.com/MariaDB/mariadb-docker/blob/148b0e5d33be0eeb1bd4ef5cfccb3..., there are still unaddressed downsides previously mentioned.
Can we please have this?
Can we agree that this would be a desired feature in next MariaDB 11.x version, and if somebody implements this, it would be timely reviewed and merged?
There is already design outlined at https://jira.mariadb.org/browse/MDEV-30499
Thanks for showing the other use cases Otto.
- Server might refuse to start, asking users to manually run mariadb-upgrade
Can you describe this one more, mariadb-upgrade requires the server started which is the point of this request to fix.
This is a very popular one on Stack Overflow: https://stackoverflow.com/questions/27918764/cannot-load-from-mysql-proc-the... When users see the server failing to start and logs contain the very scary error message "mysql.proc corrupted". Some users might recover their entire database from backups as they think it was corrupted - but real fix is to simply run mariadb-upgrade which will update the system tables and the numer of columns/names in mysql.proc will match what the new mariadbd binary expects and then it will run just fine.
But this is just one example in a long list of scenarios where users suffer - all of them would go away if mariadbd itself did it's own upgrade without relying on any external admin or system to run a separate mariadb-upgrade script.
..
Can we please have this?
Can we agree that this would be a desired feature in next MariaDB 11.x version, and if somebody implements this, it would be timely reviewed and merged?
There is already design outlined at https://jira.mariadb.org/browse/MDEV-30499
Thanks for showing the other use cases Otto.
You are welcome! Looking forward and hoping this one will get traction.
Hi, Otto,
Automatically performing the upgrade in the server would pretty much mean that downgrade is officially impossible.
Historically the server mostly worked fine without mysql_upgrade, with few exceptions (like, when a bug in collations required indexes to be rebuilt).
Nowadays it seems we don't have an official position. The server kinda sorta is supposed to work, at least here and there I see the code in the server that is written to support old tables. But it's done inconsistently, there're more and more cases when the server won't work without mysql_upgrade, and documentation now says that mysql_upgrade must be run. This was not the case earlier, mysql_upgrade was optional.
Disallowing downgrades would, of course, simplify the server quite a bit, for example, privilege system has a lot of code for handling old privilege tables.
But considering that people sometimes do need to downgrade, would it be a welcome change if we'll totally prohibit it?
What I mean is - we need to take a position and either admit that we no longer allow downgrades *at all* or that downgrades *should work*.
In the first case, the server can auto-upgrade the datadir, this would be a user friendly thing to do.
In the second case, every time when mysql_upgrade is required it should be considered a bug. This is a more complex approach.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
On Jul 25, Otto Kekäläinen via developers wrote:
I frequently see users running into various problems after upgrading MariaDB and starting the upgraded mariadbd server:
...
All of the above could be permanently solved if mariadbd simply did the upgrade by itself automatically. Can we please have this?
Hi!
Automatically performing the upgrade in the server would pretty much mean that downgrade is officially impossible.
Historically the server mostly worked fine without mysql_upgrade, with few exceptions (like, when a bug in collations required indexes to be rebuilt).
Supporting "downgrades" shouldn't be tied to whether or not a DBA ran mariadb-upgrade, but whether they upgraded a *minor* version or a *major* version. For minor version downgrades should be possible even after running mariadb-upgrade.
So you are implying now that if a user runs say MariaDB 10.6.9 and upgraded to 10.6.12 and ran mariadb-upgrade, and after a week of running 10.6.12 and some serious bug has occurred and the user wants to swap back to MariaDB 10.6.9 by going back to old binaries but still keep running oldest data it is no longer possible in MariaDB?
If the above is no longer possible in MariaDB, how long do you recommend users to run a new binary but postpone running mariadb-upgrade after upgrading to a new minor version? A week? A month?
Otto, Sergei,
I will just add my view on the subject here.
Our documentation warns users that downgrades are not supported, even between minor versions, note the last paragraph.
https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
Once this is decided, the rest of the decisions should be made based on that. If you want to take a middle of the road approach, where downgrades work, unless specifically mentioned in the release notes, that needs to be documented too *and we need to test that in our CI*, which as far as I know, we do not.
So, Sergei, we should make a decision (or if one already has been made but I am not aware of it, put it in writing on the KB).
Vicentiu
On Thu, 27 Jul 2023, 16:25 Otto Kekäläinen via developers, < developers@lists.mariadb.org> wrote:
Hi!
Automatically performing the upgrade in the server would pretty much mean that downgrade is officially impossible.
Historically the server mostly worked fine without mysql_upgrade, with few exceptions (like, when a bug in collations required indexes to be rebuilt).
Supporting "downgrades" shouldn't be tied to whether or not a DBA ran mariadb-upgrade, but whether they upgraded a *minor* version or a *major* version. For minor version downgrades should be possible even after running mariadb-upgrade.
So you are implying now that if a user runs say MariaDB 10.6.9 and upgraded to 10.6.12 and ran mariadb-upgrade, and after a week of running 10.6.12 and some serious bug has occurred and the user wants to swap back to MariaDB 10.6.9 by going back to old binaries but still keep running oldest data it is no longer possible in MariaDB?
If the above is no longer possible in MariaDB, how long do you recommend users to run a new binary but postpone running mariadb-upgrade after upgrading to a new minor version? A week? A month? _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
On 27.07.23 17:33, Vicențiu Ciorbaru via developers wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
minor versions are not an issue. There were a very few cases where minor aspects of the mysql schema changed in minor releases, but AFAIR the last time we did that was in 10.2 days. Nowadays mysql_upgrade even immediately returns when seeing a stored version info file from a previous run containing the same major version number unless you use --force.
The problem always was with major upgrades only, and there we don't support downgrades not only as we don't have a tool to revert mariadb-upgrade changes (I filed a feature request for such a tool looooong ago when MySQL-MariaDB migrations still were a more common thing, back in 5.x days of 'in-place alternative', but it never happened ...). The other, and IMHO much more important reason, is that data file formats can change between major versions, and once a storage engine has started to write data using a new / change format that is not backwards compatible there is no way back anymore anyway.
Heck, we even have pre-upgrade checks in our RPM and deb packages that prevent you from doing a major version upgrade via "apt-get upgrade" or "yum update" to prevent such non-versible upgrades from happening accidentally, for major version upgrade you have to explicitly uninstall, then re-install, the server packet.
Or did I miss something here while merely browsing over the previous messages on the thread only?
On Thu, 27 Jul 2023 at 18:45, Hartmut Holzgraefe via developers < developers@lists.mariadb.org> wrote:
On 27.07.23 17:33, Vicențiu Ciorbaru via developers wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
minor versions are not an issue. There were a very few cases where minor aspects of the mysql schema changed in minor releases, but AFAIR the last time we did that was in 10.2 days. Nowadays mysql_upgrade even immediately returns when seeing a stored version info file from a previous run containing the same major version number unless you use --force.
We don't actively test this use case. If we don't test it, we can't say for certain that this is not an issue. Empirically, perhaps it works, but if we don't test, we always run the risk of not fulfilling that promise (and also not having warnings in release notes either). And this is not just about mariadb-upgrade only. If there was a forward-only change on the storage level, even if it's something that happens transparently to the end user, that also makes downgrading impossible.
Hence I would err on sticking to what we test and have the resources to manage, not say it "probably" works, or "in the past it was not an issue".
Vicentiu
On 27.07.23 17:59, Vicențiu Ciorbaru wrote:
We don't actively test this use case.
ok, I was under the impression that we actually did. I even seem to remember that this was explicitly mentioned in the communication regarding "no need to run mariadb-upgrade on minor updates anymore"
If this is indeed *not* tested then "no downgrades supported" should be clearly documented for minor upgrades, too. That we can agree on.
Hi, Vicențiu,
On Jul 27, Vicențiu Ciorbaru wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
Yes, this is exactly what I meant in my email too. We should make a decision and then it will determine what we'll do.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Hi, Vicențiu,
There's a compromise approach - mariadb-upgrade is required (and thus downgrade does not work) between major versions, but mariadb-upgrade is not needed (and downgrade works) between minor versions.
So, again, to summarize:
Premise: if mariadb-upgrade is required between versions X and Y, the downgrade from Y to X is impossible
* Option 1: mariadb-upgrade is never required, for any X and Y
* Option 2: mariadb-upgrade may be required for any X and Y
* Option 3: mariadb-upgrade is required when X and Y differ in the first two components and not required if they differ only in the third component
On Jul 28, Sergei Golubchik wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
Yes, this is exactly what I meant in my email too. We should make a decision and then it will determine what we'll do.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Hi, Vicențiu,
Monty voiced his opinion too, by editing the knowledge base page here: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
It seems that he prefers the "compromise approach", downgrade is supported between versions that only differ in the third version component (patch version) as long as both are RC or GA.
Opinions?
On Jul 29, Sergei Golubchik wrote:
Hi, Vicențiu,
There's a compromise approach - mariadb-upgrade is required (and thus downgrade does not work) between major versions, but mariadb-upgrade is not needed (and downgrade works) between minor versions.
So, again, to summarize:
Premise: if mariadb-upgrade is required between versions X and Y, the downgrade from Y to X is impossible
* Option 1: mariadb-upgrade is never required, for any X and Y
* Option 2: mariadb-upgrade may be required for any X and Y
* Option 3: mariadb-upgrade is required when X and Y differ in the first two components and not required if they differ only in the third component
On Jul 28, Sergei Golubchik wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
Yes, this is exactly what I meant in my email too. We should make a decision and then it will determine what we'll do.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Hi Sergei!
From a user's perspective I support that position. It is quite friendly. It also gives users a very simple way out if we ever do a "bad release", until we release the hotfix patch. (not that we should be doing bad releases in general, but we know it happens)
From a server developer's perspective, it does come with some care needed when doing bug fixing, yet it really aligns well with the ideals of Semantic Versioning and that I like.
The challenge for this approach lies in testing it. Let's take a fictitious example such as: 10.11.5 (GA) as an older version and 10.11.10 (GA).
Pragmatically, what we can do in our CI/CD is test downgrading from the current version to the previous point version. Doing it from the current version to all past versions would be rather expensive I would think.
So in this scenario, we test downgrade from 10.11.10 to 10.11.9 and it works fine. In the past we would have tested 10.11.9 downgrade 10.11.8 and it should've also worked fine.
Now, given this testing chain, can we guarantee 10.11.10 -> 10.11.5 is safe? Is this a transitive property? Probably not always, but very likely.
Another aspect of difficulty in testing is *what* are the actual requirements to be "downgrade safe"? Starting the server on a data dir is one thing. Ensuring all functionality is present is another. Additionally, ensuring no data incompatibilities exist is hard to test for.
Despite these potential challenges, I'm all for this approach as it makes our user's lives easier.
Vicentiu
On Tue, 1 Aug 2023 at 16:00, Sergei Golubchik via developers < developers@lists.mariadb.org> wrote:
Hi, Vicențiu,
Monty voiced his opinion too, by editing the knowledge base page here: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/
It seems that he prefers the "compromise approach", downgrade is supported between versions that only differ in the third version component (patch version) as long as both are RC or GA.
Opinions?
On Jul 29, Sergei Golubchik wrote:
Hi, Vicențiu,
There's a compromise approach - mariadb-upgrade is required (and thus downgrade does not work) between major versions, but mariadb-upgrade is not needed (and downgrade works) between minor versions.
So, again, to summarize:
Premise: if mariadb-upgrade is required between versions X and Y, the downgrade from Y to X is impossible
* Option 1: mariadb-upgrade is never required, for any X and Y
* Option 2: mariadb-upgrade may be required for any X and Y
* Option 3: mariadb-upgrade is required when X and Y differ in the first two components and not required if they differ only in the third component
On Jul 28, Sergei Golubchik wrote:
Rather than offer a half-truth, I would us just take a clear stance. We either fully support downgrading between minor versions officially (which has implications on how we approach bug fixes, especially on the storage side), or we don't even encourage it at all, stating "at your own risk", or do a full dump and restore as the only recovery method.
Yes, this is exactly what I meant in my email too. We should make a decision and then it will determine what we'll do.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-leave@lists.mariadb.org
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.
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.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
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.
Hi, Jean,
On Aug 02, Jean Weisbuch via developers wrote:
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.
Mostly, but not always. Sometimes it modifies other tables too.
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.
Agree. Even if upgrades aren't automatic, one still often doesn't know the new version won't work until after the upgrade. So not allowing to revert a minor upgrade would be very problematic.
It seems that everyone who cared to comment supported the approach where minor downgrades should work, but major downgrades aren't guaranteed to work. So, this is the rule we'll try to follow consistently from now on.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
Sergei Golubchik via developers developers@lists.mariadb.org writes:
There's a compromise approach - mariadb-upgrade is required (and thus downgrade does not work) between major versions, but mariadb-upgrade is not needed (and downgrade works) between minor versions.
I agree with this approach.
- Kristian.
On Wed, 2 Aug 2023 at 10:37, Kristian Nielsen via developers developers@lists.mariadb.org wrote:
Sergei Golubchik via developers developers@lists.mariadb.org writes:
There's a compromise approach - mariadb-upgrade is required (and thus downgrade does not work) between major versions, but mariadb-upgrade is not needed (and downgrade works) between minor versions.
I agree with this approach.
Seems most people agree on this and it is also aligned with what https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ states.
Thus we should work towards architecting systemd scripts and other startup scripts to *not* run mariadb-upgrade automatically and restrict that only to major version upgrades. We need to stop running mariadb-upgrade both for users and in CI, so that users actually can benefit from this policy and that CI can detect if it is broken. Any change that requires mariadb-upgrade to run on a X.Y.n minor release should be treated as a bug, and MTR tests that call upgrade_from/test_upgrade.sh on minor upgrades should be adjusted to not run the upgrade at all.
Still, having a future 11.X mariadbd run the upgrade automatically if it detects that there has been a major version upgrade would help simplify packaging/service scripts and prevent users from running into issues that arise if mariadb-upgrade was omitted after a major version upgrade.
Hi, Otto,
On Jul 27, Otto Kekäläinen wrote:
Hi!
Automatically performing the upgrade in the server would pretty much mean that downgrade is officially impossible.
Historically the server mostly worked fine without mysql_upgrade, with few exceptions (like, when a bug in collations required indexes to be rebuilt).
Supporting "downgrades" shouldn't be tied to whether or not a DBA ran mariadb-upgrade, but whether they upgraded a *minor* version or a *major* version. For minor version downgrades should be possible even after running mariadb-upgrade.
No, this is logically impossible.
If you upgrade from the version X to the version Y (and it doesn't matter whether it's a major or a minor upgrade) and mariadb-upgrade changes *something* (anything at all) then by definition the datadir will be not as the version X expects it and version X won't be able to read it anymore because, as an older version, it cannot possibly take into account changes made by the mariadb-upgrade of the newer version Y.
So the question is, as Vicențiu put it - what is the official position of MariaDB regarding downgrades? Shall we support them or not? What would you prefer us to do? Why?
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
participants (8)
-
Daniel Black -
Hartmut Holzgraefe -
Jean Weisbuch -
Kristian Nielsen -
Otto Kekäläinen -
Sergei Golubchik -
Vicențiu Ciorbaru -
Vicențiu Ciorbaru