Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
On Debian, the mariadb_upgrade process is run at every start/reboot of the mariadb-server.
This is problematic because:
- most of the time it's not needed;
- if maria_upgrade has to be run, as in case of a major upgrade, then check and possible fix of tables can take from a few seconds to 20-30 seconds (normally) but potentially much longer if there is was a change in a character collation;
- If during this time another maria_upgrade is run then it is very likely that mariadb_upgrade will hang because of unexpected conflicts. This is because maria_upgrade was not designed to be run in parallel (should now be fixed by
MDEV-27279); - If anyone else connects to mysqld/mariadbd during maria_upgrade, bad things can happen as the tables are not up to date for the system. The possible problems are hangs or wrong data from selects or errors from table updates (as the indexes may not be up to date).
Here are some questions summarized from MDEV-27068:
- how to integrate this in a many packages upgrade scenario?
- what is the right moment to run the mariadb_upgrade (post-install script, startup/restart), if needed?
- should we split system tables upgrade (quick) and the rest of the tables upgrade (can be very long)?
- is this feasible with systemd directives (man systemd.directives) or should a script handle alone the whole process?
- what about sysv init?
Attachments
Issue Links
- is part of
-
MDEV-27068 running mariadb-upgrade on mariadb server with other user make it hangs forever
- Closed
- relates to
-
MDEV-27167 system variable deferred-networking to resolve early initialization
- Closed
-
MDEV-27606 change debian packaging to not run mariadb-upgrade at the same time as anything
- Open
-
MDEV-30499 mariadb in-server upgrade
- Open
-
MDEV-25887 "Got notification message from PID xxxx, but reception only permitted for main PID yyyy" in systemd during SST
- Closed