undefined | Better HN

Skip to content

Top Best Ask Show New Jobs

0 pointsfh9739y ago0 comments

A good reason for running a database in a container is fault tolerance without setting up database replication.

Put your database in a container, let it store its data on a network storage system (like a distributed file system). The container scheduler makes sure it gets rescheduled when the node goes down.

0 comments

4 comments · 2 top-level

dozzie9y ago· 2 in thread

And what does it do any better than doing the same (keeping database on an NFS/iSCSI/AoE share) on physical or virtual machines?

fh973OP9y ago

Less downtime and automatic recovery, I'd say. When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.

dozzie9y ago

> Less downtime and automatic recovery, I'd say.

How? By magic dust sprinkled by Docker Inc?

> When the host machine goes down, the scheduler will pretty quickly start the container on a new machine. There the container will startup much quicker than a VM would.

You seem to forget that a) container's filesystem needs to be downloaded in the first place, and b) that VMs can work in a standby mode, not running the service (database) when not needed. Starting a container seems to be much more fragile solution.

There are already well-developed mechanisms for things like that, and we (sysadmins) were using them for dozens years already.

The question still stands: what do containers do better than the mechanisms we had for a long time?

And then the NFS handle goes stale, and the fun begins.

j / k navigate · click thread line to collapse