6 ms·

Could you elaborate on this? I was considering using containers for a PG installation but am reevaluating.

• X86BSD 11y ago
  Well on FreeBSD you can toss it into a jail with iocage and get snapshots, clones, easy HA with vrrp or CARP. Not replication per se. But for a lot of people that works just fine and is incredibly easy to automate and accomplish.
  • geofft 11y ago
    How does this get you HA (easy or otherwise) without application-level configuration? Does this involve something like lockstep execution between the two servers? I'd expect that if you run two Postgres servers, unaware of each other, at the same IP address you will rapidly get data corruption, but maybe I'm missing a step since you say this works fine for a lot of people.
    • creshal 11y ago
      I'd guesstimate it involves shipping snapshots to a cold standby, since snapshotting/cloning is mentioned.
• takeda 11y ago
  What are you trying to solve by doing this? Are you planning to run other applications on the same host. Generally it's not a good idea to share host running database with other applications due to different workloads. If you would want to put multiple databases on one host, probably more efficient would be still to put all data in single instance. I could see this if it's a very small database, then this could work, but then wouldn't you be better off with using SQLite? In additions when you add containers to the mix you turn a single problem into many, some examples: - assuming you have multiple hosts, you need to figure out where you'll store persistent data (and you generally want a solution with high IOPS) - how you handle logging (where you store them?) - how the applications figure out where your database is (service discovery) - how you solve replication (and figure out which database is the master) - how you handle failover
  • dcgoss 11y ago
    I was considering deploying Postgres (as a container) into a Kubernetes cluster. Kubernetes takes care of service discovery, networking, persistent disk mounting, moving the container if a server goes down, etc. Wouldn't you have similar problems with Postgres without the container?
    • takeda 11y ago
      I don't know kubernetes, but looks like it solves many of those issues already. I still believe the HA might be a challenge. Typically to make the database highly available you might set up a second one (or perhaps more) that replicates from the master. This can become problematic if the postgres containers will be moved around. As I said, I don't know kubernetes, if you for example can have containers that have state (e.g. you destroy and recreate it somewhere else, and they are exactly same) and also keep the same IP then this is not an issue, but if when you move it around and each instance is technically a new postgres, then such setup might become problematic. Regarding your question, the traditional way of running it is that you set up a host and run postgres on it. It doesn't move around so you need those solutions. Granted that for example if you implement service discovery for example if something happens to a host, you can set up another and quickly point everything to it.