Administration af høj tilgængelighed i PostgreSQL – Del II:Replikeringsmanager

Installerer du PostgreSQL i skyen og vil du forstå dine muligheder for at opnå høj tilgængelighed? I vores tidligere blogindlæg, Managing High Availability in PostgreSQL – Part I, diskuterede vi mulighederne og funktionen af ​​PostgreSQL Automatic Failover (PAF) af ClusterLabs. I del II introducerer vi dig for et alternativt open source-værktøj, Replication Manager fra 2ndQuadrant, som skal følges tæt af del III, hvor vi dykker ned i vores tredje alternativ, Patroni af Zalando.

• Administration af høj tilgængelighed i PostgreSQL – Del I:PostgreSQL Automatic Failover
• Styring af høj tilgængelighed i PostgreSQL – Del III:Patroni

Replication Manager (repmgr)

repmgr er en open source-værktøjspakke udviklet af 2ndQuadrant til styring af replikering og failover af dine PostgreSQL-klynger. Det giver værktøjerne til at opsætte, konfigurere, administrere og overvåge replikering af PostgreSQL, og det giver dig også mulighed for at udføre manuelle omskiftnings- og failover-opgaver ved hjælp af værktøjet repmgr. Dette gratis værktøj understøtter og forbedrer PostgreSQLs indbyggede streaming-replikering.

Replication Manager giver to hovedværktøjer til at administrere replikering og failover af PostgreSQL.

repmgr

• Et kommandolinje-interfaceværktøj, som sætter dig i stand til at udføre forskellige administrative opgaver.
• repmgr giver dig mulighed for at konfigurere standby-servere, fremme standby, foretage en overgang og overvåge status for din PostgreSQL-klynge.
• Det giver også mulighed for tørkørsel for næsten alle administrative kommandoer.

repmgrd

Dette er dæmonen, som:

• Overvåger aktivt PostgreSQL-klyngerne og udfører nødvendige handlinger baseret på klyngens tilstand.
• Udfører automatisk failover i tilfælde af, at den primære node går ned ved at promovere den mest kvalificerede standby som den nye primære.
• Giver en mulighed for at overvåge og gemme data relateret til replikeringsydelse.
• Giver meddelelse ved at påkalde brugerscripts for registrerede begivenheder.

Sådan virker det

repmrg administrerer ikke kun replikeringen af ​​PostgreSQL-klynger, men har også muligheder for at opsætte standby-servere til replikering. Efter den indledende installation skal vi foretage ændringer i repmgr-konfigurationsfilen (repmgr.conf) med de nødvendige detaljer på hver server. Når en server er konfigureret, skal den registreres med repmgr ved hjælp af repmgr primær/standby register kommando. Først opsættes og registreres den primære node. Derefter oprettes og konfigureres standby-servere ved hjælp af repmgr standby clone-kommandoen, som kloner PostgreSQL standby-noden fra en anden PostgreSQL-server.

Replication Manager gør brug af PostgreSQL-udvidelsesfunktionen og opretter sit eget skema på klyngedatabasen for at gemme den klyngerelaterede information. Installation af udvidelsen og oprettelse af skemaet sker under registreringen af ​​den primære server ved hjælp af repmgr. Når opsætningen er fuldført, kan manuelle administrative handlinger såsom promote, follow, switchover osv. udføres ved hjælp af værktøjet repmgr. For omskiftningsoperation kræver det, at SSH uden adgangskode er opsat mellem noderne.

Automatisk failover kan konfigureres ved hjælp af repmgrd. repmgrd kræver, at et delt bibliotek 'repmgr' indlæses på tidspunktet for start af PostgreSQL-serveren. Bibliotekets navn skal nævnes i shared_preload_libraries konfigurationsparameter i postgresql.conf-filen. For at repmgrd skal fungere, failover=automatisk parameter skal indstilles i filen repmgr.conf. Når alle disse parametre er indstillet, begynder repmgrd daemon aktivt at overvåge klyngen. Hvis der er nogen fejl i den primære node, vil den forsøge at genoprette forbindelsen flere gange. Når alle forsøg på at oprette forbindelse til primær mislykkes, vælges den mest kvalificerede standby ved valg som ny primær af repmgrd.

repmgr understøtter også begivenhedsmeddelelser. Den har et sæt foruddefinerede hændelser og gemmer hver forekomst af disse hændelser i repmgr.events-tabellen. repmgr gør det muligt at sende hændelsesmeddelelser til et brugerdefineret program eller script, som kan foretage yderligere handlinger, såsom at sende en e-mail eller udløse en alarm. Dette gøres ved at indstille event_notification_command parameter i repmgr.conf.

Hvordan håndterer den det splittede hjernescenarie?

repmgr håndterer splittede hjernescenarier ved hjælp af placeringen parameter, hvor hver node skal angive placeringsparameteren baseret på det datacenter, hvori den er placeret. I tilfælde af netværksdeling vil repmgr sikre promovering af noden, som er på samme sted som den primære. Hvis den ikke finder nogen node på den placering, vil den ikke promovere nogen node på nogen placering.

Det håndterer også netværksisolering i tilfælde af et lige antal servere i en klynge. Dette gøres ved hjælp af en ekstra node kaldet vidneserveren. Vidneserveren er en node, som kun tages i betragtning ved optælling af flertal. Der vil ikke være nogen PostgreSQL-installation på den server, og derfor ingen rolle at spille i replikering.

Er der nogen opsætningskrav?

• repmgr kræver en dedikeret database og en bruger med superbrugerrettigheder. Der er dog også en mulighed for at give en superbruger, hvis du ikke er villig til at give superbrugeren adgang til repmgr-brugeren.
• Hvis du vil have repmgr til at kopiere konfigurationsfiler, som er placeret uden for PostgreSQL-databiblioteket, og/eller for at teste switchover-funktionalitet, skal du også bruge adgangskodeløse SSH-forbindelser mellem begge servere, og rsync skal være installeret.
• Hvis du har til hensigt at bruge andre servicebaserede kommandoer end pg_ctl (som bruges af repmgr som standard) til at starte, stoppe, genindlæse og genstarte, kan du angive dem i repmgr konfigurationsfil (repmgr.conf).
• De grundlæggende konfigurationsparametre, der kræves i repmgr-konfigurationsfilen, er som følger:
  

  node_id (int) – Et unikt heltal større end nul, som identificerer noden.node_name (streng) – En vilkårlig (men unik) streng, der bruger serverens værtsnavn eller en anden identifikator, der er utvetydigt forbundet med serveren, anbefales for at undgå forvirring. forbindelsesinfo (streng) – Databaseforbindelsesoplysninger som en conninfo-streng. Alle servere i klyngen skal kunne oprette forbindelse til den lokale node ved hjælp af denne streng. data_directory (streng) – Nodens datakatalog. Dette er nødvendigt af repmgr for at udføre operationer, når PostgreSQL-forekomsten ikke kører, og der ikke er nogen anden måde at bestemme databiblioteket på.

repmgr Fordele

• Repmgr leverer værktøjer, der hjælper med at konfigurere primære og standby noder og konfigurere replikering.
• Den bruger ingen ekstra porte til kommunikation. Hvis du vil udføre omskiftning, vil det først kræve, at SSH uden adgangskode konfigureres.
• Giver besked ved at påkalde brugerscripts for de registrerede begivenheder.
• Udfører automatisk failover i tilfælde af primær serverfejl.

repmgr Ulemper

• repmgr registrerer ikke, om standbyen er forkert konfigureret med en ukendt eller ikke-eksisterende node i gendannelseskonfigurationen. Noden vil blive vist som standby, selvom den kører uden at oprette forbindelse til den primære/kaskadende standby node.
• Kan ikke hente status for en anden node fra en node, hvor PostgreSQL-tjenesten er nede. Derfor giver den ikke en distribueret kontrolløsning.
• Det håndterer ikke gendannelse af individuelle noders helbred.

Håndtering af høj tilgængelighed i #PostgreSQL – Del II:Open Source repmgr-værktøj Klik for at tweete

testscenarier for høj tilgængelighed

Vi udførte et par test på PostgreSQL høj tilgængelighedsstyring ved hjælp af repmgr. 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

Master/Primær servertest

Netværksisolationstest

Inferens

repmgr leverer adskillige kommandoer til opsætning og overvågning af PostgreSQL-replikering. Den er rig på funktioner og letter også jobbet for databaseadministratoren (DBA). Det er dog ikke et fuldgyldigt administrationsværktøj med høj tilgængelighed, da det ikke vil administrere ressourcerne. Manuel indgriben er påkrævet for at sikre, at ressourcen er i korrekt tilstand.

Så i dette indlæg har vi diskuteret mulighederne og funktionerne i Replication Manager af 2ndQuadrant. I vores næste indlæg vil vi diskutere de samme høje tilgængelighedsaspekter ved hjælp af Patroni af Zalando. For brugere, der ønsker at automatisere deres høje tilgængelighed i skyen, kan du tjekke vores PostgreSQL på Azure og PostgreSQL på AWS fuldt administrerede løsninger.