Hantera hög tillgänglighet i PostgreSQL – Del II:Replikeringshanterare

Distribuerar du PostgreSQL i molnet och vill du förstå dina alternativ för att uppnå hög tillgänglighet? I vårt tidigare blogginlägg, Managing High Availability in PostgreSQL – Del I, diskuterade vi funktionerna och funktionen hos PostgreSQL Automatic Failover (PAF) av ClusterLabs. I del II presenterar vi ett alternativt verktyg med öppen källkod, Replication Manager från 2ndQuadrant, som tätt följs av del III där vi dyker in i vårt tredje alternativ, Patroni av Zalando.

Hantera hög tillgänglighet i PostgreSQL – Del I:PostgreSQL Automatic Failover
Hantera hög tillgänglighet i PostgreSQL – Del III:Patroni

Replication Manager (repmgr)

repmgr är en öppen källkodssvit utvecklad av 2ndQuadrant för att hantera replikering och failover av dina PostgreSQL-kluster. Den tillhandahåller verktygen för att ställa in, konfigurera, hantera och övervaka replikering av PostgreSQL, och gör det också möjligt för dig att utföra manuella övergångs- och failover-uppgifter med hjälp av verktyget repmgr. Det här kostnadsfria verktyget stöder och förbättrar PostgreSQL:s inbyggda strömmande replikering.

Replication Manager tillhandahåller två huvudverktyg för att hantera replikering och failover av PostgreSQL.

repmgr

Ett kommandoradsgränssnittsverktyg som gör att du kan utföra olika administrativa uppgifter.
repmgr gör det möjligt för du att ställa in standby-servrar, främja standby-lägen, göra en övergång och övervaka statusen för ditt PostgreSQL-kluster.
Den ger också möjlighet till torrkörning för nästan alla administrativa kommandon.

repmgrd

Detta är demonen som:

Övervakar aktivt PostgreSQL-klustren och utför nödvändiga åtgärder baserat på klustrets tillstånd.
Utför automatisk failover om den primära noden går ner genom att marknadsföra den mest kvalificerade vänteläge som den nya primära.
Ger ett alternativ för att övervaka och lagra data relaterade till replikeringsprestanda.
Ger meddelande genom att anropa användarskript för registrerade händelser.

Så fungerar det

repmrg hanterar inte bara replikeringen av PostgreSQL-kluster, utan har också möjligheter att ställa in standbyservrarna för replikering. Efter den första installationen måste vi göra ändringar i repmgr-konfigurationsfilen (repmgr.conf) med de nödvändiga detaljerna på varje server. När en server är konfigurerad måste den registreras med repmgr med hjälp av repmgr primära/väntelägesregisterkommandot. Först ställs den primära noden in och registreras. Sedan skapas och konfigureras standbyservrar med hjälp av repmgr standby clone-kommandot som klonar PostgreSQL standby-noden från en annan PostgreSQL-server.

Replication Manager använder sig av PostgreSQL-tilläggsfunktionen och skapar sitt eget schema i klusterdatabasen för att lagra klusterrelaterad information. Installation av tillägget och skapandet av schemat sker under registreringen av den primära servern med repmgr. När installationen är klar kan manuella administrativa operationer såsom främja, följa, byta, etc. göras med hjälp av verktyget repmgr. För omkopplingsoperation krävs att lösenordslös SSH ställs in mellan noderna.

Automatisk failover kan ställas in med repmgrd. repmgrd kräver att ett delat bibliotek "repmgr" laddas när PostgreSQL-servern startas. Bibliotekets namn bör nämnas i shared_preload_libraries konfigurationsparametern i postgresql.conf-filen. För att repmgrd ska fungera, failover=automatic parametern måste ställas in i filen repmgr.conf. När alla dessa parametrar är inställda börjar repmgrd-demonen att aktivt övervaka klustret. Om det finns något fel i den primära noden kommer den att försöka återansluta flera gånger. När alla försök att ansluta till primärvalet misslyckas, väljs den mest kvalificerade vänteläget genom val som ny primär av repmgrd.

repmgr stöder även händelseaviseringar. Den har en uppsättning fördefinierade händelser och lagrar varje förekomst av dessa händelser i tabellen repmgr.events. repmgr gör det möjligt att skicka händelsemeddelanden till ett användardefinierat program eller skript som kan vidta ytterligare åtgärder, som att skicka ett e-postmeddelande eller utlösa en varning. Detta görs genom att ställa in event_notification_command parameter i repmgr.conf.

Hur hanterar det Scenariot med delad hjärna?

repmgr hanterar scenarier med splittrade hjärnor med hjälp av platsen parameter, där varje nod ska ange platsparametern baserat på det datacenter där den är placerad. I händelse av nätverksdelning kommer repmgr att säkerställa marknadsföringen av noden som är på samma plats som den primära. Om den inte hittar någon nod på den platsen kommer den inte att marknadsföra någon nod på någon plats.

Den hanterar även nätverksisolering i händelse av ett jämnt antal servrar i ett kluster. Detta görs med hjälp av en extra nod som kallas vittnesservern. Vittnesservern är en nod som endast beaktas för majoritetsrösträkningen. Det kommer inte att finnas någon PostgreSQL-installation på den servern, och därför ingen roll att spela i replikeringen.

Finns det några installationskrav?

repmgr kommer att kräva en dedikerad databas och en användare med superanvändarbehörigheter. Men det finns också ett alternativ att tillhandahålla en superanvändare om du inte är villig att ge superanvändaren åtkomst till repmgr-användare.
Om du vill att repmgr ska kopiera konfigurationsfiler som finns utanför PostgreSQL-datakatalogen och/eller testa omkopplingsfunktionalitet, behöver du också lösenordslösa SSH-anslutningar mellan båda servrarna, och rsync bör installeras.
Om du tänker använda andra tjänstebaserade kommandon än pg_ctl (som används av repmgr som standard) för att starta, stoppa, ladda om och starta om, kan du ange dem i repmgr konfigurationsfil (repmgr.conf).

De grundläggande konfigurationsparametrarna som krävs i repmgr-konfigurationsfilen är följande:

node_id (int) – Ett unikt heltal större än noll som identifierar noden.nodnamn (sträng) – En godtycklig (men unik) sträng som använder serverns värdnamn eller annan identifierare som entydigt är associerad med servern rekommenderas för att undvika förvirring.

konninfo (sträng) – Databasanslutningsinformation som en conninfo-sträng. Alla servrar i klustret måste kunna ansluta till den lokala noden med den här strängen.

data_katalog (sträng) – Nodens datakatalog. Detta behövs av repmgr för att utföra operationer när PostgreSQL-instansen inte körs och det inte finns något annat sätt att fastställa datakatalogen.

repmgr Proffs

Repmgr tillhandahåller verktyg som hjälper till att ställa in primära och standbynoder och konfigurera replikering.
Den använder inga extra portar för kommunikation. Om du vill utföra övergången, först då kommer det att kräva att lösenordslös SSH konfigureras.
Ger meddelande genom att anropa användarskripten för de registrerade händelserna.
Utför automatisk failover vid primär serverfel.

repmgr Nackdelar

repmgr upptäcker inte om vänteläget är felkonfigurerat med en okänd eller obefintlig nod i återställningskonfigurationen. Noden kommer att visas som standby även om den körs utan att ansluta till den primära/kaskadkopplade standbynoden.
Kan inte hämta status för en annan nod från en nod där PostgreSQL-tjänsten är nere. Därför tillhandahåller den inte en distribuerad kontrolllösning.
Den hanterar inte att återställa hälsan för enskilda noder.

Hantera hög tillgänglighet i #PostgreSQL – Del II:Verktyg för repmgr med öppen källkod Klicka för att tweeta

testscenarier för hög tillgänglighet

Vi genomförde några tester på PostgreSQL hög tillgänglighetshantering med hjälp av repmgr. Alla dessa tester kördes medan applikationen kördes och infogade data till PostgreSQL-databasen. Applikationen skrevs med hjälp av PostgreSQL Java JDBC-drivrutin som utnyttjar möjligheten för anslutningsfel.

Standby-servertest

Sl. Nej	Testscenario	Observation
1	Döda PostgreSQL-processen	Standbyservern markerades som misslyckad. Det var inga avbrott i skribentansökan. Manuell intervention krävdes för att starta PostgreSQL-processen igen.
2	Stoppa PostgreSQL-processen	Standbyservern markerades som misslyckad. Det var inga avbrott i skribentansökan. Manuell intervention krävdes för att starta PostgreSQL-processen igen.
3	Starta om servern	Standbyservern markerades som misslyckad. När servern väl kom upp efter omstart startades PostgreSQL manuellt och servern markerades som igång. Det var inga avbrott i skribentapplikationen.
4	Stoppa repmgrd-processen	Vänteservern kommer inte att vara en del av den automatiska failover-situationen. PostgreSQL-tjänsten visade sig vara igång. Det var inga avbrott i skribentapplikationen.

Tester av master/primär server

Sl. Nej	Testscenario	Observation
1	Döda PostgreSQL-processen	repmgrd startade hälsokontrollen för den primära serveranslutningen på alla standbyservrar under ett fast intervall. När alla försök misslyckades utlöstes ett val på alla standby-servrar. Som ett resultat av valet befordrades den standby som hade den senaste mottagna LSN. Standbyservrarna som förlorade valet kommer att vänta på meddelandet från den nya huvudnoden och följa det när de får meddelandet. Det var driftstopp i skrivprogrammet. Manuell intervention krävdes för att starta PostgreSQL-processen igen.
2	Stoppa PostgreSQL-processen och ta tillbaka den omedelbart efter att hälsokontrollen har gått ut	repmgrd startade hälsokontrollen för den primära serveranslutningen på alla standbyservrar under ett fast intervall. När alla försök misslyckades utlöstes ett val på alla standbynoder. Den nyvalda mastern meddelade dock inte de befintliga standbyservrarna eftersom den gamla mastern var tillbaka. Klustret lämnades i ett obestämt tillstånd och manuellt ingripande krävdes.
3	Starta om servern	repmgrd startade valet när huvudanslutningens hälsokontroll misslyckades på alla standby-servrar. Den kvalificerade vänteläge har främjats. När den här servern kom tillbaka gick den inte med i klustret och markerades som misslyckad. repmgr node rejoin-kommandot kördes för att lägga till servern tillbaka till klustret. Det var driftstopp i writer-applikationen.
4	Stoppa repmgr-processen	Den primära servern kommer inte att vara en del av den automatiska failover-situationen. PostgreSQL-tjänsten hittades vara igång. Det var inga avbrott i skribentapplikationen.

Tester för nätverksisolering

Sl. Nej	Testscenario	Observation
1	Nätverk isolerar den primära servern från andra servrar (alla har samma värde för plats i repmgr-konfigurationen)	repmgrd startade valet när huvudanslutningens hälsokontroll misslyckades på alla standby-servrar. Den kvalificerade vänteläge har främjats, men PostgreSQL-processen kördes fortfarande på den gamla huvudnoden. Det fanns två noder som körde som master. Manuellt ingripande krävdes efter att nätverksisoleringen korrigerats.
2	Nätverk isolerar den primära servern från andra servrar (standby-servrarna har samma värde för plats men primärt hade ett annat värde för plats i repmgr-konfigurationen)	repmgrd startade valet när huvudanslutningens hälsokontroll misslyckades på alla standby-servrar. Men det valdes ingen ny master eftersom standbyservrarna hade en annan plats än den primära. repmgrd gick in i försämrat övervakningsläge. PostgreSQL kördes på alla noder och det fanns bara en master i klustret.

Inferens

repmgr ger flera kommandon för att ställa in och övervaka PostgreSQL-replikering. Den är rik på funktioner och underlättar också jobbet för databasadministratören (DBA). Det är dock inte ett fullfjädrat verktyg för hantering av hög tillgänglighet eftersom det inte kommer att hantera resurserna. Manuellt ingripande krävs för att säkerställa att resursen är i korrekt skick.

Så, i det här inlägget har vi diskuterat funktionerna och funktionerna i Replication Manager av 2ndQuadrant. I vårt nästa inlägg kommer vi att diskutera samma höga tillgänglighetsaspekter med Patroni av Zalando. För användare som vill automatisera sin höga tillgänglighet i molnet, kolla in våra PostgreSQL på Azure och PostgreSQL på AWS helt hanterade lösningar.