Details
-
Task
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
The competing requirements around mariadb-upgrade make the current solution undesirable:
- mariadb-upgrade should be conducted without user load
- multiple startups of the server takes time and can was a lot of time in innodb recovery/page loading
- scripted deployments shouldn't bare the responsibility of understanding the complexity
- service scripts like systemd and containers make mariadb available on sd_notify=READY or the network connection being listened too.
So ideally:
- compile the upgrade SQL into the server (cold attribute)
- Use include/mysql/service_sql.h or bootstrap like interface to run the SQL
- allow skipping by non-default system variable auto_upgrade=1
- execute before tcp/unix sockets are bound/listening
- use service_manager_extend_timeout in some way
- lock state file like mariadb-upgrade (and keep this for compatibility)
Attachments
Issue Links
- relates to
-
MDEV-27060 mariadb_upgrade runs every startup
-
- Closed
-
-
-
- Closed
-
-
MDEV-27107
prevent two mariadb-upgrade running in parallel
-
- Closed
-
-
MDEV-27279
mariadb_upgrade add --check-if-upgrade-is-needed / restrict tests to major version
-
- Closed
-
-
-
- Open
-
-
-
- Stalled
-
-
MDEV-27636 mariadb_upgrade --check-if-upgrade-is-needed cannot be run offline
-
- Open
-
-
MDEV-30498
Rename mysql_upgrade state file to mariadb_upgrade
-
- Closed
-
-
-
- Confirmed
-
- links to
Activity
I don't see any drawbacks with the server doing the upgrade automatically.
The server startup speed will be fast if the server check the existence of /var/lib/mysql/mariadb-upgrade-info file on startup and based on its contents decides to attempt automatic upgrade, as such a file check sub-millisecond operation.
In rare cases when a DBA has a use case to not do it, they can use the auto_upgrade=0 config or --skip-auto-upgrade.
The upside however is huge: When the server does the upgrade by itself it will be much more reliable, as it is very hard to end up having none or multiple mariadb-upgrades running in parallel. That whole category of bugs would go away.
This architecture would also greatly simplify the SysV init and systemd startup files as they don't need to check for any upgrades anymore. Most likely also the deb and rpm install/upgrade maintainer scripts could be simplified after this.
If we had this automatic upgrade inside mariadbd, bugs like MDEV-27060 and MDEV-27606 would not occur.
I am definitely in favor of having automatic in-server upgrade on every mariadbd start.
I believe monty was not keen on this feature being implemented. I don't remember the details, just that there was a discussion over it between him and danblack.
Lucky there's a documented discussion with a user interest and valid points around function and testing that can supersede that.
Is there any update on this issue? I think this can help to improve the upgrade process reliability. Knowing that the server itself will take care of updating the DB tables will make the upgrade process more simpler i.e less prone to errors, specially in automated environments when the upgrade process is automated and it might be harder to catch unexpected errors. Also, if some extra hands are needed I could lock some time to start working on this.