Container definition: Containers are designed to solve the problem of "how to ensure software runs correctly when switching runtime environments."
Currently, containers and Docker remain the hottest topics in the tech field. Stateless service containerization has become an unstoppable trend, sparking a heated debate: Does MySQL need to be containerized?
After carefully analyzing various opinions, it's clear that proponents only argue for MySQL containerization based on the advantages of containers, with almost no business scenarios to validate their views. On the other hand, opponents cite multiple factors such as performance and data security to argue against MySQL containerization, providing examples of unsuitable business scenarios. Below, we will discuss N reasons why Docker is not suitable for running MySQL!
Data Security Issues
Do not store data in containers—this is one of Docker's official container usage tips. Containers can be stopped or deleted at any time. When a container is removed, the data inside it will be lost. To avoid data loss, users can use data volume mounting for storage. However, container volumes are designed around Union FS image layers to provide persistent storage, but data security lacks guarantees. If a container suddenly crashes and the database is not properly shut down, data may be corrupted. Additionally, sharing data volume groups in containers can cause significant damage to the physical machine hardware.
Performance Issues
As everyone knows, MySQL is a relational database with high I/O demands. When multiple instances run on a single physical machine, I/O accumulates, leading to I/O bottlenecks and significantly reducing MySQL's read/write performance.
At a special session on the top ten difficulties of Docker applications, an architect from a state-owned bank also pointed out: "Database performance bottlenecks usually occur at the I/O level. Following Docker's approach, multiple dockers will ultimately converge I/O requests on storage. Most internet databases today use a shared-nothing architecture, which might be one reason they are not considered for migration to Docker."
In fact, there are some corresponding strategies to address this issue, such as:
- Separation of database program and data
If using Docker to run MySQL, the database program and data must be separated: store data in shared storage and place the program in a container. If the container or MySQL service encounters an exception, a new container can automatically start. Additionally, it is recommended not to store data on the host machine, as the host and container share volume groups, which can have a significant impact on the host if damaged.
- Run lightweight or distributed databases
Deploy lightweight or distributed databases in Docker. Docker itself recommends that when a service goes down, a new container starts automatically rather than restarting the container service.
- Rational application layout
For applications or services with high I/O requirements, it is more appropriate to deploy databases on physical machines or KVM. Currently, Tencent Cloud's TDSQL and Alibaba's OceanBase are both deployed directly on physical machines, not Docker.
Statefulness Issues
In Docker, horizontal scaling can only be applied to stateless compute services, not databases.
One of Docker's key features for rapid scaling is statelessness; stateful data components are not suitable for direct deployment in Docker. If a database is installed in Docker, storage services need to be provided separately.
Currently, Tencent Cloud's TDSQL (financial distributed database) and Alibaba's OceanBase (distributed database system) both run directly on physical machines, rather than the more manageable Docker.
Resource Isolation Issues
In terms of resource isolation, Docker is indeed inferior to virtual machines like KVM. Docker uses cgroups to enforce resource limits, which can only cap the maximum resource consumption but cannot isolate resources from other programs. If other applications excessively consume physical machine resources, it will affect the read/write efficiency of MySQL running in containers.
The more isolation levels required, the greater the resource overhead. Compared to dedicated environments, easy horizontal scaling is a major advantage of Docker. However, in Docker, horizontal scaling is only suitable for stateless compute services, not for databases.
Can't MySQL Run in Containers?
MySQL is not entirely unsuitable for containerization.
Businesses that are not sensitive to data loss (e.g., product search for users) can be containerized, using database sharding to increase the number of instances and thereby increase throughput.
Docker is suitable for running lightweight or distributed databases. When a Docker service fails, a new container starts automatically rather than restarting the container service.
Databases that use middleware and containerization systems capable of automatic scaling, disaster recovery, failover, and multiple nodes can also be containerized.
Typical examples: Tongcheng Travel, JD.com, and Alibaba's database containerization are good cases to explore.
Original author: Lao Wang Talks Operations
Original link: https://www.toutiao.com/i6675622107390411276?wid=1640184427889