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.
If you have recently updated your container image and your container logs show repeating entries of:
Caught SIGTERM signal!
lscr.io/linuxserver/mariadb:10.6.13 assuming this was the version you were running when things were last working)lscr.io/linuxserver/mariadb:10.11.3 or lscr.io/linuxserver/mariadb:latest)This should get MariaDB running again with your user databases in a healthy state.
If user databases are not in a healthy state (sometimes caused by a failed upgrade), it may be remedied by running:
mariadb-check -u root -p<PASSWORD> -c -A # check all databases for errors
mariadb-check -u root -p<PASSWORD> -r -A # repair all databases
mariadb-check -u root -p<PASSWORD> -a -A # analyze all databases
mariadb-check -u root -p<PASSWORD> -o -A # optimize all databases
After running the above commands, you may need to run the upgrade command again.
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:
mariadb-upgrade -u root -p<PASSWORD>
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.
Last updated: September 5, 2023 at 7:11 PM