Why Docker May Not Be Ideal for Running MySQL: N Reasons and Practical Guidance

When asked whether to set up environments for learning or production, the author recommends using Docker for personal learning but cautions that production deployments must consider whether the service is suitable for containerization.

Data Security Issues

Storing data inside containers is risky because containers can be stopped or removed, causing data loss; using volumes mitigates this but does not guarantee safety, and abrupt container crashes may corrupt the database.

Performance Issues

MySQL is I/O‑intensive; running multiple instances in containers on a single host can create I/O bottlenecks that degrade read/write performance, as highlighted by an architect from a state‑owned bank.

Suggested solutions include separating the database program from its data and placing data on shared storage, using lightweight or distributed databases, and deploying databases on physical machines or KVM when high I/O performance is required.

State Issues

Docker’s horizontal scaling is designed for stateless services; databases require persistent state, so additional storage services are needed, and major cloud providers run their distributed databases on physical machines rather than Docker.

Resource Isolation

Docker relies on cgroups for resource limits, which cannot fully isolate resources like a virtual machine; heavy resource consumption by other applications can affect MySQL’s performance inside a container.

Can MySQL Run in Containers?

MySQL can be containerized in scenarios such as workloads tolerant of data loss, lightweight or distributed database deployments, and when middleware enables automatic scaling, disaster recovery, and multi‑node operation; examples include travel and e‑commerce platforms.

The author invites readers to discuss these points, share opinions, and reach out for further communication.