JKJameson
commented
4 years ago When you redeploy the stack like this, the containers are deleted. So if you didn't have a mount for /var/lib/mysql your data was deleted as it was inside the container. Redeploying a stack deletes all the containers at once, so all your database copies are simultaneously deleted.
This works well for me
--mount type=bind,source=/d/galera/data,target=/var/lib/mysql
I use the mariadb 10.3 image with the actual swarm example on a 4 master node docker swarm.
At an earlier release with an earlier docker-compose file and the mariadb 10.1 image. A restart of one of the 4 swarm nodes distributes all galera containers over all running nodes. If the restartet swarm node comes back, a galera ccontainer would be startet of them.
I assume after renaming the volume name to name: '{{.Service.Name}}-{{.Task.Slot}}-data' and the dnsrr in the swarm config all galera nodes are able to run on the same node and the distrubtion over the docker swarm doesn't work anymore.
The hope that the
docker stack deploy -c docker-compose.yml galerafixes this and start a redepolyment of the galera nodes, ends with a restart of the cluster from an empty seed and deletes all data in the cluster.Perhaps it is fixable with some placement rules in the docker file. But the behavior on restarting is strange. In the earlier relase of the docker-compose.yml the seed and the later starting node use the same data in the mysql-volume. In the actual version the seed seems to start with last seed data volume.
In a extrem version of the this scenario all galera containers reside on the same swarm node, what the fail-safety thwarted.