From 5966df5b9120f16eeee8ba1379e7ec691c1a6197 Mon Sep 17 00:00:00 2001 From: Eric Nemchik Date: Sun, 28 May 2023 21:45:00 -0500 Subject: [PATCH 1/4] Known Issue: MariaDB Check and Repair Signed-off-by: Eric Nemchik --- content/issues/2023-05-28-mariadb.md | 43 ++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 content/issues/2023-05-28-mariadb.md diff --git a/content/issues/2023-05-28-mariadb.md b/content/issues/2023-05-28-mariadb.md new file mode 100644 index 00000000..ed953ff9 --- /dev/null +++ b/content/issues/2023-05-28-mariadb.md @@ -0,0 +1,43 @@ +--- +title: 'Known Issue: MariaDB Check and Repair' +date: '2023-05-28 12:00:00Z' +severity: notice +resolved: false +affected: + - 'Known Issues' + - 'mariadb' +section: 'issue' +--- +There is a known issue with MariaDB when updating the container image and a database upgrade is required on user databases that are not in a healthy state. This can prevent MariaDB from starting. + +MariaDB version updates (ex: `10.6.x` to `10.11.x`) can happen when updating the container image. Upgrading user databases is done manually by running a command. + +When the container initializes, if `MYSQL_ROOT_PASSWORD` is set an upgrade check will run. If an upgrade is required the log will indicate the need to run: + +```shell +mariadb-upgrade -u root -p +``` + +If user databases are not in a healthy state (sometimes caused by a failed upgrade), it may be remedied by running: + +```shell +mariadb-check -u root -p -c -A # check all databases for errors +mariadb-check -u root -p -r -A # repair all databases +mariadb-check -u root -p -a -A # analyze all databases +mariadb-check -u root -p -o -A # optimize all databases +``` + +After running the above commands, you may need to run the upgrade command again. + +If you have recently updated your container image and your container logs show repeating entries of: + +```log +Caught SIGTERM signal! +``` + +- Roll back the container image to a previous tag (ex: `lscr.io/linuxserver/mariadb:10.6.13` assuming this was the version you were running when things were last working) +- Run the check, repair, analyze, and optimize commands above, watch for any issues +- Update the container image to the new tag (ex: `lscr.io/linuxserver/mariadb:10.11.3` or `lscr.io/linuxserver/mariadb:latest`) +- Run the upgrade command above + +This should get MariaDB running again with your user databases in a healthy state. From 48fc3a9541c05d7e3df300655a20dd321b0553ef Mon Sep 17 00:00:00 2001 From: Eric Nemchik Date: Mon, 29 May 2023 08:25:34 -0500 Subject: [PATCH 2/4] Update 2023-05-28-mariadb.md --- content/issues/2023-05-28-mariadb.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/issues/2023-05-28-mariadb.md b/content/issues/2023-05-28-mariadb.md index ed953ff9..5d2580b0 100644 --- a/content/issues/2023-05-28-mariadb.md +++ b/content/issues/2023-05-28-mariadb.md @@ -8,7 +8,7 @@ affected: - 'mariadb' section: 'issue' --- -There is a known issue with MariaDB when updating the container image and a database upgrade is required on user databases that are not in a healthy state. This can prevent MariaDB from starting. +There is a known issue with MariaDB when updating the container image to a new version. If a database upgrade is required and user databases are not in a healthy state, then the MariaDB service may fail to start. MariaDB version updates (ex: `10.6.x` to `10.11.x`) can happen when updating the container image. Upgrading user databases is done manually by running a command. From 2505217ea6d06b00a1b413d44108c47f0a6cccee Mon Sep 17 00:00:00 2001 From: Eric Nemchik Date: Mon, 29 May 2023 09:21:21 -0500 Subject: [PATCH 3/4] Rearrange, separate sections, and improve wording Signed-off-by: Eric Nemchik --- content/issues/2023-05-28-mariadb.md | 32 ++++++++++++++++++---------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/content/issues/2023-05-28-mariadb.md b/content/issues/2023-05-28-mariadb.md index 5d2580b0..5ecf4567 100644 --- a/content/issues/2023-05-28-mariadb.md +++ b/content/issues/2023-05-28-mariadb.md @@ -12,12 +12,23 @@ There is a known issue with MariaDB when updating the container image to a new v MariaDB version updates (ex: `10.6.x` to `10.11.x`) can happen when updating the container image. Upgrading user databases is done manually by running a command. -When the container initializes, if `MYSQL_ROOT_PASSWORD` is set an upgrade check will run. If an upgrade is required the log will indicate the need to run: +### Recovery Procedure -```shell -mariadb-upgrade -u root -p +If you have recently updated your container image and your container logs show repeating entries of: + +```log +Caught SIGTERM signal! ``` +- Roll back the container image to a previous tag (ex: `lscr.io/linuxserver/mariadb:10.6.13` assuming this was the version you were running when things were last working) +- Run the check, repair, analyze, and optimize commands, watch for any issues +- Update the container image to the new tag (ex: `lscr.io/linuxserver/mariadb:10.11.3` or `lscr.io/linuxserver/mariadb:latest`) +- Run the upgrade command + +This should get MariaDB running again with your user databases in a healthy state. + +### Check and Repair + If user databases are not in a healthy state (sometimes caused by a failed upgrade), it may be remedied by running: ```shell @@ -29,15 +40,14 @@ mariadb-check -u root -p -o -A # optimize all databases After running the above commands, you may need to run the upgrade command again. -If you have recently updated your container image and your container logs show repeating entries of: +### Upgrading -```log -Caught SIGTERM signal! +When this container initializes, if `MYSQL_ROOT_PASSWORD` is set an upgrade check will run. If an upgrade is required the log will indicate the need stop any services that are accessing databases in this container, and then run the command: + +```shell +mariadb-upgrade -u root -p ``` -- Roll back the container image to a previous tag (ex: `lscr.io/linuxserver/mariadb:10.6.13` assuming this was the version you were running when things were last working) -- Run the check, repair, analyze, and optimize commands above, watch for any issues -- Update the container image to the new tag (ex: `lscr.io/linuxserver/mariadb:10.11.3` or `lscr.io/linuxserver/mariadb:latest`) -- Run the upgrade command above +### Closing Notes -This should get MariaDB running again with your user databases in a healthy state. +If you are running MariaDB databases in production, we always recommend pinning the container image to a specific version tag, such as `lscr.io/linuxserver/mariadb:10.6.13-r0-ls97`, and planning any upgrades so that you can test and monitor them. From 3e4dfc026a7a7c5642724ed3ddefa287b8ba34d6 Mon Sep 17 00:00:00 2001 From: Eric Nemchik Date: Mon, 29 May 2023 10:29:55 -0500 Subject: [PATCH 4/4] Update date for mariadb check/repair Signed-off-by: Eric Nemchik --- content/issues/{2023-05-28-mariadb.md => 2023-05-29-mariadb.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename content/issues/{2023-05-28-mariadb.md => 2023-05-29-mariadb.md} (98%) diff --git a/content/issues/2023-05-28-mariadb.md b/content/issues/2023-05-29-mariadb.md similarity index 98% rename from content/issues/2023-05-28-mariadb.md rename to content/issues/2023-05-29-mariadb.md index 5ecf4567..419e4e05 100644 --- a/content/issues/2023-05-28-mariadb.md +++ b/content/issues/2023-05-29-mariadb.md @@ -1,6 +1,6 @@ --- title: 'Known Issue: MariaDB Check and Repair' -date: '2023-05-28 12:00:00Z' +date: '2023-05-29 12:00:00Z' severity: notice resolved: false affected: