With modern techniques, it's relatively trivial to create a clustered, high-availability solution for webservers by using docker (or comparable) to handle the front-end serving of pages to users.
e.g. for a LAMP stack, docker would handle the "A" and "P" parts.
Is there any way to make the database (e.g. mysql) work in a similar high-availability system with docker or comparable.
There are docker images for running opensource databases in high availability mode such as https://info.crunchydata.com/blog/an-easy-recipe-for-creating-a-postgresql-cluster-with-docker-swarm
You can also find examples of Microsoft SQLServer container for Linux being run with high availability on Kubernetes https://docs.microsoft.com/en-us/sql/linux/tutorial-sql-server-containers-kubernetes
Your question is missing an important concept from the devops perspective. If we run a particular version of a database (MySQL, PostresQL, SQLServer) on either a physical server, or a VMware ESX virtual machine server, or an openstack Xen virtual server, or in Docker in a laptop or in an http://cri-o.io container runtime in Kubernetes it’s “the same software”. If the high availability is based on running two or three instances of the database, and them opening tcp sockets to exchange data, and perform leader failover, then as “it’s the same software” it doesn’t matter whether we are running the database cluster as physical, or on a virtual machine hypervisor, or in a container orchestrator. That means you can learn how to configure the software for HA as containers on your laptop to then know how to configure it for HA on physical servers.
Obviously you might get different performance on different hardware or virtual machines or container runtimes. Typically it’s disk bandwidth and memory that makes the biggest difference for a database not how the process is being run (within reason). Yet from the perspective of making a high availability setup if the software you are using to only needs normal disk and normal tcp connections you can expect it to work anywhere that lets you access disk and network. It is then a matter of making sure that you provide enough cpu, memory, disk and network of sufficient reliability to meet your NFRs and SLAs.
A lot of companies might setup virtual machine farms or container orchestrators while not thinking about the demands of relational databases running in high availability modes. For example if you configure a HA setup of two Postgres instances but they get placed in two different virtual machine on the same physical server then you have a very poor setup with respect to the likelihood of one machine fault killing both database servers. If you configure all disk to be NAS network drives then that might be fine to run application servers but terrible to run databases under load. Often people are only thinking about scaling up application servers and having many of them crash and restart on different machines as the aim without the same disk being attached at startup. Anyone trying to run a database cluster in such an environment is going to have many sleepless nights. This means it’s important to ensure that wherever you run your databases is sympathetic to the needs of databases to have relative stability. If the environment is optimised and operating as though everything hosted is a stateless application server workloads that is not fussy about being moved around and restarted at random you might regret setting up a database cluster there.
I do not run databases in containers as these are hard to scale and the data should be persistent. I use database pools in GCP, AWS and Azure.
