Selfhosted

60210 readers

965 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:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

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 2 weeks ago by Croquette@sh.itjust.works to c/selfhosted@lemmy.world

34 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

[–] tburkhol@slrpnk.net 3 points 2 weeks ago (1 children)

I started doing the One True Database method because I got worried that the high write count on all the little db's was abusing a raspberry pi's SD card. Moved them all to a bigger server with NVME and mirroring to a RAID.

Not all the compose files make obvious how to reconfigure the db host. Homeassistant uses s a sqlite db built into the container, rather than a separate unit, but you can force it to use a remote db through its config file. May or may not be worth hiding db user/pass in a .env And sometimes there's trouble restarting after power failure, depending on what order the database, pi, and various containers come back up.

I also feel it's worthwhile. I feel better being able to check on all the databases. Feel better not writing to the SD card so much. Feel better offloading those megabytes and cpu cycles from the little pi. It's been fun snooping through database structures. There have been a couple times where I decided to query one of the ccontain databases directly, or cross from one project to another, and it's easier (for me) to give a different user privileges to the database and query some deep bit of data than to figure out how to extract it from an API or frontend.

I'm not even running that many services, but why would I want the overhead of 6 separate mysql instances when I could just have one?

[–] ohulancutash@feddit.uk 3 points 2 weeks ago* (last edited 2 weeks ago)

sometimes there's trouble restarting after power failure, depending on what order the database, pi, and various containers come back up.

depends_on solves this problem