Why Deploying MySQL in Docker Can Be Problematic: Scaling & Memory Pitfalls

Docker allows quick deployment by pulling images from remote repositories, but using Docker for MySQL is generally not recommended.

1. Database scaling difficulties

MySQL stores data on the host; when MySQL runs inside a container, the data must be mounted to the host because container shutdown would otherwise lose the data. Each MySQL container mounts its own host directory, making it impossible for multiple containers to share a single data file.

When scaling, the following problems appear:

Solution options include:

Binlog synchronization

Full dump followed by incremental binlog sync

Binlog sync is unsuitable for large data volumes, and full dump requires downtime, making both approaches problematic for scaling.

2. Memory resource issues

Docker isolates applications, not resources; memory is shared among containers. If one container (e.g., an MQ service) consumes most of the memory, MySQL and other services may lack sufficient memory, leading to service failures.

Summary

(1) From a scaling perspective, host data files are exclusive to each container, so multiple MySQL containers mount separate files; data‑sharing solutions exist but have drawbacks.

(2) Memory sharing among containers can cause contention, jeopardizing service stability.

(3) This does not mean Dockerized MySQL is impossible; in scenarios requiring automatic scaling, disaster recovery, multi‑node setups, or where middleware can manage data synchronization, containerized MySQL may still be appropriate.