3 ms·
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 th
by fh973 10y 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.
- dozzie 10y 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?
- CSDude 10y agoIts faster virtual machines, which do not have live migration for that specific use case. Just because you are doing it for years does not mean that it cannot be improved or have an alternative with its both downsides and upsides.
- quickben 10y agoYou do not want a 'downside' with any database. Especially when big money are involved, people are shown the door for far lesser issues than the ones that docker seems to have. By the way, you still haven't answered his question.
- otterley 10y agoYou're praising a feature that is an anti-pattern for database administration. If you're migrating data around and upgrading and restarting your production database without adequate business justification, you're asking for trouble.
- deleted 10y ago[deleted]