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
-
MDEV-27068 running mariadb-upgrade on mariadb server with other user make it hangs forever
- 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
-
MDEV-27606 change debian packaging to not run mariadb-upgrade at the same time as anything
- Open
-
MDEV-27613 Fixing debian to only run the full mysql_upgrade process when necessary
- 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
-
MDEV-35297 Table will encounter rebuild during minor version upgrade if contains hashing index on TEXT type unique key
- Confirmed
- links to