crunchy-proxy VS patroni

This is why I always recommend using a postgres proxy so you can point it to different database servers as you stand them up. AWS does this by default but GCP doesn’t yet, so you have to have your own Postgres proxy (e.g https://github.com/CrunchyData/crunchy-proxy) or move to an HA Postgres setup like Patroni that has streaming replication (https://github.com/zalando/patroni).

Now according to Patroni Docs we will config Patroni using etc/patroni/config.yml/ file. mine looks like this:

Do you need HA, or do you want to minimize downtime? At work we have something like an "error budget", were we accept downtime but try to minimize it. As such we have two nodes with one floating ip and a shared disk. The switch over takes as long as stopping the database on the first node, starting up the database on the second one and switching over the ip. Stuff like kernel updates takes us <1 minute of scheduled downtime, which is good enough for us.

If you want more, I think Patroni (by Zalando) is the current best option for you. Patroni handles automatic leader election if the master goes down, and it is open source. Read here more:

https://github.com/patroni/patroni

I was never clear about the difference between Spilo and Patroni. I'm using this, is it Spilo or Patroni? https://github.com/zalando/patroni/blob/master/kubernetes/pa...

> I think etcd is basically a k8s only project now

I hate etcd with the best of them, but etcd is used in a lot more places than just kubernetes:

https://github.com/apache/apisix/blob/master/docs/en/latest/...

https://github.com/traefik/traefik#:~:text=Etcd,

https://github.com/zalando/patroni#patroni-a-template-for-po...

https://github.com/purpleidea/mgmt/tree/0.0.26/etcd (this one shows up on HN quite a bit)

https://github.com/sorintlab/stolon#features

It's actually one of the major reasons I wouldn't touch those projects

Citus doesn't provide fault tolerance. Each shard is a monolithic PostgreSQL. To reduce downtime on failures, you can protect each shard with a standby database. As this is a complex configuration, Patroni can help. For this lab I'll use the Citus+Patroni docker-compose-citus.yml from https://github.com/zalando/patroni.git:

We have been using stolon + consul for years without issue in our swarm environments. It may also be possible with patroni.

one of the solutions which made it pretty simple for us to run postgresql in a ha environment (mostly in k8s, but works standalone as well) is zalandos patroni: https://github.com/zalando/patroni it's really solid and worked for us for a few years already.

or for k8s their operator: https://github.com/zalando/postgres-operator (docker image: https://github.com/zalando/spilo) we've also tried other operators which were easier to get started, but they failed miserably (crunchyrolls operator is basically based on the zalando one)

Hello. I am currently using this docker-compose model from Zalando repository. It does not include PgBouncer in its architecture by default. I've been trying to find a containerized implementation involving Patroni, HAProxy, Etcd and PgBouncer. I didn't find anything solid so far.

General purpose: Patroni - Set up your own etcd + HAProxy + Patroni + Postgres components and it'll generally manage itself after that.