151–160 of 184 posts
As others have mentioned, Docker doesn't really do any magic which might harm the smooth running of a database, but just leverages process isolation built into the Linux kernel and provides a convenient way to package and distribute bundles of software. In the case of a database, the former can be handy any time you want to run a database on a host where you want to run other software too. As for the latter, being ab…
Earlier quoted context omitted.
> I wonder if google has database nodes in containers? I've been wondering this for a while. I'm sure some of the big players do it, but I'd really like to see a case study from one of them.
Google runs MySQL on Borg internally.
"You may corrupt the data in case of container crash where database didn’t shutdown correctly. And lose the most important part of your service." This is the point in the article where you know you don't need to read the rest. If your data integrity hinges on your database being able to shut down correctly you will be disappointed. The author believes in fairytales.
It's kind of interesting how knowledge works with some subjects. If you don't know anything, you will agree with the statement. When you know a bit more, you will disagree, but when you learn more than that you will once agree. It's true that real databases need to guarantee data won't disappear even at power loss, so you would think that container crash should be comparable with power loss, if not more trivial. The…
This article is terrible. It's a lot of wishy-washy explanations devoid of technical detail - because their isn't a technical explanation or justification for this list. I've run extensive benchmarks of Hadoop/HBase in Docker containers, and there is no performance difference. There is no stability difference (oh a node might crash? Welcome to thing which happens every day across a 300 machine cluster). Any clustered…
While I agree with you I'd like to caution some users about rushing into dockerising everything in their production environment. If your environment setup is not repeatable and you don't have your configuration management under control then you have other problems and using docker is just going to add another layer of abstraction on your mess that your DBA doesn't know how to deal with when things hit the fan. In par…
"You may corrupt the data in case of container crash where database didn’t shutdown correctly. And lose the most important part of your service." This is the point in the article where you know you don't need to read the rest. If your data integrity hinges on your database being able to shut down correctly you will be disappointed. The author believes in fairytales.
It's kind of interesting how knowledge works with some subjects. If you don't know anything, you will agree with the statement. When you know a bit more, you will disagree, but when you learn more than that you will once agree. It's true that real databases need to guarantee data won't disappear even at power loss, so you would think that container crash should be comparable with power loss, if not more trivial. The…
Yes, persisting data in a consistent and durable manner is hard. It is damn hard. It was hard 20 years ago when systems required to store obscene amounts of data started to become more common and it is hard today.
(This reminds me of a discussion a couple of years ago on how to kill processes. There are two schools of thought. One is that you should go through the SIGTERM - wait - SIGKILL dance, because that's "being nice". The other is that you always send SIGKILL immediately and instead engineer systems that can deal with it)
This article is terrible. It's a lot of wishy-washy explanations devoid of technical detail - because their isn't a technical explanation or justification for this list. I've run extensive benchmarks of Hadoop/HBase in Docker containers, and there is no performance difference. There is no stability difference (oh a node might crash? Welcome to thing which happens every day across a 300 machine cluster). Any clustered…
Yeah volumes skip unionfs. This article is full of FUD. The author demonstrates they don't really have enough experience to make these claims. I wonder if google has database nodes in containers? Kubernetes is adding the features for containers now. I think it is stable now.
I still can't really figure out what a container is. Every time I think of a use case for one, I read something like this which says that's a terrible idea. The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the…
> The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the other "servers" I have running. SaltStack, Ansible, Chef are all configuration management tools that serve this purpose. They let you configure a standalon…
2) They let you have burstable instances, but controlling all the services sharing those resources, rather than being subjected to unknown neighbours.
3) Related to the previous points, they let you take advantage of free resources by distributing batch operations over VMs not under peak capacity.
Earlier quoted context omitted.
I've run Oracle in a container, ugh what a pig, though it can be done. It's great for development, since you can checkpoint state, pass it around and have 99 containers of bugs on the ground. At the end of the day, the data and database is run on some production instance that runs on a fully bare hypervisor at TopGuy (TM) cloud provider. This is enough so that everyone feels more or less good about their situation.
> I've run Oracle in a container Danger, danger https://www.theregister.co.uk/2016/02/24/oracle_vmware_licen...