Build a MySQL MHA Cluster with Docker: Complete Step‑by‑Step Guide
This article walks through constructing a MySQL MHA high‑availability cluster using Docker, comparing traditional installation with two Docker‑based versions, detailing container setup, configuration steps, Dockerfile composition, pros and cons, and automation scripts for rapid, repeatable deployments.
Why Use Docker for MySQL MHA?
Traditional MySQL MHA installations require manual setup on at least three servers, often taking 2–3 hours and being vulnerable to network issues. Docker’s image layering, portability, and automation capabilities enable faster, repeatable deployments and smoother version upgrades.
Version 1: Basic MySQL Container Cluster
This version uses Docker only to run MySQL containers that cooperate with the host to form an MHA cluster. The steps are:
Pull MySQL image – e.g., docker pull percona/percona-server:latest from a private or public registry.
Define directories and my.cnf – create host directories for configuration and data, then mount them with -v.
mkdir -p /home/docker/mount/mysql/mhadb
mkdir -p /home/docker/conf/mysql/master.cnfRun containers – start each MySQL instance with --net=host and mount /etc/localtime to keep time in sync.
docker run -d --name mysql1 \
--net=host \
-v /home/docker/mount/mysql/mhadb:/var/lib/mysql \
-v /home/docker/conf/mysql/master.cnf:/etc/mysql/my.cnf \
-v /etc/localtime:/etc/localtime \
percona/percona-serverRepeat on other nodes – create the same directories, copy my.cnf (adjusting master‑slave parameters), and run the container.
Configure master‑slave replication – select one node as master and set up replication on the other two (standard MySQL commands, omitted for brevity).
Install MHA tools – performed on the host OS; the article notes this step is straightforward but not detailed.
Pros of Version 1
Improves deployment efficiency by 5‑10 % and scales without extra time cost.
Leverages image layering for rapid rolling upgrades and rollbacks.
Allows quick replication of multiple DB instances when host resources are sufficient.
Cons of Version 1
Limited benefit when only a single instance is deployed.
Still depends on host OS for MHA packages.
Container adds extra disk usage compared with bare‑metal installs.
Version 2: Full OS‑Level Docker Image
This version builds a complete OS image that already contains MySQL, MHA, and required dependencies, separating manager and node roles into distinct images.
Base image – FROM centos:6.7.
Install dependencies and MySQL – add required packages and install Percona/MySQL inside the image.
Add MHA binaries – copy the downloaded MHA source and compile it.
Copy configuration files – either embed static config files or pass parameters at docker run time.
Run shell scripts at container start – use COPY and ENTRYPOINT to execute setup scripts.
Build manager image – run the manager container from the built image.
Build node images – create lighter images for MHA nodes, removing manager‑specific parts.
Configure master‑slave – use
docker exec -it <container_id> mysql -uroot -p… -e 'show master status'and similar commands to set up replication.
Set up node trust – perform SSH trust configuration inside each container.
Start MHA monitoring – launch the MHA monitor process within the manager container.
Pros of Version 2
Most of the MHA install and configuration is automated, enabling minute‑level cluster provisioning.
Containerized MHA runs on any host OS, providing platform independence.
OS‑level optimizations can be baked into the image.
Monitoring can be packaged into the same Dockerfile.
Cons of Version 2
Larger image size due to full OS layer.
Containers must run with --net=host and --privileged=true, reducing security and risking port conflicts.
Requires a full SSH server inside containers for inter‑node trust.
Complex build process: custom Dockerfiles and scripts are needed, though they are reusable after the initial creation.
Parsing mysql-entrypoint.sh
The entrypoint script performs simple tasks such as removing the test user, substituting configuration variables, and creating required users. A snippet illustrating variable substitution:
# Example snippet from mysql-entrypoint.sh
sed -i "s/{{DB_USER}}/$DB_USER/g" /etc/mysql/my.cnf
sed -i "s/{{DB_PASS}}/$DB_PASS/g" /etc/mysql/my.cnfFull script details are omitted for brevity.
Conclusion
Version 1 demonstrates how Docker can accelerate MySQL MHA deployment while still relying heavily on host‑level operations. Version 2 shows a more advanced, fully containerized approach that achieves near‑instant provisioning and platform independence at the cost of larger images and reduced security isolation. Both versions illustrate Docker’s potential to streamline database high‑availability setups.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
dbaplus Community
Enterprise-level professional community for Database, BigData, and AIOps. Daily original articles, weekly online tech talks, monthly offline salons, and quarterly XCOPS&DAMS conferences—delivered by industry experts.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
