Administration af High Availability (HA) i din PostgreSQL-hosting er et meget vigtigt emne for at sikre, at dine databaseimplementeringsklynger opretholder enestående oppetid og stærk driftsydeevne, så dine data altid er tilgængelige for din applikation. I et tidligere blogindlæg introducerede vi dig til konfiguration af høj tilgængelighed for PostgreSQL ved hjælp af streamingreplikering, og nu skal vi vise dig, hvordan du bedst administrerer høj tilgængelighed på klientsiden.
Der er flere tilgængelige værktøjer til at administrere den høje tilgængelighed (HA) af dine PostgreSQL-implementeringsklynger ved hjælp af streamingreplikering. Disse løsninger tilbyder automatiske failover-funktioner, overvåger tilgængelighed og systemstatus, replikering, brugeradministration og andre nyttige administrative opgaver på use cases for Postgres-databaser. Nogle af de fremtrædende open source-løsninger inkluderer:
-
PostgreSQL Automatic Failover af ClusterLabs
-
Replication Manager for PostgreSQL-klynger af repmgr (2ndQuadrant)
-
Patroni af Zalando
Hvert værktøj giver deres egen måde at administrere de højtilgængelige PostgreSQL-klynger på. I vores tredelte serie af indlæg om HA til PostgreSQL deler vi et overblik, forudsætningerne og arbejds- og testresultaterne for hvert af disse tre værktøjer. Her i del 1 vil vi dykke dybt ned i PAF-løsningen fra ClusterLabs.
- Håndtering af høj tilgængelighed i PostgreSQL – Del II:Replication Manager
- Styring af høj tilgængelighed i PostgreSQL – Del III:Patroni
Hvordan administrerer du høj tilgængelighed for din PostgreSQL-database?
PostgreSQL Automatic Failover (PAF) er en administrationsløsning med høj tilgængelighed til PostgreSQL af ClusterLabs. Den bruger Postgres synkron replikering til at garantere, at ingen data går tabt på tidspunktet for failover-operationen. Den gør brug af den populære industristandard Pacemaker og Corosync stack. Med Pacemaker- og Corosync-applikationer sammen, vil du være i stand til at opdage PostgreSQL-databasefejl i systemet og handle derefter.
Pacemaker er en tjeneste, der er i stand til at administrere mange ressourcer og gør det ved hjælp af deres ressourceagenter. Ressourceagenter har derefter ansvaret for at håndtere en specifik ressource, hvordan de skal opføre sig og informere Pacemaker om deres resultater.
Din ressourceagentimplementering skal overholde Open Cluster Framework-specifikationen (OCF). Denne specifikation definerer ressourceagenters adfærd og implementering af metoder som stop, start, fremme, degradere og interaktion med Pacemaker.
PAF er en OCF-ressourceagent for Postgres skrevet i Perl. Når først din databaseklynge er bygget ved hjælp af intern streaming-replikering, er PAF i stand til at eksponere for Pacemaker den aktuelle status for PostgreSQL-instansen på hver enkelt af databasens noder:master, slave, stoppet, indhentning, load balancer osv.
Sådan fungerer Postgres Automatic Failover
PAF kommunikerer med Pacemaker vedrørende klyngestatus og overvåger PostgreSQL-databasens funktion. I tilfælde af en fejl informerer den Pacemaker, og hvis der ikke er nogen chance for, at den aktuelle master bliver gendannet, vil det udløse et valg mellem en af de nuværende standby-databaseservere. Med den robuste Pacemaker på plads vil Postgres Automatic Failover udføre administrationshandlinger som start, stop, overvågning og failover på alle Postgres-databasernes noder.
Håndtering af høj tilgængelighed i PostgreSQL - Del I:Automatic Failover af ClusterLabsKlik for at tweete
PostgreSQL Automatic Failover for High Availability (HA)-konfiguration
- PAF understøtter PostgreSQL version 9.3 og nyere.
- PAF er ikke ansvarlig for PostgreSQL-master/standby-oprettelse eller dens opsætning - du skal oprette og konfigurere streaming-replikering, før du bruger PAF.
- PAF redigerer ikke nogen konfigurations- eller opsætningskrav for PostgreSQL. Det kræver dog, at databasebrugere følger nogle få forudsætninger som:
- Slaven skal konfigureres som varm standby. Hot standby-slaveknuder kan forespørges som skrivebeskyttede databaser.
- En gendannelsesskabelonfil (standard:
/recovery.conf.pcmk) skal leveres med nedenstående parametre: - standby_mode =på
- recovery_target_timeline ='seneste'
- primary_conninfo skal have parameteren application_name defineret og indstillet til lokalt nodenavn som i Pacemaker.
- PAF afslører flere parametre relateret til administrationen af en Postgres-ressource. Dette kan konfigureres, så det passer til ens krav. Nedenfor er parametrene:
- binder: placering af PostgreSQL binære filer (standard:/usr/bin)
- pgdata: placering af PGDATA for din instans (standard:/var/lib/pgsql/data)
- datadir: stien til den mappe, der er angivet i data_directory fra din postgresql.conf-fil
- pghost: socket-biblioteket eller IP-adressen, der skal bruges til at oprette forbindelse til den lokale instans (standard:/tmp)
- pgport: porten for at oprette forbindelse til den lokale instans (standard:5432)
- gendannelsesskabelon: den lokale skabelon, der vil blive kopieret som filen PGDATA/recovery.conf. Denne skabelonfil skal eksistere på alle noder (standard:$PGDATA/recovery.conf.pcmk)
- start_opts: Yderligere argumenter givet til Postgres-processen ved opstart. Se "postgres -help" for tilgængelige muligheder. Nyttigt, når postgresql.conf-filen ikke er i databiblioteket (PGDATA), f.eks.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
- systembruger: systemejeren af din instanss proces (standard:postgres)
- maxlag: maksimalt tilladt forsinkelse på en standby, før vi sætter en negativ masterscore på den
Postgres Automatic Failover Pros
- PAF giver brugeren en gratis praktisk konfiguration og opsætning af PostgreSQL.
- PAF kan håndtere knudefejl og udløse valg, når masteren går ned.
- Kvorumsadfærd kan håndhæves i PAF.
- Det vil give en komplet databaseadministrationsløsning (HA) for ressourcen, inklusive start, stop og overvågning og håndtering af netværksisolationsscenarier.
- Det er en distribueret løsning, som gør det muligt at administrere enhver node fra en anden node.
Postgres Automatic Failover Ulemper
- PAF registrerer ikke, om en standby-knude er forkert konfigureret med en ukendt eller ikke-eksisterende knude i gendannelseskonfigurationen. Node vil blive vist som slave, selvom standby kører uden at oprette forbindelse til master/cascading standby node.
- Kræver en ekstra port (standard 5405) for at blive åbnet for pacemaker- og Corosync-komponenternes kommunikation ved hjælp af UDP.
- Understøtter ikke NAT-baseret konfiguration.
- Ingen understøttelse af pg_rewind.
Høj tilgængelighed for PostgreSQL-testscenarier
Vi udførte et par tests for at bestemme kapaciteten af PostgreSQL-styringen med høj tilgængelighed (ha) ved hjælp af PAF i nogle tilfælde. Alle disse test blev kørt, mens applikationen kørte og indsatte data i PostgreSQL-databasen. Ansøgningen blev skrevet ved hjælp af PostgreSQL Java JDBC-driver, der udnyttede forbindelsesfejloverførslen.
Standby-servertests
| Sl. Nej | Testscenarie | Observation |
|---|---|---|
| 1 | Dræb PostgreSQL-processen | Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand. Der var ingen forstyrrelse i forfatteransøgningen. |
| 2 | Stop PostgreSQL-processen | Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand. Der var ingen forstyrrelse i forfatteransøgningen. |
| 3 | Genstart serveren | Standby-databaseserverknudepunktet blev oprindeligt markeret som offline. Når serveren kom op efter genstart, blev PostgreSQL-databasen startet af Pacemaker, og serveren blev markeret som online. Hvis hegn var aktiveret, ville noden ikke automatisk være blevet tilføjet til klyngen. Der var ingen forstyrrelse i forfatteransøgningen. |
| 4 | Stop pacemaker-processen | Det vil også stoppe PostgreSQL-processen, og servernoden vil blive markeret offline. Der var ingen forstyrrelse i forfatteransøgningen. |
Master/Primær servertest
| Sl. Nej | Testscenarie | Observation |
| 1 | Dræb PostgreSQL-processen | Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand. Primær blev genoprettet inden for tærskeltiden, og valget blev derfor ikke udløst. Writer-applikationen var nede i omkring 26 sekunder. |
| 2 | Stop PostgreSQL-processen | Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand. Primær blev genoprettet inden for tærskeltiden, og valget blev derfor ikke udløst. Der var en nedetid i writer-applikationen i omkring 26 sekunder. |
| 3 | Genstart serveren | Valget blev udløst af Pacemaker efter den tærskeltid, som master ikke var tilgængelig for. Den mest kvalificerede standby-server blev forfremmet som den nye master. Når den gamle master kom op efter genstart, blev den tilføjet tilbage til databaseklyngen som en standby. Hvis hegn var aktiveret, ville noden ikke automatisk være blevet tilføjet til klyngen. Forfatterapplikationstjenesten var nede i omkring 26 sekunder. |
| 4 | Stop pacemaker-processen | Det vil også stoppe PostgreSQL-processen, og serveren vil blive markeret offline. Valg vil blive udløst og ny mester vil blive valgt. Der var nedetid i forfatterapplikationen. |
Netværksisolationstest
| Sl. Nej | Testscenarie | Observation |
| 1 | Netværket isolerer standby-serveren fra andre servere | Corosync-trafik blev blokeret på standby-serveren. Serveren blev markeret som offline, og PostgreSQL-tjenesten blev slået fra på grund af kvorumspolitik. Der var ingen forstyrrelse i forfatterapplikationen. |
| 2 | Netværk isolerer masterserveren fra andre servere (split-brain-scenarie) | Corosync-trafik blev blokeret på masterserveren. PostgreSQL-tjenesten blev slået fra, og hovedserveren blev markeret som offline på grund af kvorumspolitik. En ny mester blev valgt i flertalsdelingen. Der var en nedetid i writer-applikationen. |
Diverse tests
| Sl. Nej | Testscenarie | Observation |
| 1 | Degrader klyngen ved at slukke for alle standby-servere. | Da alle standby-servere gik ned, blev PostgreSQL-tjenesten på master stoppet på grund af kvorumspolitik. Efter denne test, da alle standby-servere var tændt, blev en ny master valgt. Der var en nedetid i writer-applikationen. |
| 2 | Sluk alle servere tilfældigt efter hinanden, startende med masteren, og bring dem alle tilbage på samme tid | Alle servere kom op og sluttede sig til klyngen. Ny mester blev valgt. Der var en nedetid i writer-applikationen. |
Er PAF løsningen til PostgreSQL High Availability?
Postgres Automatic Failover giver adskillige fordele ved håndtering af PostgreSQL høj tilgængelighed (HA) på mange use cases. PAF bruger IP-adresse-failover i stedet for at genstarte standby for at oprette forbindelse til den nye master under en failover-hændelse. Dette viser sig at være fordelagtigt i scenarier, hvor brugeren ikke ønsker at genstarte standby-knudepunkterne. PAF har også brug for meget lidt manuel indgriben og styrer den overordnede tilstand af alle Postgres databaseressourcer. Det eneste tilfælde, hvor manuel indgriben er et krav, er i tilfælde af en tidslinjedatadivergens, hvor brugeren kan vælge at bruge pg_rewind.
I del 1 har vi diskuteret mulighederne og funktionerne i PostgreSQL Automatic Failover (PAF) af ClusterLabs, og i del 2 vil vi diskutere de samme høje tilgængelighedsaspekter ved hjælp af Replication Manager for PostgreSQL-klynger (repmgr) af 2ndQuadrant. Sørg for at vende tilbage til del 3, hvor vi også dækker Patroni af Zalando og sammenligner alle tre open source-løsninger for at hjælpe dig med at finde den bedst egnede til din applikation.
I del 1 blog har vi diskuteret mulighederne, bedste praksis og virkemåden af PAF by ClusterLabs, og i del 2 blogindlæg vil vi diskutere det samme emne med høj tilgængelighedsaspekter ved hjælp af Replikeringsmanageren for Postgresql-klynger (repmgr) af 2ndQuadrant. Sørg for at vende tilbage til vores blogindlæg om del 3, hvor vi også dækker Patroni af Zalando og sammenligner alle tre open source-løsninger for at hjælpe dig med at finde den bedste praksis og den ideelle pasform til dine virksomhedsapplikationer.
