What are the drawbacks of deploying the database in a Docker container?

Preface

Docker has been very popular in the past two years. Developers are eager to deploy all applications and software in Docker containers, but are you sure you want to deploy the database in the container as well?

This problem is not groundless, because you can find a lot of various operation manuals and video tutorials on the Internet. The editor has compiled some reasons why databases are not suitable for containerization for your reference. At the same time, I also hope that everyone can be more cautious when using them.

So far, it is very unreasonable to containerize the database, but I believe that all developers have tasted the advantages of containerization. I hope that with the development of technology, a more perfect solution will emerge.

7 reasons why Docker is not suitable for database deployment

1. Data security issues

Do not store data in containers, which is also one of the official Docker container usage tips. The container can be stopped or deleted at any time. When the container is rm'd, the data in the container will be lost. To avoid data loss, users can use data volume mount to store data. However, the design of container volumes is based on the Union FS image layer to provide persistent storage, and data security is not guaranteed. If the container crashes suddenly and the database is not shut down properly, data may be corrupted. In addition, sharing data volume groups in containers can cause significant damage to physical machine hardware.

Even if you store Docker data on the host, it still cannot guarantee that data will not be lost. Docker volumes are designed around providing persistent storage for Union FS image layers, but it still lacks guarantees.

With current storage drivers, Docker still runs the risk of being unreliable. If the container crashes and the database is not closed properly, data corruption may occur.

2. Performance issues

As we all know, MySQL is a relational database with high IO requirements. When a physical machine runs multiple instances, IO will accumulate, causing IO bottlenecks and greatly reducing MySQL's read and write performance.

At a special session on the top ten difficulties in using Docker, an architect from a state-owned bank once said: "The performance bottleneck of the database usually occurs on IO. If we follow the Docker idea, then multiple Docker IO requests will eventually appear on the storage. Now most databases on the Internet are based on a share nothing architecture, which may be a factor in not considering migrating to Docker."

Some students may also have corresponding solutions to performance issues:

(1) Separation of database programs and data

If you use Docker to run MySQL, the database program and data need to be separated, with the data stored in shared storage and the program placed in the container. If there is an exception in the container or the MySQL service is abnormal, a new container will be started automatically. In addition, it is recommended not to store data in the host machine. The host machine and the container share a volume group, which has a greater impact on the damage to the host machine.

(2) Running lightweight or distributed databases

When deploying lightweight or distributed databases in Docker, Docker itself recommends that you terminate the service and automatically start a new container instead of restarting the container service.

(3) Reasonable layout of applications

For applications or services with high IO requirements, it is more appropriate to deploy the database on a physical machine or KVM. Currently, TX Cloud's TDSQL and Alibaba's Oceanbase are directly deployed on physical machines rather than Docker.

3. Network issues

To understand Docker networking, you must have a solid understanding of network virtualization. You must also be prepared to deal with unexpected situations. You may need to make bug fixes without support or additional tools.

We know that databases require dedicated and sustained throughput to achieve higher loads. We also know that containers are an isolation layer behind the hypervisor and the host virtual machine. However, the network is critical for database replication, which requires a 24/7 stable connection between the master and slave databases. Unresolved Docker networking issues remain unresolved in version 1.9.

Putting these issues together, containerization makes database containers difficult to manage. I know you are a top engineer and can solve any problem. But how much time do you spend troubleshooting Docker networking issues? Wouldn't it be better to put the database in a dedicated environment? Free up time to focus on truly important business goals.

4. Status

It's cool to package stateless services in Docker to orchestrate containers and solve single point of failure issues. But what about the database? Putting the database in the same environment will make it stateful and make the scope for system failures greater. The next time your application instance or application crashes, it may affect the database.

Knowledge point: In Docker, horizontal scaling can only be used for stateless computing services, not databases.

An important feature of Docker's rapid expansion is its statelessness. Anything with data state is not suitable to be placed directly in Docker. If a database is installed in Docker, storage services need to be provided separately.

Currently, TX Cloud's TDSQL (financial distributed database) and Alibaba Cloud's Oceanbase (distributed database system) are both running directly on physical machines, rather than on Docker, which is easier to manage.

5. Resource Isolation

In terms of resource isolation, Docker is indeed not as good as the virtual machine KVM. Docker uses Cgroup to implement resource limitations, which can only limit the maximum value of resource consumption, but cannot isolate other programs from occupying its own resources. If other applications excessively occupy physical machine resources, it will affect the read and write efficiency of MySQL in the container.

The more isolation levels you require, the more resource overhead you incur. Compared with dedicated environments, easy horizontal scaling is a major advantage of Docker. However, in Docker, horizontal scaling can only be used for stateless computing services, not databases.

We don’t see any isolation features for the database, so why should we put it in a container?

6. The inapplicability of cloud platforms

Most people start their projects through a public cloud. The cloud simplifies the complexity of operating and replacing virtual machines, so there is no need to unload human time at night or on weekends to test new hardware environments. Why should we worry about the environment in which an instance runs when we can just spin it up quickly?

That's why we pay a lot to our cloud providers. When we place a database container for the instance, the convenience mentioned above no longer exists. Because the data does not match, the new instance will not be compatible with the existing instance. If you want to limit the instance to use a single-machine service, you should use a non-containerized environment for the DB. We only need to retain the ability to elastically expand the computing service layer.

7. Environmental requirements for running the database

It is common to see DBMS containers running on the same host as other services. However, the hardware requirements of these services are very different.

Databases (especially relational databases) have high IO requirements. General database engines use dedicated environments to avoid concurrent resource competition. If you put your database in a container, you will waste your project's resources. Because you need to configure a lot of additional resources for the instance. In the public cloud, when you need 34G memory, the instance you launch must have 64G memory. In practice, these resources are not fully utilized.

How to solve it? You can design in layers and use fixed resources to launch multiple instances of different layers. Scaling horizontally is always better than scaling vertically.

Summarize

In response to the above question, does it mean that the database must not be deployed in a container?

The answer is: No

We can digitize businesses that are not sensitive to data loss (search, tracking points), and use database sharding to increase the number of instances, thereby increasing throughput.

Docker is suitable for running lightweight or distributed databases. When the Docker service crashes, a new container will be automatically started instead of restarting the container service.

The database uses middleware and containerized systems to automatically scale, recover from disasters, switch, and come with multiple nodes. It can also be containerized.

The above is the detailed content of the defects of deploying the database in the Docker container. For more information about why Docker is not suitable for deploying databases, please pay attention to other related articles on 123WORDPRESS.COM!