Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
Spider, CS and potentially other plugins install udf functions, stored functions and stored procedures. The mysql_upgrade is changes the format of mysql.func, proc and other system tables related to those operations. Evidenced by:
- MDEV-14622 spider / mysql_upgrade deadlock - drop procedure / alter table proc
- MDEV-27107 spider / mysql_upgrade deadlock - create udf function / alter table func
Including but not limited to:
- User connections
- Installation of other packages (e.g. spider, CS) and their plugins
A solution part of packaging might look like:
mysql_upgrade --check-if-upgrade-is-needed
followed by a temporary start of the server (additional options - https://jira.mariadb.org/browse/MDEV-27068?focusedCommentId=207708&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-207708), maybe put these in a [mariadb.upgrade] group the in the configuration file and use --defaults-group-suffix=.upgrade.
followed by mysql_upgrade --upgrade-system-tables
Attachments
Issue Links
- includes
-
MDEV-27636 mariadb_upgrade --check-if-upgrade-is-needed cannot be run offline
-
- Open
-
- relates to
-
-
- Stalled
-
-
MDEV-30499 mariadb in-server upgrade
-
- Open
-
- split from
-
-
- Closed
-
Activity
Please update the Description why we have to run mysql_upgrade BEFORE we install spider (or other plugins).
It would good if an Description starts with describing the problem and then updated with all the possible solutions for it.
The title and description of this issue is wrong/misleading. Debian maintainer scripts (postinstall/preinstall) do not run mariadb-upgrade nor mysql_upgrade. All the references to those commands are inside comments or in reference to temporary data directory /var/lib/mysql-upgrade. The Debian packaging does not call mariadb-upgrade.
± grep mariadb-upgrade debian/*
|
debian/changelog: * Move mariadb-upgrade to same package as mysql-upgrade and manpage
|
debian/mariadb-server-10.6.postinst: # perform mariadb-upgrade, (MDEV-22678). To keep the impact minimal, we
|
debian/mariadb-server-core-10.6.install:usr/bin/mariadb-upgrade
|
debian/mariadb-server-core-10.6.install:usr/share/man/man1/mariadb-upgrade.1
|
debian/mariadb-server-core-10.6.links:usr/bin/mariadb-upgrade usr/bin/mysql_upgrade
|
|
|
± grep mysql_upgrade debian/*
|
debian/changelog: * Automate renaming MySQL auth_socket correctly in mysql_upgrade
|
debian/changelog: * Prevent mysql_upgrade from being triggered on every server restart
|
debian/changelog: * Move mysql_upgrade to server core package so that Akonadi and similar
|
debian/changelog: * New upstream release. Fixed the server crash caused by mysql_upgrade
|
debian/mariadb-server-10.6.postinst: mysql_upgradedir=/var/lib/mysql-upgrade
|
debian/mariadb-server-10.6.postinst: savelink="$mysql_upgradedir/$dir.link"
|
debian/mariadb-server-10.6.postinst: rmdir $mysql_upgradedir 2>/dev/null || true
|
debian/mariadb-server-10.6.postinst: # mysql_upgrade, called from the /etc/init.d/mariadb start script, will
|
debian/mariadb-server-10.6.postinst: echo "[mysql_upgrade]" >>$dc
|
debian/mariadb-server-10.6.preinst:mysql_upgradedir=/var/lib/mysql-upgrade
|
debian/mariadb-server-10.6.preinst: mkdir -pZ "$mysql_upgradedir"
|
debian/mariadb-server-10.6.preinst: cp -dT "$checkdir" "$mysql_upgradedir/$dir.link"
|
debian/mariadb-server-10.6.README.Debian:There should not be any need to run 'mysql_upgrade' manually, as the upgrade
|
debian/mariadb-server-core-10.6.install:usr/share/man/man1/mysql_upgrade.1
|
debian/mariadb-server-core-10.6.links:usr/bin/mariadb-upgrade usr/bin/mysql_upgrade
|
debian/not-installed:usr/bin/mysql_upgrade
|
The only thing that runs the upgrade is the startup scripts (systemd or init.d) which are largely inherited from how the server upstream wants to be started, and there is no Debian specific thing to fix about mariadb-upgrade.
mysql_upgrade or mariadb-upgrade is run from debian/additions/debian-start.inc.sh included into debian/additions/debian-start, which in turn is run from debian/mariadb-server-10.8.mariadb.init.
Which was the source of the original problem (you'll see it if you walk the issue links up) — on every mariadb startup, debian runs mysql_upgrade in the background in parallel with any other user load. This was causing deadlocks and unpredictable results. That's why the issue subject is "not run mariadb-upgrade at the same time as anything"
rpm packages do not run mysql_upgrade or mariadb-upgrade at all, so this is very much debian-specifc issue.
rpm packages aren't perfect — not running mariadb-upgrade is also bad, but differently.
note that the temporary start of the server needs to prevent plugin initialization.
Scenario:
MariaDB 10.2 installed.Then 10.3 installed with spider (e.g) package as well.
Like all plugins a plugin-load-add option in a configuration file is dropped and will auto-install on startup.
From https://mariadb.com/kb/en/install-plugin/ is appears skip-grant-tables isn't sufficient to prevent it loading. plugin_dir=/dev/null maybe.