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
[–] 9 points 4 months ago (4 children)

Individually. If the app requires a DB, I put it in the compose file. This simplifies both backups and migrations. My tooling for backups has a pre and post script I can customize on a per app basis so I just have the pre do whatever *dump for that DB and the post clean it up (backup takes a tar of the folder).

  • source
  • hideshow 4 child comments
  • [–] 2 points 4 months ago (3 children)

    My backup tooling just shuts down the container and associated db, then rysncs it all somwhere safe and restarts the container. Am I missing somethoing critical by not doing a db dump in the middle of that?

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 4 months ago (2 children)

    Most of the time that's perfectly fine, but if the database were in the middle of an operation you risk corruption.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 4 months ago (1 child)

    The last thing I want is database corruption. That is why I "docker compose down" before I make a backup then "docker compose up" when the backup is complete. Is that not good enough? Do I have to do something else?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 4 months ago*

    Yes that's good enough! Sorry I missed your statement about shutting down first. To clarify I leave mine running since a dump can recover if it gets corrupt.

    Basically my backup contains the database and the SQL dump (or equivalent) - that way I don't need to shutdown the service.

  • source
  • parent