Details
Description
From https://github.com/MariaDB/mariadb-docker/issues/350
Its causing problems for users https://github.com/AzuraCast/docker-azuracast-db/issues/3
If we have a healthcheck (MDEV-25434), then we'll need to ensure that only returns health after mysql_upgrade is run.
" the most difficult problem is detection of when it ought to be run because it requires the server to be up before it can run (so it requires the same temporary server logic as the initial bootstrapping), so it isn't reasonable to just run it every time"
Maybe a direct inspection of the FRM format in MDEV-23008
Attachments
Issue Links
- relates to
-
MDEV-23008 store mysql_upgrade version info in system table instead of local file
-
- Open
-
-
MDEV-25434 mariadb container to have HEALTHCHECK
-
- Closed
-
- links to
Activity
Prototype https://github.com/MariaDB/mariadb-docker/commit/ad50437313e02c82e3ec902cb1e71f22636c1d3c
While debian users might tolerate a two start approach (MDEV-27613), container users only just tolerate this on initialization.
So MDEV-27636 is blocking this. There's only on version of mariadbd/mariadb-upgrade in the container.
Fixed with https://github.com/MariaDB/mariadb-docker/pull/407 as opt in feature.
Still a few too many hacks which will be simplified with:
Test timeouts due to missing https://github.com/MariaDB/server/commit/6b4f0d782c973bd49ad62a67add36d4773852c3a (released version 10.4+, CI versions 10.5+)
As MDEV-23008 describes, when mysql_upgrade runs, it creates mysql_upgrade_info file in the data directory. The file contains the server version on which mysql_upgrade was run.
This file is used by mysql_upgrade itself to determine whether it should run again. It only runs if the file doesn't exist, or the version doesn't match the current one (or if it's started with --force, but that's irrelevant).
So, the same criteria can be used here.
It may be imperfect (as MDEV-23008 also describes), but it should be sufficient here, as the most arguments from MDEV-23008 don't apply to the use case.
Besides, MDEV-23008 probably won't be implemented any time soon (if ever).