sql >> Database >  >> RDS >> PostgreSQL

Hoge beschikbaarheid beheren in PostgreSQL – Deel III:Patroni

In onze vorige blogposts hebben we de mogelijkheden en werking van PostgreSQL Automatic Failover (PAF) door Cluster Labs en Replicatie Manager (repmgr) door 2ndQuadrant besproken. In het laatste bericht van deze serie zullen we de laatste oplossing, Patroni van Zalando, bekijken en alle drie aan het einde vergelijken, zodat u kunt bepalen welk framework met hoge beschikbaarheid het beste is voor uw PostgreSQL-hostingimplementatie.

  • Hoge beschikbaarheid beheren in PostgreSQL – Deel I:automatische PostgreSQL-failover
  • Hoge beschikbaarheid beheren in PostgreSQL – Deel II:Replicatiebeheer

Patroni voor PostgreSQL

Patroni is ontstaan ​​als een fork van Governor, een project van Compose. Het is een open-source toolsuite, geschreven in Python, voor het beheren van hoge beschikbaarheid van PostgreSQL-clusters. In plaats van zijn eigen consistentieprotocol te bouwen, maakt Patroni slim gebruik van het consistentiemodel van een Distributed Configuration Store (DCS). Het ondersteunt ook andere DCS-oplossingen zoals Zookeeper, etcd, Consul en Kubernetes.

Patroni zorgt voor de end-to-end setup van PostgreSQL HA-clusters, inclusief streamingreplicatie. Het ondersteunt verschillende manieren om een ​​standby-knooppunt te maken en werkt als een sjabloon die kan worden aangepast aan uw behoeften.

Deze functie-rijke tool opent de functionaliteit ervan via REST API's en ook via een opdrachtregelhulpprogramma genaamd patronictl. Het ondersteunt integratie met HAProxy door gebruik te maken van de statuscontrole-API's om de taakverdeling af te handelen.

Patroni ondersteunt ook gebeurtenismeldingen met behulp van callbacks, dit zijn scripts die door bepaalde acties worden geactiveerd. Het stelt gebruikers in staat om onderhoudsacties uit te voeren door een pauze-/hervatfunctionaliteit te bieden. De Watchdog-ondersteuningsfunctie maakt het raamwerk nog robuuster.

Hoe het werkt

In eerste instantie moeten de binaire bestanden van PostgreSQL en Patroni worden geïnstalleerd. Zodra dit is gebeurd, moet u ook een HA DCS-configuratie instellen. Alle benodigde configuraties om het cluster te bootstrappen, moeten worden gespecificeerd in het yaml-configuratiebestand en Patroni zal dit bestand gebruiken voor initialisatie. Op de eerste node initialiseert Patroni de database, verkrijgt de leader lock van DCS en zorgt ervoor dat de node als master wordt uitgevoerd.

De volgende stap is het toevoegen van stand-by nodes, waarvoor Patroni meerdere opties biedt. Patroni gebruikt standaard pg_basebackup om het stand-byknooppunt te maken en ondersteunt ook aangepaste methoden zoals WAL-E, pgBackRest, Barman en andere voor het maken van stand-byknooppunten. Patroni maakt het heel eenvoudig om een ​​stand-by-knooppunt toe te voegen en handelt alle bootstrapping-taken en het instellen van uw streaming-replicatie af.

Hoge beschikbaarheid beheren in #PostgreSQL – Deel III:Patroni vs. PAF vs. repmgrKlik om te tweeten

Zodra uw clusterconfiguratie is voltooid, zal Patroni het cluster actief controleren en ervoor zorgen dat het in goede staat verkeert. Het hoofdknooppunt vernieuwt de leidervergrendeling elke ttl seconde(n) (standaard:30 seconden). Wanneer de master-node de leader-lock niet vernieuwt, activeert Patroni een verkiezing, en de node die de leader-lock krijgt, wordt gekozen als de nieuwe master.

Hoe gaat het om met het gespleten brein-scenario?

In een gedistribueerd systeem speelt consensus een belangrijke rol bij het bepalen van consistentie, en Patroni gebruikt DCS om consensus te bereiken. Alleen de node die de leaderlock bevat, kan de master zijn en de leaderlock wordt verkregen via DCS. Als het hoofdknooppunt de leidervergrendeling niet bevat, wordt het onmiddellijk door Patroni gedegradeerd om als stand-by te werken. Op deze manier kan er op elk moment slechts één master in het systeem draaien.

Zijn er installatievereisten?

  • Patroni heeft python 2.7 en hoger nodig.
  • De DCS en zijn specifieke python-module moeten worden geïnstalleerd. Voor testdoeleinden kan DCS worden geïnstalleerd op dezelfde knooppunten waarop PostgreSQL wordt uitgevoerd. In productie moet DCS echter op afzonderlijke knooppunten worden geïnstalleerd.
  • Het yaml-configuratiebestand moet aanwezig zijn met deze configuratie-instellingen op hoog niveau:

    Globaal/universeel
    Dit omvat configuratie zoals de naam van de host (naam) die uniek moet zijn voor het cluster, de naam van het cluster (scope) en pad voor het opslaan van configuratie in DCS (naamruimte).

    Log
    Patroni-specifieke log-instellingen inclusief niveau, formaat, file_num, file_size etc.

    Bootstrap-configuratie
    Dit is de globale configuratie voor een cluster dat naar DCS wordt geschreven. Deze configuratieparameters kunnen worden gewijzigd met behulp van Patroni API's of rechtstreeks in DCS. De bootstrap-configuratie omvat stand-by-creatiemethoden, initdb-parameters, post-initialisatiescript enz. Het bevat ook time-outsconfiguratie, parameters om het gebruik van PostgreSQL-functies zoals replicatieslots te beslissen , synchrone modus enz. Deze sectie wordt geschreven in ///config van een bepaald configuratiearchief na het initialiseren van een nieuw cluster.

    PostgreSQL
    Deze sectie bevat de PostgreSQL-specifieke parameters zoals authenticatie, directorypaden voor gegevens, binair en configuratie, luister-ip-adres enz.

    REST API
    Dit gedeelte bevat de Patroni-specifieke configuratie met betrekking tot REST API's zoals luisteradres, authenticatie, SSL enz.

    Consul
    Instellingen specifiek voor Consul DCS.

    Etcd
    Instellingen specifiek voor Etcd DCS.

    Exposant
    Instellingen specifiek voor exposant DCS.

    Kubernetes
    Instellingen specifiek voor Kubernetes DCS.

    ZooKeeper
    Instellingen specifiek voor ZooKeeper DCS.

    Watchdog
    Instellingen specifiek voor Watchdog.

Patroni Pro's

  • Patroni maakt end-to-end setup van het cluster mogelijk.
  • Ondersteunt REST API's en HAproxy-integratie.
  • Ondersteunt gebeurtenismeldingen via callback-scripts die door bepaalde acties worden geactiveerd.
  • Gebruikt DCS voor consensus.

Patroni nadelen

  • Patroni zal de verkeerde configuratie van een stand-by met een onbekende of niet-bestaande node in de herstelconfiguratie niet detecteren. Het knooppunt wordt weergegeven als een slaaf, zelfs als de stand-by wordt uitgevoerd zonder verbinding te maken met de master/cascadering stand-byknooppunt.
  • De gebruiker moet de installatie, het beheer en de upgrade van de DCS-software afhandelen.
  • Vereist dat meerdere poorten open zijn voor communicatie met componenten:
    • REST API-poort voor Patroni
    • Minimaal 2 poorten voor DCS

Hoge beschikbaarheid testscenario's

We hebben een paar tests uitgevoerd op PostgreSQL HA-beheer met Patroni. Al deze tests zijn uitgevoerd terwijl de applicatie actief was en gegevens werden ingevoegd in de PostgreSQL-database. De applicatie is geschreven met PostgreSQL Java JDBC Driver, waarbij gebruik wordt gemaakt van de mogelijkheid tot failover van de verbinding.

Stand-by servertests

Sl. Nee Testscenario Observatie
1 Dood het PostgreSQL-proces Patroni bracht het PostgreSQL-proces terug naar de actieve status.

  • Er was geen onderbreking van de schrijftoepassing.
2 Stop het PostgreSQL-proces Patroni bracht het PostgreSQL-proces terug naar de actieve status.

  • Er was geen onderbreking van de schrijftoepassing.
3 Herstart de server Patroni moet worden gestart na opnieuw opstarten, tenzij geconfigureerd om niet te starten bij opnieuw opstarten. Nadat Patroni was gestart, startte het het PostgreSQL-proces en stelde het de stand-byconfiguratie in.

  • Er was geen onderbreking van de schrijftoepassing.
4 Stop het Patroni-proces
  • Het stopte het PostgreSQL-proces niet.
  • patronictl-lijst heeft deze server niet weergegeven.
  • Er was geen onderbreking van de schrijftoepassing.

Dus in wezen moet je de gezondheid van het Patroni-proces in de gaten houden, anders leidt dit tot problemen in de loop van de tijd.

Hoofd-/primaire servertests

Sl. Nee Testscenario Observatie
1 Dood het PostgreSQL-proces Patroni bracht het PostgreSQL-proces terug naar de actieve status. Patroni die op dat knooppunt draaide, had een primaire vergrendeling en dus werd de verkiezing niet geactiveerd.

  • Er was een storing in de schrijver-applicatie.
2 Stop het PostgreSQL-proces en breng het onmiddellijk terug nadat de statuscontrole is verlopen Patroni bracht het PostgreSQL-proces terug naar de actieve status. Patroni die op dat knooppunt draaide, had een primaire vergrendeling en dus werd de verkiezing niet geactiveerd.

  • Er was een storing in de schrijver-applicatie.
3 Herstart de server Failover vond plaats en een van de standby-servers werd gekozen als de nieuwe master na het verkrijgen van de vergrendeling. Toen Patroni op de oude master werd gestart, bracht het de oude master terug en voerde pg_rewind uit en begon de nieuwe master te volgen.T

  • Er was een storing in de schrijver-applicatie.
4 Stop/kill het Patroni-proces
  • Een van de standby-servers kreeg het DCS-slot en werd de meester door zichzelf te promoten.
  • De oude master was nog steeds actief en dit leidde tot een scenario met meerdere masters. De applicatie schreef nog steeds naar de oude meester.
  • Zodra Patroni op de oude master was gestart, werd de oude master teruggespoeld (use_pg_rewind was ingesteld op true) naar de nieuwe master-tijdlijn en lsn en begon de nieuwe master te volgen.

Zoals je hierboven kunt zien, is het erg belangrijk om de gezondheid van het Patroni-proces op de master te bewaken. Als u dit niet doet, kan dit leiden tot een scenario met meerdere masters en mogelijk gegevensverlies.

Netwerkisolatietests

Sl. Nee Testscenario Observatie
1 Netwerk-isoleer de masterserver van andere servers DCS-communicatie is geblokkeerd voor hoofdknooppunt.

  • PostgreSQL is gedegradeerd op de hoofdserver.
  • Er is een nieuwe meester gekozen in de meerderheidspartitie.
  • Er was een storing in de schrijver-applicatie.
2 Netwerk-isoleer de standby-server van andere servers DCS-communicatie is geblokkeerd voor het standby-knooppunt.

  • De PostgreSQL-service was actief, maar het knooppunt kwam niet in aanmerking voor verkiezingen.
  • Er was geen onderbreking in de schrijftoepassing.

Wat is het beste PostgreSQL HA-framework?

Patroni is een waardevol hulpmiddel voor PostgreSQL-databasebeheerders (DBA's), omdat het de end-to-end setup en monitoring van een PostgreSQL-cluster uitvoert. De flexibiliteit bij het kiezen van DCS en het maken van stand-by is een voordeel voor de eindgebruiker, omdat ze de methode kunnen kiezen waar ze zich prettig bij voelen.

REST API's, HaProxy-integratie, Watchdog-ondersteuning, callbacks en het uitgebreide beheer ervan maken Patroni de beste oplossing voor PostgreSQL HA-beheer.

PostgreSQL HA Framework-testen:PAF vs. repmgr vs. Patroni

Hieronder vindt u een uitgebreide tabel met de resultaten van alle tests die we hebben uitgevoerd op alle drie de frameworks:PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) en Patroni.

Stand-by servertests

Testscenario PostgreSQL Automatic Failover (PAF) Replicatiebeheer (repmgr) Patroni
Dood het PostgreSQL-proces Pacemaker bracht het PostgreSQL-proces terug naar de actieve status.

  • Er was geen onderbreking van de schrijftoepassing.
 Standby-server is gemarkeerd als mislukt. Handmatige tussenkomst was vereist om het PostgreSQL-proces opnieuw te starten.

  • Er was geen onderbreking van de schrijftoepassing.
 Patroni bracht het PostgreSQL-proces terug naar de actieve staat.

  • Er was geen onderbreking van de schrijftoepassing.
Stop het PostgreSQL-proces Pacemaker bracht het PostgreSQL-proces terug naar de actieve status.

  • Er was geen onderbreking van de schrijftoepassing.
 Standby-server is gemarkeerd als mislukt. Handmatige tussenkomst was vereist om het PostgreSQL-proces opnieuw te starten.

  • Er was geen onderbreking van de schrijftoepassing.
 Patroni bracht het PostgreSQL-proces terug naar de actieve staat.

  • Er was geen onderbreking van de schrijftoepassing.
Start de server opnieuw op Standby-server was aanvankelijk als offline gemarkeerd. Nadat de server was opgestart na het opnieuw opstarten, werd PostgreSQL gestart door Pacemaker en werd de server gemarkeerd als online. Als omheining was ingeschakeld, zou het knooppunt niet automatisch aan het cluster zijn toegevoegd.

  • Er was geen onderbreking van de schrijftoepassing.
 Standby-server is gemarkeerd als mislukt. Nadat de server na het opnieuw opstarten was opgestart, werd PostgreSQL handmatig gestart en werd de server gemarkeerd als actief.

  • Er was geen onderbreking van de schrijftoepassing.
 Patroni moet worden gestart na opnieuw opstarten, tenzij geconfigureerd om niet te starten bij opnieuw opstarten. Nadat Patroni was gestart, startte het het PostgreSQL-proces en stelde het de stand-byconfiguratie in.

  • Er was geen onderbreking van de schrijftoepassing.
Stop het framework-agentproces Agent:pacemaker

  • Het PostgreSQL-proces is gestopt en als offline gemarkeerd.
  • Er was geen onderbreking van de schrijftoepassing.
 Agent:repmgrd

  • De standby-server maakt geen deel uit van een geautomatiseerde failover-situatie.
  • Er is vastgesteld dat de PostgreSQL-service actief is.
  • Er was geen onderbreking van de schrijftoepassing.
 Agent:patroni

  • Het stopte het PostgreSQL-proces niet.
  • patronictl-lijst heeft deze server niet weergegeven.
  • Er was geen onderbreking van de schrijftoepassing.

Hoofd-/primaire servertests

Testscenario PostgreSQL Automatic Failover (PAF) Replicatiebeheer (repmgr) Patroni
Dood het PostgreSQL-proces Pacemaker bracht het PostgreSQL-proces terug naar de actieve status. Primair werd binnen de drempeltijd hersteld en daarom werd de verkiezing niet geactiveerd.

  • Er was een storing in de schrijver-applicatie.
 repmgrd startte een statuscontrole voor de primaire serververbinding op alle standby-servers voor een vast interval. Toen alle nieuwe pogingen mislukten, werd een verkiezing geactiveerd op alle standby-servers. Als resultaat van de verkiezing werd de stand-by die de laatst ontvangen LSN had, gepromoveerd. De standby-servers die de verkiezing hebben verloren, wachten op de melding van het nieuwe hoofdknooppunt en zullen deze volgen zodra ze de melding hebben ontvangen. Handmatige tussenkomst was vereist om het postgreSQL-proces opnieuw te starten.

  • Er was een storing in de schrijver-applicatie.
 Patroni bracht het PostgreSQL-proces terug naar de actieve status. Patroni die op dat knooppunt draaide, had een primaire vergrendeling en daarom werd de verkiezing niet geactiveerd.

  • Er was een storing in de schrijver-applicatie.
Stop het PostgreSQL-proces en breng het onmiddellijk terug nadat de statuscontrole is verlopen Pacemaker bracht het PostgreSQL-proces terug naar de actieve status. 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. De meest geschikte standby-server werd gepromoot als de nieuwe 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.

Netwerkisolatietests

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. Meerdere rijen invoegen in Oracle

  2. FILEGROUPPROPERTY() gebruiken in SQL Server

  3. SQL Server 2016:altijd versleuteld

  4. Problemen met CPU-prestaties op VMware oplossen