You could technically pin your MySQL container to one host, but that seems to defeat the point of fleet. I considered trying to mount an iSCSI target to run the database from, but CoreOS doesn't have a working iSCSI initiator.
I guess I could just run all the persistent stuff on a more traditional OS, but then why mess with CoreOS at all?
https://github.com/leg100/docker-ebs-attach
You'll need three fleet units in total:
- one to attach the EBS volume (wrapping the above container)
- one to mount the device to a directory on the host
- one to run the DB container, with a bind mount to the host directory
CoreOS seems to do a decent job as the application layer for something operating in a larger cloud that provides database and file storage as services, like Amazon or OpenStack. However, I think Docker has the potential to eliminate the need for infrastructure-level "clouds" to be so complex. The basic unit can be the container instead of the instance, so you don't need fancy automated instance management and all that. It'd be nice if you could also obviate the need for the other external services, and just run everything in containers on metal.
I was really excited by CoreOS as a way to do this, but it seems to fighting me at every turn. It seems much easer to just wire together the REST APIs of several Ubuntu/CentOS nodes running Docker.
That is more likely what they'd have in mind than a single MySQL master container.
That explains how they chose to minimize deadlocks.
Yes, if you use it incorrectly and/or for the wrong problem space, you will have issues. It isn't a magical solution to all problems. It is, however, an effective solution for a specific problem space.
This is after configuring HAProxy to have a primary node which all connections go to.
OpenStack seems to be OK with it though, it chugs along without fully breaking down. I'm sure I would see a pretty big performance delta if I ran a benchmark against it with and without Galera.