


Reasons why the database is not suitable for docker and containerization
There are several reasons why the database is not suitable for docker and containerization:
1. Data is not safe
Even if you want to put Docker data on the host To store, it still cannot guarantee that data will not be lost. Docker volumes are designed around the Union FS image layer to provide persistent storage, but it still lacks guarantees.
With the current storage driver, Docker is still at risk of being unreliable. If the container crashes and the database is not shut down properly, data may be corrupted.
2. Environmental requirements for running the database
It is common to see DBMS containers and other services running on the same host. However, the hardware requirements for these services are very different.
Databases (especially relational databases) have higher IO requirements. Typically database engines use dedicated environments to avoid contention for concurrent resources. 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 this instance. In the public cloud, when you need 34G of memory, the instance you start must have 64G of memory. In practice, these resources are not fully used.
How to deal with it? You can design in layers and use fixed resources to launch multiple instances at different tiers. Scaling horizontally is always better than scaling vertically.
3. Network issues
To understand the Docker network, you must have an in-depth understanding of network virtualization. You must also be prepared to deal with the unexpected. You may need to perform bug fixes without support or additional tools.
4. State
It’s cool to package stateless services in Docker, which can orchestrate containers and solve single points of failure. But what about the database? By placing the database in the same environment, it will be stateful and make the scope for system failure greater. The next time your application instance or application crashes, it may affect the database.
5. Additional isolation is detrimental to the database
In fact, I mentioned this in the second and third reasons. But I list this as a separate reason because I want to emphasize this fact again. The more isolation levels we have, the more resource overhead we get. Easily scaling horizontally allows us to gain more benefits than a dedicated environment. However, horizontal scaling in Docker can only be used for stateless computing services, not databases.
We don’t see any isolation functionality for the database, so why should we put it in a container?
Recommended tutorial: docker tutorial
The above is the detailed content of Reasons why the database is not suitable for docker and containerization. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

Four ways to exit Docker container: Use Ctrl D in the container terminal Enter exit command in the container terminal Use docker stop <container_name> Command Use docker kill <container_name> command in the host terminal (force exit)

Methods for copying files to external hosts in Docker: Use the docker cp command: Execute docker cp [Options] <Container Path> <Host Path>. Using data volumes: Create a directory on the host, and use the -v parameter to mount the directory into the container when creating the container to achieve bidirectional file synchronization.

How to restart the Docker container: get the container ID (docker ps); stop the container (docker stop <container_id>); start the container (docker start <container_id>); verify that the restart is successful (docker ps). Other methods: Docker Compose (docker-compose restart) or Docker API (see Docker documentation).

You can query the Docker container name by following the steps: List all containers (docker ps). Filter the container list (using the grep command). Gets the container name (located in the "NAMES" column).

The process of starting MySQL in Docker consists of the following steps: Pull the MySQL image to create and start the container, set the root user password, and map the port verification connection Create the database and the user grants all permissions to the database

Docker container startup steps: Pull the container image: Run "docker pull [mirror name]". Create a container: Use "docker create [options] [mirror name] [commands and parameters]". Start the container: Execute "docker start [Container name or ID]". Check container status: Verify that the container is running with "docker ps".

The steps to update a Docker image are as follows: Pull the latest image tag New image Delete the old image for a specific tag (optional) Restart the container (if needed)

The methods to view Docker logs include: using the docker logs command, for example: docker logs CONTAINER_NAME Use the docker exec command to run /bin/sh and view the log file, for example: docker exec -it CONTAINER_NAME /bin/sh ; cat /var/log/CONTAINER_NAME.log Use the docker-compose logs command of Docker Compose, for example: docker-compose -f docker-com
