Kubernetes Killed the High Availability Star
Presented by:
Shaun Thomas
Shaun has spent decades working in the Postgres ecosystem, specializing in architecture and high availability. His "PostgreSQL High Availability Cookbook" serves as a treatise to the lessons he learned over that time. Perhaps you've read something from his PG Phriday blog series over the years?
Currently he serves as a Senior Software Engineer at Tembo, striving to help make Postgres the distributed cluster-aware platform he knows it can be!
Doing High Availability with Postgres is hard. So hard that even the experts get it wrong due to unforeseen edge cases. Quorum, CAP and PACELC theory, fencing, STONITH, network partitions and split brains, RPO, RTO, SLA, sync and async replication, node count and architecture, proxies, connection pools, load balancers... And then there's the tools! EFM, repmgr, Patroni, Stolon, pg_auto_failover, Barman, pgBackRest, Pgpool-II, PgBouncer, PgCat, Odyssey, is there any end to this madness?!
Well... sort of. Kubernetes takes many of the fundamental concepts of cluster management and makes it an integral part of the platform. With an appropriate Postgres-aware operator, it's possible to deploy a highly available Postgres cluster without having to understand a few books worth of cluster theory. But do we really want to run a production Postgres cluster in a container? Is any of this safe at all?
As cliche as this sounds, let us tell you about a new paradigm of what it means to be cloud-native. Where layers are self-organizing, ephemeral hardware and operating systems are preferred, and data serves as the tranquil eye of the storm while a cyclone of tooling ensures it's always available. We can show how the CloudNativePG Postgres Kubernetes operator ends the Postgres HA debate in a way that will make you a believer.
- Date:
- 2024 November 7 14:30 PST
- Duration:
- 20 min
- Room:
- Ops: 421
- Conference:
- Seattle 2024
- Language:
- Track:
- Ops
- Difficulty:
- Easy