[MDEV-25670] mariadb container needs to run mysql_upgrade Created: 2021-05-13  Updated: 2022-01-31  Resolved: 2022-01-29

Status: Closed
Project: MariaDB Server
Component/s: Docker
Fix Version/s: 10.2.42, 10.3.33, 10.4.23, 10.5.14, 10.6.6, 10.7.2, 10.8.1

Type: Task Priority: Major
Reporter: Daniel Black Assignee: Daniel Black
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Blocks
Relates
relates to MDEV-27167 system variable deferred-networking t... Closed
relates to MDEV-23008 store mysql_upgrade version info in s... Open
relates to MDEV-25434 mariadb container to have HEALTHCHECK Closed

 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



 Comments   
Comment by Elena Stepanova [ 2021-06-02 ]

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).

Comment by Daniel Black [ 2022-01-28 ]

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.

Comment by Daniel Black [ 2022-01-29 ]

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+)

Generated at Thu Feb 08 09:39:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.