sql >> Database teknologi >  >> RDS >> PostgreSQL

Administration af høj tilgængelighed i PostgreSQL – del III:Patroni

I vores tidligere blogindlæg diskuterede vi mulighederne og funktionen af ​​PostgreSQL Automatic Failover (PAF) af Cluster Labs og Replication Manager (repmgr) af 2ndQuadrant. I det sidste indlæg i denne serie vil vi gennemgå den sidste løsning, Patroni af Zalando, og sammenligne alle tre i slutningen, så du kan bestemme, hvilken ramme med høj tilgængelighed, der er bedst til din PostgreSQL-hostingimplementering.

  • Administration af høj tilgængelighed i PostgreSQL – Del I:PostgreSQL Automatic Failover
  • Styring af høj tilgængelighed i PostgreSQL – Del II:Replication Manager

Patroni til PostgreSQL

Patroni opstod som en fork af Governor, et projekt fra Compose. Det er en open source-værktøjspakke, skrevet i Python, til styring af høj tilgængelighed af PostgreSQL-klynger. I stedet for at bygge sin egen konsistensprotokol, udnytter Patroni på en smart måde konsistensmodellen leveret af en distribueret konfigurationsbutik (DCS). Det understøtter også andre DCS-løsninger som Zookeeper, etcd, Consul og Kubernetes.

Patroni sikrer ende-til-ende-opsætningen af ​​PostgreSQL HA-klynger, inklusive streaming-replikering. Den understøtter forskellige måder at oprette en standby-knude på og fungerer som en skabelon, der kan tilpasses til dine behov.

Dette funktionsrige værktøj afslører dets funktionalitet via REST API'er og også via et kommandolinjeværktøj kaldet patronictl. Det understøtter integration med HAProxy ved at bruge dets sundhedstjek API'er til at håndtere belastningsbalancering.

Patroni understøtter også hændelsesnotifikationer ved hjælp af tilbagekald, som er scripts udløst af bestemte handlinger. Det gør det muligt for brugere at udføre enhver vedligeholdelseshandling ved at tilbyde pause/genoptag-funktionalitet. Watchdog-supportfunktionen gør rammen endnu mere robust.

Sådan virker det

I første omgang skal PostgreSQL og Patroni binære filer installeres. Når dette er gjort, skal du også opsætte en HA DCS-konfiguration. Alle de nødvendige konfigurationer for at bootstrap klyngen skal angives i yaml-konfigurationsfilen, og Patroni vil bruge denne fil til initialisering. På den første node initialiserer Patroni databasen, henter lederlåsen fra DCS og sikrer, at noden køres som master.

Næste trin er at tilføje standby noder, som Patroni giver flere muligheder for. Som standard bruger Patroni pg_basebackup til at oprette standby-knuden, og understøtter også brugerdefinerede metoder som WAL-E, pgBackRest, Barman og andre til oprettelse af standby-noden. Patroni gør det meget enkelt at tilføje en standby-node og håndterer alle bootstrapping-opgaver og opsætning af din streaming-replikering.

Håndtering af høj tilgængelighed i #PostgreSQL – Del III:Patroni vs. PAF vs. repmgrKlik for at tweete

Når din klyngeopsætning er fuldført, vil Patroni aktivt overvåge klyngen og sikre, at den er i en sund tilstand. Masternoden fornyer lederlåsen hvert ttl sekund(er) (standard:30 sekunder). Når masternoden ikke fornyer lederlåsen, udløser Patroni et valg, og den node, som vil opnå lederlåsen, vil blive valgt som ny master.

Hvordan håndterer den split-hjerne-scenariet?

I et distribueret system spiller konsensus en vigtig rolle i at bestemme konsistens, og Patroni bruger DCS til at opnå konsensus. Kun den node, der holder lederlåsen, kan være master, og lederlåsen opnås via DCS. Hvis masterknuden ikke holder lederlåsen, vil den straks blive degraderet af Patroni til at køre som standby. På denne måde kan der på et hvilket som helst tidspunkt kun køre én master i systemet.

Er der nogen opsætningskrav?

  • Patroni har brug for python 2.7 og nyere.
  • DCS og dets specifikke python-modul skal installeres. Til testformål kan DCS installeres på samme noder, der kører PostgreSQL. I produktionen skal DCS dog installeres på separate noder.
  • Yaml-konfigurationsfilen skal være til stede ved at bruge disse højniveaukonfigurationsindstillinger:

    Global/Universal
    Dette inkluderer konfiguration såsom navnet på værten (navnet), som skal være unikt for klyngen, navnet på klyngen (omfang) og stien til lagring af konfiguration i DCS (navneområde).

    Log
    Patroni-specifikke logindstillinger, herunder niveau, format, file_num, file_size osv.

    Bootstrap-konfiguration
    Dette er den globale konfiguration for en klynge, der vil blive skrevet til DCS. Disse konfigurationsparametre kan ændres ved hjælp af Patroni API'er eller direkte i DCS. Bootstrap-konfigurationen inkluderer standby-oprettelsesmetoder, initdb-parametre, post-initialiseringsscript osv. Den indeholder også timeout-konfiguration, parametre til at bestemme brugen af ​​PostgreSQL-funktioner såsom replikeringsslots , synkron tilstand osv. Denne sektion vil blive skrevet ind i ///config af et givet konfigurationslager efter initialiseringen af ​​den nye klynge.

    PostgreSQL
    Denne sektion indeholder de PostgreSQL-specifikke parametre som autentificering, biblioteksstier til data, binær og konfiguration, lytte-ip-adresse osv.

    REST API
    Dette afsnit inkluderer den Patroni-specifikke konfiguration relateret til REST API'er såsom lytteadresse, godkendelse, SSL osv.

    Konsul
    Indstillinger, der er specifikke for Consul DCS.

    Osv
    Indstillinger, der er specifikke for Etcd DCS.

    Udstiller
    Indstillinger, der er specifikke for udstiller DCS.

    Kubernetes
    Indstillinger, der er specifikke for Kubernetes DCS.

    ZooKeeper
    Indstillinger, der er specifikke for ZooKeeper DCS.

    Watchdog
    Indstillinger, der er specifikke for Watchdog.

Patroni Pros

  • Patroni muliggør ende-til-ende-opsætning af klyngen.
  • Understøtter REST API'er og HAproxy-integration.
  • Understøtter hændelsesnotifikationer via callbacks-scripts udløst af visse handlinger.
  • Udnytter DCS til konsensus.

Patroni Cons

  • Patroni vil ikke opdage fejlkonfigurationen af ​​en standby med en ukendt eller ikke-eksisterende node i gendannelseskonfigurationen. Noden vil blive vist som en slave, selvom standbyen kører uden at oprette forbindelse til master/cascading standby noden.
  • Brugeren skal håndtere opsætning, administration og opgradering af DCS-softwaren.
  • Kræver, at flere porte er åbne for komponentkommunikation:
    • REST API-port til Patroni
    • Minimum 2 porte til DCS

testscenarier for høj tilgængelighed

Vi udførte et par test af PostgreSQL HA-administration ved hjælp af Patroni. Alle disse test blev udfø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 Patroni bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
2 Stop PostgreSQL-processen Patroni bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
3 Genstart serveren Patroni skal startes efter genstart, medmindre den er konfigureret til ikke at starte ved genstart. Når Patroni var startet, startede den PostgreSQL-processen og konfigurerede standby-konfigurationen.

  • Der var ingen afbrydelse af forfatterapplikationen.
4 Stop Patroni-processen
  • Det stoppede ikke PostgreSQL-processen.
  • patronictl liste viste ikke denne server.
  • Der var ingen afbrydelse af forfatterapplikationen.

Så i det væsentlige skal du overvåge Patroni-processens helbred – ellers vil det føre til problemer senere hen.

Master/Primær servertest

Sl. Nej Testscenarie Observation
1 Dræb PostgreSQL-processen Patroni bragte PostgreSQL-processen tilbage til kørende tilstand. Patroni, der kørte på den node, havde primær lås, så valget blev ikke udløst.

  • Der var nedetid i writer-applikationen.
2 Stop PostgreSQL-processen og bring den tilbage umiddelbart efter udløb af sundhedstjekket Patroni bragte PostgreSQL-processen tilbage til kørende tilstand. Patroni, der kørte på den node, havde primær lås, så valget blev ikke udløst.

  • Der var nedetid i writer-applikationen.
3 Genstart serveren Failover skete, og en af ​​standby-serverne blev valgt som den nye master efter at have opnået låsen. Da Patroni blev startet på den gamle master, bragte den den gamle master op igen og udførte pg_rewind og begyndte at følge den nye master.T

  • Der var nedetid i writer-applikationen.
4 Stop/dræb Patroni-processen
  • En af standby-serverne erhvervede DCS-låsen og blev master ved at promovere sig selv.
  • Den gamle master kørte stadig, og det førte til multi-master-scenarie. Ansøgningen skrev stadig til den gamle mester.
  • Når Patroni blev startet på den gamle master, spole den gamle master tilbage (use_pg_rewind blev sat til sand) til den nye master-tidslinje og lsn og begyndte at følge den nye master.

Som du kan se ovenfor, er det meget vigtigt at overvåge sundheden for Patroni-processen på mesteren. Hvis du ikke gør det, kan det føre til et multi-master-scenarie og potentielt datatab.

Netværksisolationstest

Sl. Nej Testscenarie Observation
1 Netværksisoler masterserveren fra andre servere DCS-kommunikation blev blokeret for masterknudepunktet.

  • PostgreSQL blev degraderet på masterserveren.
  • Der blev valgt en ny mester i flertalsdelingen.
  • Der var en nedetid i forfatterapplikationen.
2 Netværksisoler standby-serveren fra andre servere DCS-kommunikation blev blokeret for standby-knuden.

  • PostgreSQL-tjenesten kørte, men noden kom ikke i betragtning til valg.
  • Der var ingen afbrydelse i forfatterapplikationen.

Hvad er det bedste PostgreSQL HA Framework?

Patroni er et værdifuldt værktøj for PostgreSQL-databaseadministratorer (DBA'er), da det udfører ende-til-ende opsætning og overvågning af en PostgreSQL-klynge. Fleksibiliteten ved at vælge DCS og standby-oprettelse er en fordel for slutbrugeren, da de kan vælge den metode, de er komfortable med.

REST API'er, HaProxy-integration, Watchdog-support, tilbagekald og dets funktionsrige administration gør Patroni til den bedste løsning til PostgreSQL HA-administration.

PostgreSQL HA-rammetest:PAF vs. repmgr vs. Patroni

Inkluderet nedenfor er en omfattende tabel, der beskriver resultaterne af alle de test, vi har udført på alle tre frameworks – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) og Patroni.

Standby-servertests

Testscenarie PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Dræb PostgreSQL-processen Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
 Standbyserver blev markeret som mislykket. Manuel indgriben var påkrævet for at starte PostgreSQL-processen igen.

  • Der var ingen afbrydelse af forfatterapplikationen.
 Patroni bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
Stop PostgreSQL-processen Pacemaker bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
 Standbyserver blev markeret som mislykket. Manuel indgriben var påkrævet for at starte PostgreSQL-processen igen.

  • Der var ingen afbrydelse af forfatterapplikationen.
 Patroni bragte PostgreSQL-processen tilbage til kørende tilstand.

  • Der var ingen afbrydelse af forfatterapplikationen.
Genstart serveren Standbyserveren blev oprindeligt markeret som offline. Når serveren kom op efter genstart, blev PostgreSQL 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 afbrydelse af forfatterapplikationen.
 Standbyserver blev markeret som mislykket. Når serveren kom op efter genstart, blev PostgreSQL startet manuelt, og serveren blev markeret som kørende.

  • Der var ingen afbrydelse af forfatterapplikationen.
 Patroni skal startes efter genstart, medmindre den er konfigureret til ikke at starte ved genstart. Når Patroni var startet, startede den PostgreSQL-processen og konfigurerede standby-konfigurationen.

  • Der var ingen afbrydelse af forfatterapplikationen.
Stop rammeagentprocessen Agent:pacemaker

  • PostgreSQL-processen blev stoppet og blev markeret som offline.
  • Der var ingen afbrydelse af forfatterapplikationen.
 Agent:repmgrd

  • Standbyserveren vil ikke være en del af en automatisk failover-situation.
  • PostgreSQL-tjenesten blev fundet at køre.
  • Der var ingen afbrydelse af forfatterapplikationen.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Master/Primary Server Tests

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 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.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back.Cluster was left in an indeterminate state and manual intervention was required.

  • There was downtime in the writer application.
 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. The most eligible standby server was promoted as the new master. 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.

Network Isolation Tests

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.
  • There were two nodes running as master. Manual intervention was required after the network isolation was corrected.

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 went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.
 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. Hvordan bruger man en fremmednøgle i sqlite?

  2. Brug OBJECT_NAME() til at hente et objekts navn fra dets object_id i SQL Server

  3. Postgres dump af kun dele af tabeller til et dev-øjebliksbillede

  4. SQL, Unikke og Primære nøgler