Patroni regelt automatische failover voor PostgreSQL via een distributed configuration store (etcd, Consul of ZooKeeper). Anders dan handmatig pg_basebackup en streaming replication beheert Patroni leader election, failover en synced replicas. Productie-vereiste voor 24/7-PostgreSQL.
Architectuur: drie of vijf nodes
Drie PostgreSQL-nodes (één primary, twee replicas) plus een drie- of vijf-node etcd-cluster. etcd kan op dezelfde nodes draaien, maar voor productie raden we aparte etcd-nodes aan zodat database-load geen distributed-consensus verstoort.
Synchronous versus asynchronous replication
Patroni ondersteunt synchronous_mode waarbij commit wacht op acknowledge van een replica. Geen data-loss, maar latency-impact op writes. Voor financiele data en logging-met-bewijslast: synchronous. Voor hoge OLTP-throughput: asynchroon plus extra back-up-frequentie.
HAProxy of pgbouncer voor connection routing
Applicaties moeten naar de leader connecten, ook na failover. HAProxy of pgbouncer met Patroni REST API queries voor health-status routeert connections automatisch. We zetten alle drie de PostgreSQL-nodes achter een load balancer met dynamic backend.
Backup integratie met pgBackRest
Patroni regelt geen backups. pgBackRest voor PITR-backup, incremental backup en stanza-management. Backups landen op object storage (S3, MinIO, Azure Blob) buiten het cluster. Restore-test elk kwartaal, anders is de backup-strategie theorie.
Failover-test en oncall
We oefenen failover bij elke major upgrade. patronictl switchover laat handmatig de leader verschuiven. Bij een echte failover (network partition, leader crash) gebeurt dat automatisch binnen 30 tot 60 seconden. Monitoring via Prometheus en Patroni's eigen REST API.
Verwant: Freelance PostgreSQL DBA inhuren, PostgreSQL performance tuning.