Why Databases Are Not for Docker Containers
myopsblog.wordpress.com
Why Databases Are Not for Docker Containers
1–10 of 184 posts
Re: Why Databases Are Not for Docker Containers
#2So let your database write a journal. Data corruption problem solved.
Re: Why Databases Are Not for Docker Containers
#3So let your database write a journal. Data corruption problem solved.
And when your journal is corrupted due to a bug in the Docker volume driver?
Re: Why Databases Are Not for Docker Containers
#4This article mentions offhand that the storage drivers are unreliable, even for data volumes.
Is that actually the case? Is there a serious risk that a database will be corrupted by a container crash, as the article claims? A regular crash of the computer should not be able to corrupt a database, is a container more dangerous in this regard?
Re: Why Databases Are Not for Docker Containers
#5Re: Why Databases Are Not for Docker Containers
#6Re: Why Databases Are Not for Docker Containers
#7This article mentions offhand that the storage drivers are unreliable, even for data volumes. Is that actually the case? Is there a serious risk that a database will be corrupted by a container crash, as the article claims? A regular crash of the computer should not be able to corrupt a database, is a container more dangerous in this regard?
I've been running a couple of petabytes in production with Docker and Cassandra for a couple years (around 2k nodes). I've rarely seen FS corruption, however I must qualify that this is on bare metal. They could be running into issues with the interaction with EBS? This is more of a screed than an argument backed by specific details and facts.
Re: Why Databases Are Not for Docker Containers
#8Scaling everything else (stateless non-persistent services) is nearly trivial, with or without Docker. It's scaling databases where things get interesting, but here we are back to dark ages of DBAs and manual deployment :(
Re: Why Databases Are Not for Docker Containers
#9I've been using docker in production with Elasticsearch and MySQL for 3 years in the PB scale and have never had data corruption issues occur.
Corruption occurs on data drives even without docker - you still have to plan for it. This is why you enable replication. This is why you snapshot/backup your data daily and have disaster recovery plans.
There are some major reasons why I actually think running databases in docker containers, even if you are mounting a volume for the data.
1) Development environments can be similar to production. Ensures everyone runs the same version that is running in prod.
2) You don't have to worry as much about what is installed on the host machine.
3) In a clustered setup, it's easier to ensure each node is running the same configuration, version, etc...
One of my issues with all the gripes about docker are the assertions that it causes issues. In all of my time of using docker, 99% of the time when there is an issue it has nothing to do with docker itself. Everyone loves to blame it when things go wrong though.
This article doesn't really back up any of the claims about any of its issues. It just makes blanket statements without backing them up. Don't like docker's networking? Use host networking then.
What people don't think about is the countless issues that will never come up when using containerization. I never have to worry about whether or not python 2.7 is installed on a server that I'm going to deploy a python 3 app on. I also have MUCH higher confidence that if things work on my local development env (which runs the same containers), then there is a high chance it will work in production.
YMMV
Re: Why Databases Are Not for Docker Containers
#10Earlier quoted context omitted.
And when your journal is corrupted due to a bug in the Docker volume driver?
Isn't it possible to stream a copy of the database out of the container and over the network to another database instance?
Chicken and egg. Is that other instance containerized?