Managed PostgreSQL, med automatisk failover
Kør et højtilgængeligt Postgres-cluster på Suble: N medlems-VM'er, hver med en fuld lokal kopi af dataene, Patroni til automatisk leder-valg og failover, og et enkelt stabilt :5432-endpoint der altid peger på den nuværende primary. Opret det i dashboardet, forbind med sslmode=require, og hold op med at passe din database.
The Suble team
Engineering ·
At køre højtilgængelig PostgreSQL selv er en overgangsrite, og ikke en sjov en. Du sætter streaming-replikering op, griber så fat i Patroni eller repmgr til leder-valget, rejser så etcd eller Consul til at bakke det op, sætter så HAProxy foran så klienter rammer den rigtige node — og så må du holde det hele i live kl. 3 om natten. Det er mange bevægelige dele for et resultat: når primaryen dør, overtager noget andet hurtigt, og din app opdager det næsten ikke.
I dag er det resultat et flueben. Suble tilbyder nu managed, højtilgængelig PostgreSQL som et database-cluster: vælg Postgres, vælg et antal noder, og du får replikering, automatisk failover og et stabilt endpoint — alt sammen managed for dig, på vores egen danske infrastruktur.
Sådan virker det
Et database-cluster er N medlems-VM'er, der hver kører sin egen PostgreSQL med en fuld lokal kopi af dataene. Det er shared-nothing — ingen delt volume, ingen netværkslagring, ingen enkelt disk som alle afhænger af. Medlemmerne holdes i sync med almindelig Postgres streaming-replikering.
- Patroni kører failover. Hvert medlem kører Patroni ved siden af Postgres. Det overvåger databasen og kører leder-valget med sin indbyggede raft — ingen ekstern etcd du skal drifte. Hvis primary-VM'en eller -processen dør, forfremmer Patroni den sundeste replika på sekunder.
- Ét stabilt endpoint. En managed load balancer eksponerer et enkelt
:5432. HAProxy kører et aktivt health check mod hvert medlems Patroni/primary-endpoint — kun den nuværende leder svarer 200 — så hver skrivning routes til primaryen, og endpointet følger automatisk en failover. - TLS hele vejen. Medlemmerne er kun private; du forbinder gennem load balancerens offentlige IP. LB'en er en TCP-passthrough, så TLS kører direkte fra din klient til Postgres — forbind med
sslmode=require.
klienter
│ postgres://…@<lb-ip>:5432/appdb?sslmode=require
▼
Managed Load Balancer · TCP :5432
│ HAProxy tjekker hvert medlems Patroni /primary
│ kun lederen svarer 200 -> skrivninger går derhen
▼
member-1 (PRIMARY) member-2 (replika) member-3 (replika)
Postgres + Patroni · fuld lokal kopi på hver · streaming-replikeringNår primaryen går ned, ser din klient en afbrudt forbindelse og forbinder så igen til det samme endpoint — intet host-skift, ingen config-ændring. Nye skrivninger lander på den netop forfremmede primary. Rolle-skiftet dukker op på cluster-siden og dens Activity-fane, og udløser en notifikation. De fleste connection pools forbinder igen af sig selv, så en failover er et kort blip snarere end et nedbrud.
Opret et i dashboardet
Det er et almindeligt cluster, i Database-mode. Under Console → Clusters → New cluster:
- Mode → Database, engine → PostgreSQL, version → den major-version du vil have.
- Noder. Én node er en enkelt, ikke-HA database. Tre eller flere giver dig en primary plus replikaer. To er ikke tilladt — en gruppe på to medlemmer har intet sikkert flertal at vælge en leder ud fra, så det er 1 eller 3+.
- Plan. Hvert medlem kører samme plan og holder en fuld kopi af dataene. Suble provisionerer medlemmerne, load balanceren og et privat netværk, sætter replikering op, og giver dig en connection string.
psql "postgres://suble:<password>@203.0.113.10:5432/appdb?sslmode=require"En superuser-adgangskode genereres til dig og vises på forespørgsel (kun for ejeren). Fra cluster-siden opretter du applikations-databaser og brugere pr. database — giv hver app en bruger med mindst mulige rettigheder frem for superuseren. Siden viser også hvert medlems rolle (PRIMARY / replika), dens replikerings-lag og connection string.
Ikke alt behøver tre noder
Til udvikling, staging og opgaver med lav indsats er de indbyggede databaser på en enkelt instans enklere og billigere. Grib fat i et cluster, når en primary der går ned faktisk ville tilkalde dig — og husk at et cluster med en node er en almindelig managed Postgres, du kan skalere op til HA senere.
Hvad det beskytter mod
Suble's clustre er reelt højt tilgængelige. Hvis primaryen går ned, forfremmer automatisk failover en sund replika på få sekunder og holder din database online. Dine data replikeres løbende til alle noder. Det samme replikerede design giver dig medlems-patching og minor-opgraderinger uden nedetid (medlemmer drænes og udskiftes et ad gangen) plus læse-skalering på tværs af replikaerne. Vi udvider det her på tværs af flere datacenter-noder og regioner.
HA er ikke en backup
Replikering beskytter mod at en node dør lige nu. Den gør intet ved at nogen droppede en tabel for en time siden — hver replika replikerer trofast droppet. Det er præcis hvad managed backups og point-in-time recovery (pgBackRest, streamet til din egen S3-bucket) er til.
Priser
Der er ingen særlig managed-Postgres-SKU. Et cluster koster summen af sine dele — medlems-VM'erne, load balanceren og det private netværk — på de samme ressource-målere som alt andet på Suble, alt målt pr. time og loftet månedligt. Dashboardet viser det løbende måneds-estimat, mens du dimensionerer det.
Prøv det
Opret et Database-cluster, vælg PostgreSQL og tre noder, og forbind til det enkelte endpoint — failover og routing er klaret for dig. Den fulde guide findes i Managed PostgreSQL-dokumentationen, og er clusters nye for dig, så start med Kør din app på tværs af mange maskiner.
Skrevet af
The Suble team
Engineering