看到网上一片文章说：数据库不适合Docker及容器化？

Question

文章连接
刚开始用docker，有点疑惑？

Answer 1

Regarding the database not being suitable to be placed in docker, there are two articles by Waiguoren. One is posted by the original poster, and the other is this article, translated

Still the same point of view:

When the volume is small, you can do it casually. When the volume is large, some things will not work. Traditional databases and docker are not the right way. It is recommended not to containerize them directly. If you must containerize the database, you need the support of various systems, including middleware. systems, containerized systems.

If your database can automatically scale, disaster recovery, switching, come with its own multi-node solution, etc., docker is a better solution.

But if not, don’t use docker.

The original text also makes it very clear:

在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。

---

When the traffic is small, anything can be containerized. Database, application, hadoop, various nodes, nginx.

---

In the case of large volumes, storage-related services are not suitable for containerization. Stateless services such as the application layer and business layer are suitable for containerization. Memory-intensive services such as caching can be containerized.

To put it simply, there are three issues, disaster recovery, performance and data consistency.

As far as traditional databases like mysql are concerned, there are so many problems that I can list:

1. How to containerize mysql?

2. What should I do if the main database mysqld kneels down?

3. What should I do if the main library dockerd kneels down?

4. What should I do if the slave mysqld kneels down?

5. What should I do if the dockerd library crashes?

6. Can mysql be quickly expanded through containers when the peak is approaching? plan?

7. Data master-slave switching solution? How to ensure consistency?

8. The volume is large enough during peak periods, and sometimes the capacity of a physical machine is only enough for one mysql process.

9. So it’s also a single machine, why can’t I start mysql directly?

10. Why do we need to put a container outside? How much is the performance loss?

11. How to upgrade mysql?

12. Will the data volume lose data? (I have encountered damaged containers many times...)

But mysql is not completely incapable of containerization.
Businesses that are not sensitive to data loss (such as products found by JD.com search) can be digitized and use database sharding to increase throughput by increasing the number of instances.

As for the issues mentioned in the original article, some things have flaws, but they are well thought out. For example, the following question is very problematic (about shared data directories):

容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？

From the databases I have come into contact with so far, only databases such as cassandra (there are also tidb and cockroachdb, but I have not encountered use cases in large companies so far) are suitable for containerization.

But cassandra itself is also close to being stateless: it provides its own disaster recovery, capacity expansion, and switching solutions.

---

Let’s mention JD.com.

JD.com is an outlier, but JD.com has also mentioned similar problems and things that need attention.

计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。

Even, a lot of customization has been done to docker.

You can watch it on JD.com.

Answer 2

Not suitable, not unable.

If there are no problems with a single machine, it is still beneficial in some cases. For example, when my company's Oracle database was adjusting parameters before, the database crashed and could not be started. Fortunately, I used docker at that time, so I ran it directly and changed the data directory. Just point to the original one.

No matter how you create a cluster, it’s not easy to set it up manually using docker or tools like swarm. It’s better to build it directly on a physical machine to save trouble.

There is a company abroad that specializes in docker data storage solutions. For example, flocker, and rancher’s convoy

Answer 3

Docker is more suitable for stateless and will not change the service.

If there are a large number of clusters:
Write the docker file. Then when the code is uploaded to the code warehouse, after deploying the docker file, let the release script build the docker service in batches and put the service code into it.

Not only MySQL, but similar to redis and mc are not suitable for putting in docker. In other words, putting the database in docker is just for the sake of using docker, and there is not much benefit.

Answer 4

Yes, because the characteristics of docker determine that it is not suitable for data storage. Not only databases, but also all storage-related services are not suitable for using docker.

Answer 5

I can’t even figure out which directory the official mysql image stores data in.