Selfhosted

59892 readers

686 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam.
Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.
Don't duplicate the full text of your blog or git here. Just post the link for folks to click.
Submission headline should match the article title.
No trolling.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

How do you manage you DB in a docker environment? (sh.itjust.works)

submitted 18 hours ago by Croquette@sh.itjust.works to c/selfhosted@lemmy.world

25 comments fedilink hide all child comments

Hello,

As the title suggests, how do you manage your DBs for docker services.

Do you spin a new DB for every new docker cluster or do you have a centralized DB that is accessible to the docker clusters.

What are the pros and cons of both method?

For the moment, I spin a new DB for every services as I feel it is easier to backup the service in case of a problem.

you are viewing a single comment's thread
view the rest of the comments

[–] placebo@lemmy.zip 2 points 12 hours ago (1 children)

Given that database management systems already provide clear separation between services in the form of databases, users, and permissions, I see no need to spin up new database instances for each individual service. You say it's easier to back up tightly coupled services and databases, but why? I find it easier to back up a single database server than multiple servers.

The real concern with shared databases is performance: some services, under certain conditions, can generate load that degrades database performance for everyone. But that's usually a problem for large enterprises, not self-hosters.

[–] Croquette@sh.itjust.works 2 points 11 hours ago

You say it's easier to back up tightly coupled services and databases, but why?

Because it is set and forget in my docker compose. I can backup the container and bring it down without affecting other services.

But that is my inexperience talking and this is is why I wanted to see what other people were doing, and having perspective like yours to learn.