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.