How to make mariadb database changes persistent

[dmaze (David Maze)]

@keithroberts

Mariadb stores it’s databases in /var/lib/mysql.

…and the standard images declare that as a VOLUME, so if you do nothing special, if you start a database container, do some activity on it, stop the container, and restart it again, you should see the same content (provided you don’t docker rm -v or docker volume rm to destroy the backing volume).

If you’re using Docker Compose, I think it’s a little more aggressive about cleaning up volumes, and you might be well-served to use the version 2 Compose file format (if you can use a new enough Docker stack for that) and separately declare the data volume.

So it looks like I might need to move the mariadb database to it’s own DATA container, and then tell the piwik-database container running the mariadb server application to use that as a shared volume?

The application shouldn’t need to access the files underneath the database, so you shouldn’t need to share the volume.

This seems to be the best option at the moment, as it allows more than one container to share the same database cluster.

You can always have multiple containers talking to the same database server. Probably the best setup on a current Docker environment is:

• Create a named data volume to hold the database contents
• Create a private bridge network
• Spin up a single MariaDB server, on the private network, using the named data volume
• Spin up any number of applications, pointing them at mariadb:3306 for their database server, and relying on Docker’s internal DNS resolution to point them at the container named mariadb

So I guess shared data volumes would be usefull for writing any persistent data such as log files, which could eventually use up the maximum number of image layers available to a container?

That statement doesn’t quite make sense. I never use docker commit; while I do have quite a few private images, I build them with Dockerfiles and docker build. Shared data volumes are useful for things like log files, but mostly in that they need to be read by host administrators regularly who don’t want to have to dive into container space to do it.

For your particular situation, my application that needs a significant amount of preloaded database content works by having a script that starts up the database, loads the data, and then runs a mysql_dump. That dump file is packed into my application image, and when it starts up, an ENTRYPOINT script restores the dump if it’s required.