sql >> Databasteknik >  >> RDS >> PostgreSQL

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

I våra tidigare blogginlägg diskuterade vi funktionerna och funktionen hos PostgreSQL Automatic Failover (PAF) av Cluster Labs och Replication Manager (repmgr) av 2ndQuadrant. I det sista inlägget i den här serien kommer vi att granska den sista lösningen, Patroni av Zalando, och jämföra alla tre i slutet så att du kan avgöra vilket ramverk för hög tillgänglighet som är bäst för din PostgreSQL-värddrift.

  • Hantera hög tillgänglighet i PostgreSQL – Del I:PostgreSQL Automatic Failover
  • Hantera hög tillgänglighet i PostgreSQL – Del II:Replikeringshanterare

Patroni för PostgreSQL

Patroni har sitt ursprung som en gaffel av Governor, ett projekt från Compose. Det är en öppen källkodssvit, skriven i Python, för att hantera hög tillgänglighet av PostgreSQL-kluster. Istället för att bygga sitt eget konsistensprotokoll använder Patroni på ett smart sätt konsistensmodellen som tillhandahålls av en Distributed Configuration Store (DCS). Den stöder även andra DCS-lösningar som Zookeeper, etcd, Consul och Kubernetes.

Patroni säkerställer end-to-end-installationen av PostgreSQL HA-kluster, inklusive strömmande replikering. Den stöder olika sätt att skapa en standby-nod och fungerar som en mall som kan anpassas efter dina behov.

Det här funktionsrika verktyget exponerar sin funktionalitet via REST API:er och även via ett kommandoradsverktyg som heter patronictl. Den stöder integration med HAProxy genom att använda dess API:er för hälsokontroll för att hantera lastbalansering.

Patroni stöder även händelseaviseringar med hjälp av återuppringningar, som är skript som utlöses av vissa åtgärder. Det gör det möjligt för användare att utföra alla underhållsåtgärder genom att tillhandahålla paus-/återuppta-funktioner. Watchdog-stödfunktionen gör ramverket ännu mer robust.

Så fungerar det

Initialt måste PostgreSQL- och Patroni-binärfiler installeras. När detta är gjort måste du också ställa in en HA DCS-konfiguration. Alla nödvändiga konfigurationer för att starta upp klustret måste specificeras i yaml-konfigurationsfilen och Patroni kommer att använda den här filen för initiering. På den första noden initierar Patroni databasen, erhåller ledarlåset från DCS och säkerställer att noden körs som master.

Nästa steg är att lägga till standbynoder, för vilka Patroni tillhandahåller flera alternativ. Som standard använder Patroni pg_basebackup för att skapa standby-noden, och stöder även anpassade metoder som WAL-E, pgBackRest, Barman och andra för att skapa standby-noden. Patroni gör det väldigt enkelt att lägga till en standby-nod och hanterar alla bootstrapping-uppgifter och konfigurering av din streamingreplikering.

Hantera hög tillgänglighet i #PostgreSQL – Del III:Patroni vs. PAF vs. repmgrKlicka för att tweeta

När din klusterkonfiguration är klar kommer Patroni aktivt att övervaka klustret och se till att det är i ett hälsosamt tillstånd. Masternoden förnyar ledarlåset varje ttl sekund(er) (standard:30 sekunder). När masternoden misslyckas med att förnya ledarlåset utlöser Patroni ett val, och noden som ska få ledarlåset kommer att väljas till ny master.

Hur hanterar det Scenariot med delad hjärna?

I ett distribuerat system spelar konsensus en viktig roll för att bestämma överensstämmelse, och Patroni använder DCS för att nå konsensus. Endast noden som håller ledarlåset kan vara master och ledarlåset erhålls via DCS. Om masternoden inte håller ledarlåset, kommer den att degraderas omedelbart av Patroni för att köras som standby. På så sätt, när som helst, kan det bara finnas en master som körs i systemet.

Finns det några installationskrav?

  • Patroni behöver python 2.7 och senare.
  • DCS och dess specifika pythonmodul måste installeras. För teständamål kan DCS installeras på samma noder som kör PostgreSQL. I produktionen måste dock DCS installeras på separata noder.
  • Yaml-konfigurationsfilen måste finnas med dessa högnivåkonfigurationsinställningar:

    Global/Universal
    Detta inkluderar konfiguration som namnet på värden (namn) som måste vara unikt för klustret, namnet på klustret (omfattning) och sökväg för att lagra konfiguration i DCS (namnutrymme).

    Logg
    Patroni-specifika logginställningar inklusive nivå, format, file_num, file_size etc.

    Bootstrap-konfiguration
    Detta är den globala konfigurationen för ett kluster som kommer att skrivas till DCS. Dessa konfigurationsparametrar kan ändras med hjälp av Patroni API:er eller direkt i DCS. Bootstrap-konfigurationen inkluderar metoder för att skapa standby, initdb-parametrar, efterinitieringsskript etc. Den innehåller även timeout-konfiguration, parametrar för att bestämma användningen av PostgreSQL-funktioner som replikeringsplatser , synkront läge etc. Det här avsnittet kommer att skrivas in i ///config för ett givet konfigurationsminne efter initialiseringen av det nya klustret.

    PostgreSQL
    Det här avsnittet innehåller PostgreSQL-specifika parametrar som autentisering, katalogsökvägar för data, binär och konfiguration, lyssna ip-adress etc.

    REST API
    Det här avsnittet inkluderar den Patroni-specifika konfigurationen som är relaterad till REST API:er som lyssnaradress, autentisering, SSL etc.

    Konsul
    Inställningar specifika för Consul DCS.

    Ettcd
    Inställningar som är specifika för Etcd DCS.

    Utställare
    Inställningar specifika för utställare DCS.

    Kubernetes
    Inställningar som är specifika för Kubernetes DCS.

    ZooKeeper
    Inställningar som är specifika för ZooKeeper DCS.

    Watchdog
    Inställningar som är specifika för Watchdog.

Patroni-proffs

  • Patroni möjliggör end-to-end-installation av klustret.
  • Stöder REST API:er och HAproxy-integrering.
  • Stöder händelseaviseringar via återuppringningsskript som utlöses av vissa åtgärder.
  • Utnyttjar DCS för konsensus.

Patroni Cons

  • Patroni kommer inte att upptäcka felkonfigurationen av en standby med en okänd eller obefintlig nod i återställningskonfigurationen. Noden kommer att visas som en slav även om standby-läget körs utan att ansluta till master/cascading standby-noden.
  • Användaren måste hantera installation, hantering och uppgradering av DCS-programvaran.
  • Kräver att flera portar är öppna för komponentkommunikation:
    • REST API-port för Patroni
    • Minst 2 portar för DCS

testscenarier för hög tillgänglighet

Vi genomförde några tester på PostgreSQL HA-hantering med Patroni. Alla dessa tester utfördes medan appen kördes och infogade data i 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 Patroni återförde PostgreSQL-processen till körläge.

  • Det var inga avbrott i skribentapplikationen.
2 Stoppa PostgreSQL-processen Patroni återförde PostgreSQL-processen till körläge.

  • Det var inga avbrott i skribentapplikationen.
3 Starta om servern Patroni måste startas efter omstart, såvida den inte är konfigurerad att inte starta vid omstart. När Patroni väl startades startade den PostgreSQL-processen och ställde in standby-konfigurationen.

  • Det var inga avbrott i skribentapplikationen.
4 Stoppa Patroni-processen
  • Det stoppade inte PostgreSQL-processen.
  • patronictl lista visade inte den här servern.
  • Det var inga avbrott i skribentapplikationen.

Så i grund och botten måste du övervaka hälsan hos Patroni-processen – annars kommer det att leda till problem längre fram.

Tester av master/primär server

Sl. Nej Testscenario Observation
1 Döda PostgreSQL-processen Patroni återförde PostgreSQL-processen till körläge. Patroni som körde på den noden hade primärt lås och så valet utlöstes inte.

  • Det var driftstopp i writer-applikationen.
2 Stoppa PostgreSQL-processen och ta tillbaka den omedelbart efter att hälsokontrollen har gått ut Patroni återförde PostgreSQL-processen till körläge. Patroni som körde på den noden hade primärt lås och så valet utlöstes inte.

  • Det var driftstopp i writer-applikationen.
3 Starta om servern Filover inträffade och en av standbyservrarna valdes till ny master efter att ha erhållit låset. När Patroni startades på den gamla mastern, tog den tillbaka den gamla mastern och utförde pg_rewind och började följa den nya mastern.T

  • Det var driftstopp i writer-applikationen.
4 Stoppa/döda Patroni-processen
  • En av standby-servrarna skaffade DCS-låset och blev mästare genom att marknadsföra sig själv.
  • Den gamla mastern var fortfarande igång och det ledde till ett multimasterscenario. Ansökan skrevs fortfarande till den gamle mästaren.
  • När Patroni startades på den gamla mastern, spolade den tillbaka den gamla mastern (use_pg_rewind sattes till true) till den nya mastertidslinjen och lsn och började följa den nya mastern.

Som du kan se ovan är det mycket viktigt att övervaka hälsan hos Patroni-processen på mästaren. Om du inte gör det kan det leda till ett multimasterscenario och potentiell dataförlust.

Tester för nätverksisolering

Sl. Nej Testscenario Observation
1 Nätverksisolera huvudservern från andra servrar DCS-kommunikation blockerades för huvudnoden.

  • PostgreSQL degraderades på huvudservern.
  • En ny mästare valdes i majoritetspartitionen.
  • Det var ett driftstopp i writer-applikationen.
2 Nätverksisolera standbyservern från andra servrar DCS-kommunikation blockerades för standbynoden.

  • PostgreSQL-tjänsten körde, men noden övervägdes inte för val.
  • Det var inga avbrott i skribentapplikationen.

Vilket är det bästa PostgreSQL HA-ramverket?

Patroni är ett värdefullt verktyg för PostgreSQL-databasadministratörer (DBA), eftersom det utför end-to-end-installation och övervakning av ett PostgreSQL-kluster. Flexibiliteten i att välja DCS och skapa standby är en fördel för slutanvändaren, eftersom de kan välja den metod de är bekväma med.

REST-API:er, HaProxy-integration, Watchdog-support, callbacks och dess funktionsrika hantering gör Patroni till den bästa lösningen för PostgreSQL HA-hantering.

PostgreSQL HA Framework Testing:PAF vs. repmgr vs. Patroni

Inkluderad nedan är en omfattande tabell som visar resultaten av alla tester vi har utfört på alla tre ramverken – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) och Patroni.

Standby-servertest

Testscenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Döda PostgreSQL-processen Pacemaker förde PostgreSQL-processen tillbaka till körläge.

  • Det var inga avbrott i skribentapplikationen.
Standbyservern markerades som misslyckad. Manuell intervention krävdes för att starta PostgreSQL-processen igen.

  • Det var inga avbrott i skribentapplikationen.
Patroni återförde PostgreSQL-processen till körläge.

  • Det var inga avbrott i skribentapplikationen.
Stoppa PostgreSQL-processen Pacemaker förde PostgreSQL-processen tillbaka till körläge.

  • Det var inga avbrott i skribentapplikationen.
Standbyservern markerades som misslyckad. Manuell intervention krävdes för att starta PostgreSQL-processen igen.

  • Det var inga avbrott i skribentapplikationen.
Patroni återförde PostgreSQL-processen till körläge.

  • Det var inga avbrott i skribentapplikationen.
Starta om servern Standbyservern markerades från början som offline. När servern väl kom upp efter omstart startades PostgreSQL av Pacemaker och servern markerades som online. Om stängsel var aktiverat skulle noden inte ha lagts till automatiskt i klustret.

  • Det var inga avbrott i skribentapplikationen.
Standbyservern markerades som misslyckad. När servern kom upp efter omstart startades PostgreSQL manuellt och servern markerades som igång.

  • Det var inga avbrott i skribentapplikationen.
Patroni måste startas efter omstart, såvida den inte är konfigurerad att inte starta vid omstart. När Patroni väl startades startade den PostgreSQL-processen och ställde in standby-konfigurationen.

  • Det var inga avbrott i skribentapplikationen.
Stoppa ramverksagentprocessen Agent:pacemaker

  • PostgreSQL-processen stoppades och markerades offline.
  • Det var inga avbrott i skribentapplikationen.
Ombud:repmgrd

  • Vänteservern kommer inte att ingå i en automatiserad failover-situation.
  • PostgreSQL-tjänsten hittades vara igång.
  • Det var inga avbrott i skribentapplikationen.
Ombud:patroni

  • Det stoppade inte PostgreSQL-processen.
  • patronictl lista visade inte den här servern.
  • Det var inga avbrott i skribentapplikationen.

Tester av master/primär server

Testscenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Döda PostgreSQL-processen Pacemaker förde PostgreSQL-processen tillbaka till körläge. Primär återhämtade sig inom tröskeltiden och därför utlöstes inte valet.

  • Det var driftstopp i writer-applikationen.
repmgrd startade hälsokontroll för primär serveranslutning på alla standbyservrar under ett fast intervall. När alla försök misslyckades utlöstes ett val på alla standbyservrar. Som ett resultat av valet befordrades den standby som senast hade fått LSN. Standbyservrarna som förlorade valet kommer att vänta på meddelandet från den nya huvudnoden och kommer att följa det när de får meddelandet. Manuellt ingripande krävdes för att starta postgreSQL-processen igen.

  • Det var driftstopp i writer-applikationen.
Patroni återförde PostgreSQL-processen till körläge. Patroni som körde på den noden hade primärt lås och därför utlöstes inte valet.

  • Det var driftstopp i writer-applikationen.
Stoppa PostgreSQL-processen och ta tillbaka den omedelbart efter att hälsokontrollen har gått ut Pacemaker förde PostgreSQL-processen tillbaka till körläge. Primär återhämtade sig inom tröskeltiden och därför utlöstes inte valet.

  • Det var driftstopp i writer-applikationen.
repmgrd startade hälsokontroll för primära serveranslutningar 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.

  • Det var driftstopp i writer-applikationen.
Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. Den mest kvalificerade standbyservern marknadsfördes som den nya mastern. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
repmgrd started election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was run to add the server back to the cluster.

  • There was downtime in the writer application.
Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Tester för nätverksisolering

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
All servers have the same value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • The eligible standby was promoted, but the PostgreSQL process was still running on the old master node.
  • Det fanns två noder som körde som master. Manuellt ingripande krävdes efter att nätverksisoleringen korrigerats.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had location different from that of the primary.
  • repmgrd gick in i försämrat övervakningsläge. PostgreSQL kördes på alla noder och det fanns bara en master i klustret.
DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. INFOGA I ... VÄLJ FRÅN ... PÅ DUPLIKATNYCKELUPPDATERING

  2. Hur man inte kallar Hekaton inbyggt kompilerade lagrade procedurer

  3. Hur man avpivoterar en tabell i PostgreSQL

  4. PostgreSQL-strömning vs logisk replikering – jämförelse