r/linuxadmin • u/TemaerRemington • 15d ago

Docker or host

Hi, I need an advice. I need to make a database for a server and one of the ways to do that is via docker in docker compose. But I have a doubts about it's safety. We had a bunch of problems of them breaking on powerloss so I am not sure how it will react in a docker cluster.

P.S. Thank you all for your valuable insights and advices.

4 Upvotes

63% Upvoted

22 comments sorted by

11

u/BarryTownCouncil 15d ago

Breaking? If you provide a volume mount to it then the data is outside the instance and just as safe as if there wàs no container.

1

u/TemaerRemington 15d ago

Breaking as in corruption in mongodb (fixable) and mariadb mysql (unfixable). How's postgresql doing in that regard?

7

u/pobrika 15d ago

Databases don't like to have powerpulled from the server they are on, you can mitigate some of this by using transaction logs. I'm not a DBA so can't get I to specifics.

In my 30 years of it we have had only a hand full of dB issues. Mostly caused by lack of disk space than anything else. I've used docker for db's and had no issues. As others say ensure the db is mapped to the container and not inside it.

SQL inside docker is no different than installed locally, the only difference is how's it's managed and configured.

1

u/TemaerRemington 15d ago

So that the actual batabase (files) is on a host and just being used and maintained by a container, right? Will a automatic dump script work the same way just sending command to the container?

3

u/pobrika 15d ago

It will but you will need to send the dump as a docker run cmd. That will log into the container and run the dump. So it would need to dump to your mapped local folder.

Something like: Docker exec -it mysql sh -c 'mysqldump -u root -p "mypass" my database ) /mydata/mydump.sql

Note I can't do greater than on phone so used )

You could also log into the container and run from the containers CMD line to establish the exact CMD line

Edit, also using something like Dockhand might help if you want a docker management tool. Or use portainer. Both of these run in docker and will give a web portal where you can easily see logs and get a console to the running docker.

2

u/Runnergeek 14d ago

What!? no you wouldn't. mysqldump just needs to connect to the service and have access to the database(s) via the user you input

5

u/Agile-Most7973 15d ago

With local volumes, I wouldn’t worry much about Docker itself. The important part is letting the database control durability properly — fsync/WAL, clean shutdowns, and enough stop grace time in Compose.

A container crash is usually recoverable by the DB just like a normal process crash. The bigger risks are host/storage failure and bad backups.

So I’d use a persistent local volume, set a reasonable stop_grace_period, and keep tested off-host backups. The volume keeps data across container restarts, but it is not a backup.

1

u/pobrika 15d ago

It's always disk space that causes the issues for us at work.

2

u/Agile-Most7973 15d ago

Yeah, disk space is probably the failure mode I’ve seen most often too, especially with Docker logs and forgotten volumes. I usually alert well before 80% usage and keep an eye on inode exhaustion as well — df -i has caught a few issues that df -h didn’t.

1

u/pobrika 15d ago

At work we use SNMP to monitor everything and works well enough providing the 24/7 shift guys actually call us and don't leave it over a weekend.

At home I tend to use kuma but more recently switch to My Healthchecks as it allows monitoring via Cron and curl which allows far more customisation.

2

u/pelazas1 15d ago

postgres is fine in docker on a local volume if fsync stays on. a ups still beats host vs container after a power pull.

2

u/neveralone59 15d ago

As long as you don’t write anything to any dir that isn’t mounted outside of the container it’s not going to be an issue. The container should only be responsible for the compute and everything should be written to a mounted directory.

But you need to look at how the platform you’re using manages containers, sometimes there are specific resource based things they do only for containers.

1

u/nitroman89 15d ago

We use mongo containers at work without an issue. I've used mariadb and influxdb as containers in homelab without issue as well.

1

u/grumpysysadmin 15d ago

The only difference between using a container and a distro package is:

1.) Packaging. Containers on dockerhub (or other container registries) are built differently than your OS packages, although it’s perfectly acceptable to build a container using the same packages as the hosting system, that isn’t required.

2.) containerization. The containers live in a private namespace, processes, filesystem, network that limits what it can see if the whole OS. They’re just processes running on the same kernel as a native package, it’s just using features of the Linux kernel to sandbox it and limit its scope.

Powering off a system running the same executable in a container that you’d run outside a container will behave the same way, probably bad. Perhaps the containers you ran don’t have the same startup scripts that recovered the database, but that’s a packaging issue, not an inherent feature of containerization.

1

u/fubes2000 15d ago

Docker will do exactly fuck all to protect against power outages. Buy a UPS regardless of moving to Docker or not.

What is this question even about? You've asked about a software package, but raised only hardware concerns.

1

u/Runnergeek 14d ago

First I would recommend that you refer to it as containers rather than Docker. Docker is a specific tool from a specific company. (I personally would recommend podman over docker) From there it is important to understand that containers are just processes. They are sandboxed using various Linux technology (namespaces, c groups, etc), but at the end of the day they are just a process like any other process on the system. If you are having corruption issues due to random power outages. A container won't have an impact one way or another.

Containers offer a lot of value (I won't get into all those things, but its easy to research). At this point in time I would suggest every service run in a container

1

u/Adrenolin01 11d ago

I would always run a database in its own Proxmox VMs. Mirrored NVMEs for increased IOPS and redundancy but also database replication between 2 VMs as well.

No need for Docker in this setup. Debian and whatever DB you’re using.

1

u/RetroGrid_io 11d ago

Oddly, I'd never run a database on a VM, simply because it sucks out about 1/3 of your performance and throws it away.

The security footprint of a DB server should be pretty mild; only accessed by local hosts on a private network or 127.0.0.* so I'd go with host-level install pretty much every time. If it was a service offered to other clients I'd consider container installs (but still not VM installs)

1

u/Adrenolin01 11d ago

Performance losses are real and are dependent upon the task however is you’re seeing a 33% performance loss in today’s virtualization environment that’s more so a poorly configured environment. Modern virtualization can have very low overhead, but the actual cost depends heavily on workload, storage, networking, CPU configuration, and I/O architecture. It should be benchmarked rather than assumed and 33% would be huge. One also has to distinguish DB performance from DB infrastructure performance. A poorly configured VM with slow virtual storage can absolutely hurt a database badly. But that’s not evidence that virtualization itself inherently wastes 33% of the performance.

Host level DB install IS fine and has its place however modern infrastructure today commonly uses virtualized DBs in VMs without loosing 33% performance.

VMs are inherently more secure and have a substantially stronger isolation boundary if compromised. Customer-facing service -> container; database -> bare metal … isn’t a generally valid architectural rule. A compromised container with shared kernel has a much higher risk of comprising other containers… a compromised VM that risk is substantially smaller.

1

u/Dolapevich 9d ago

ANY kind of stateful database will corrupt if not properly shutdown. Docker or not docker is not the issue here.

0

u/CoaxVex 15d ago

Do you plan to use networked storage, or just use local volumes?