Docker container with Mariadb - Can the container get bricked and lose data

Question

I thought I can use Bound volumes as suggested for my another post

Docker-compose mariadb external volume mapping issue

But I read that containers should be stateless. So it seems my thinking is wrong?

I do not know what catastrophic failures can occur, so is there a possibility that I may lose all data, if the container is bricked? or is there a way to use external storage and recover?

How to manage this situation? I have a schema table which manages migrations, so don't want that table to be new and start from square 1

Question: Should I let the mariadb container on cloud write to wherever it likes? or write to host folder?

My docker -compose snippet

  mariadb:
    image: mariadb:10.4
   ...
    environment:
      ..
    logging:
...
    networks:
      - backend
    restart: on-failure
    volumes:
      - maria_volume:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci
  
# Volumes
volumes:
  maria_volume:

Another version is (./mariadb instead of maria_volume in volumes section)

    networks:
      - backend
    restart: on-failure
    volumes:
      - ./mariadb:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_general_ci
  

Answer 1

Your application at large needs to keep data somewhere. Having a relational-database container with storage mounted is fine. In a production environment you could choose to run a non-container database or use a cloud-hosted database if that met your needs better.

I feel like the actual storage mechanisms are pretty robust, both for named volumes and bind-mounted host directories. You probably will not have data-corruption problems in either case. As always, make sure you have backups of your data if it's at all important.

There's not a clear choice between using named volumes and host directories here. Host directories are probably easier to back up and restore; on some platforms named volumes will be faster. In both cases, in normal operation, the data will survive destroying and recreating the container. It'll be a little easier to destroy a named volume's state using docker commands, which depending on your specific use case could point in either direction.

It has occasionally happened to me that Docker's internal state gets corrupted, and when this happens the easiest workaround is to delete the entire /var/lib/docker tree and start over (there is an equivalent "reset" button in the Docker Desktop application). This path would lose named volumes too. On native Linux it's been widely observed that the actual named-volume storage is just a directory, so you might be able to preserve this.