sql >> Database >  >> RDS >> PostgreSQL

Hoge beschikbaarheid beheren in PostgreSQL – Part II:Replication Manager

Implementeert u PostgreSQL in de cloud en wilt u inzicht krijgen in uw opties voor het bereiken van hoge beschikbaarheid? In onze vorige blogpost, Managen van hoge beschikbaarheid in PostgreSQL – deel I, hebben we de mogelijkheden en werking van PostgreSQL Automatic Failover (PAF) door ClusterLabs besproken. In deel II laten we u kennismaken met een alternatieve open source-tool, Replication Manager van 2ndQuadrant, die op de voet wordt gevolgd door Deel III, waar we ingaan op ons derde alternatief, Patroni van Zalando.

  • Hoge beschikbaarheid beheren in PostgreSQL – Deel I:automatische PostgreSQL-failover
  • Hoge beschikbaarheid beheren in PostgreSQL – Deel III:Patroni

Replicatiebeheer (repmgr)

repmgr is een open-source toolsuite ontwikkeld door 2ndQuadrant voor het beheren van replicatie en failover van uw PostgreSQL-clusters. Het biedt de tools voor het instellen, configureren, beheren en bewaken van de replicatie van PostgreSQL, en stelt u ook in staat om handmatige omschakelings- en failover-taken uit te voeren met het hulpprogramma repmgr. Deze gratis tool ondersteunt en verbetert de ingebouwde streamingreplicatie van PostgreSQL.

Replicatiebeheer biedt twee hoofdtools om replicatie en failover van PostgreSQL te beheren.

repmgr

  • Een opdrachtregelinterface-hulpprogramma waarmee u verschillende beheertaken kunt uitvoeren.
  • repmgr stelt u in staat om stand-by-servers in te stellen, stand-by te promoten, een omschakeling uit te voeren en de status van uw PostgreSQL-cluster te controleren.
  • Het biedt ook een optie voor een droge uitvoering van bijna alle administratieve commando's.

repmgrd

Dit is de daemon die:

  • Bewaakt actief de PostgreSQL-clusters en voert de nodige acties uit op basis van de status van het cluster.
  • Voert automatische failover uit voor het geval het primaire knooppunt uitvalt door de meest geschikte stand-by als de nieuwe primaire te promoten.
  • Biedt een optie om de gegevens met betrekking tot replicatieprestaties te controleren en op te slaan.
  • Biedt een melding door de gebruikersscripts op te roepen voor geregistreerde gebeurtenissen.

Hoe het werkt

repmrg beheert niet alleen de replicatie van PostgreSQL-clusters, maar heeft ook mogelijkheden voor het instellen van de standby-servers voor replicatie. Na de eerste installatie moeten we op elke server wijzigingen aanbrengen in het repmgr-configuratiebestand (repmgr.conf) met de vereiste details. Wanneer een server is geconfigureerd, moet deze worden geregistreerd bij repmgr met de opdracht repmgr primary/standby register. Eerst wordt het primaire knooppunt ingesteld en geregistreerd. Vervolgens worden standby-servers gemaakt en geconfigureerd met behulp van de opdracht repmgr standby clone, waarmee het standby-knooppunt van PostgreSQL wordt gekloond van een andere PostgreSQL-server.

Replication Manager maakt gebruik van de functie PostgreSQL-extensies en creëert zijn eigen schema op de clusterdatabase om de clustergerelateerde informatie op te slaan. Installatie van de extensie en creatie van het schema gebeurt tijdens de registratie van de primaire server met behulp van repmgr. Zodra de installatie is voltooid, kunnen handmatige administratieve handelingen zoals promoten, volgen, omschakelen, enz. worden gedaan met het hulpprogramma repmgr. Voor omschakeling is het vereist dat SSH zonder wachtwoord wordt ingesteld tussen de knooppunten.

Automatische failover kan worden ingesteld met repmgrd. repmgrd vereist dat een gedeelde bibliotheek 'repmgr' wordt geladen op het moment dat de PostgreSQL-server wordt gestart. De naam van de bibliotheek moet worden vermeld in de shared_preload_libraries configuratieparameter in het bestand postgresql.conf. Om repmgrd te laten werken, failover=automatic parameter moet worden ingesteld in het bestand repmgr.conf. Zodra al deze parameters zijn ingesteld, begint de repmgrd-daemon het cluster actief te bewaken. Als er een storing is in het primaire knooppunt, zal het meerdere keren proberen opnieuw verbinding te maken. Wanneer alle pogingen om verbinding te maken met de primaire verbinding mislukken, wordt de meest geschikte stand-by gekozen door verkiezing als de nieuwe primaire door repmgrd.

repmgr ondersteunt ook gebeurtenismeldingen. Het heeft een reeks vooraf gedefinieerde gebeurtenissen en slaat elk optreden van deze gebeurtenissen op in de tabel repmgr.events. Met repmgr kunnen gebeurtenismeldingen worden doorgegeven aan een door de gebruiker gedefinieerd programma of script dat verdere actie kan ondernemen, zoals het verzenden van een e-mail of het activeren van een waarschuwing. Dit wordt gedaan door het event_notification_command . in te stellen parameter in repmgr.conf.

Hoe gaat het om met het gespleten brein-scenario?

repmgr pakt scenario's met gespleten hersens aan met behulp van de locatie parameter, waarbij elk knooppunt de locatieparameter moet specificeren op basis van het datacenter waarin het is geplaatst. In het geval van een netwerksplitsing, zorgt repmgr voor de promotie van het knooppunt dat zich op dezelfde locatie als het primaire knooppunt bevindt. Als het geen knooppunt op die locatie vindt, zal het op geen enkele locatie een knooppunt promoten.

Het zorgt ook voor netwerkisolatie in het geval van een even aantal servers in een cluster. Dit wordt gedaan met behulp van een extra knooppunt genaamd de getuige-server. De getuige-server is een knooppunt dat alleen in aanmerking wordt genomen voor het tellen van de meerderheid van stemmen. Er zal geen PostgreSQL-installatie op die server zijn, en dus geen rol bij replicatie.

Zijn er installatievereisten?

  • repmgr vereist een speciale database en een gebruiker met superuser-privileges. Er is echter ook een optie om een ​​superuser op te geven als u niet bereid bent de superuser toegang te geven tot de repmgr-gebruiker.
  • Als u wilt dat repmgr configuratiebestanden kopieert die zich buiten de PostgreSQL-gegevensdirectory bevinden, en/of omschakelfunctionaliteit te testen, hebt u ook wachtwoordloze SSH-verbindingen tussen beide servers nodig, en rsync moet worden geïnstalleerd.
  • Als je van plan bent om andere op service gebaseerde commando's te gebruiken dan pg_ctl (die standaard door repmgr wordt gebruikt) om te starten, stoppen, herladen en herstarten, kun je deze specificeren in repmgr configuratiebestand (repmgr.conf).
  • De basisconfiguratieparameters die vereist zijn in het repmgr-configuratiebestand zijn als volgt:
    node_id (int) – Een uniek geheel getal groter dan nul dat het knooppunt identificeert.node_name (string) – Een willekeurige (maar unieke) string, die de hostnaam van de server of een andere identifier gebruikt die ondubbelzinnig aan de server is gekoppeld, wordt aanbevolen om verwarring te voorkomen.

    conninfo (tekenreeks) – Gegevens over de databaseverbinding als een conninfo-string. Alle servers in het cluster moeten met deze string verbinding kunnen maken met het lokale knooppunt.

    data_directory (tekenreeks) – De datadirectory van het knooppunt. Dit is nodig voor repmgr om bewerkingen uit te voeren wanneer de PostgreSQL-instantie niet actief is en er geen andere manier is om de gegevensmap te bepalen.

repmgr Voordelen

  • Repmgr biedt hulpprogramma's die helpen bij het instellen van primaire en stand-by-knooppunten en het configureren van replicatie.
  • Het gebruikt geen extra poorten voor communicatie. Als u een omschakeling wilt uitvoeren, moet u alleen dan wachtwoordloze SSH configureren.
  • Biedt een melding door de gebruikersscripts voor de geregistreerde gebeurtenissen op te roepen.
  • Voert automatische failover uit in het geval van een storing van de primaire server.

repmgr nadelen

  • repmgr detecteert niet of de stand-by verkeerd is geconfigureerd met een onbekende of niet-bestaande node in de herstelconfiguratie. Het knooppunt wordt weergegeven als stand-by, zelfs als het actief is zonder verbinding te maken met het primaire/trapsgewijze stand-byknooppunt.
  • Kan de status van een ander knooppunt niet ophalen van een knooppunt waar de PostgreSQL-service niet beschikbaar is. Daarom biedt het geen gedistribueerde controle-oplossing.
  • Het kan de gezondheid van individuele nodes niet herstellen.

Hoge beschikbaarheid beheren in #PostgreSQL – Deel II:Open Source repmgr Tool Klik om te tweeten

Hoge beschikbaarheid testscenario's

We hebben een paar tests uitgevoerd op PostgreSQL-beheer met hoge beschikbaarheid met behulp van repmgr. Al deze tests werden 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 Standby-server is gemarkeerd als mislukt. Er was geen onderbreking in de schrijverstoepassing. Handmatige tussenkomst was vereist om het PostgreSQL-proces opnieuw te starten.
2 Stop het PostgreSQL-proces Standby-server is gemarkeerd als mislukt. Er was geen onderbreking in de schrijverstoepassing. Handmatige tussenkomst was vereist om het PostgreSQL-proces opnieuw te starten.
3 Herstart de server Standby-server is gemarkeerd als mislukt. Nadat de server was opgestart na opnieuw opstarten, werd PostgreSQL handmatig gestart en werd de server gemarkeerd als actief. Er was geen onderbreking in de schrijverstoepassing.
4 Stop het repmgrd-proces De standby-server maakt geen deel uit van de geautomatiseerde failover-situatie. Er is vastgesteld dat de PostgreSQL-service actief is. Er was geen onderbreking in de schrijverstoepassing.

Hoofd-/primaire servertests

Sl. Nee Testscenario Observatie
1 Dood het PostgreSQL-proces
  • repmgrd startte de statuscontrole voor de primaire serververbinding op alle standby-servers voor een vast interval.
  • Toen alle nieuwe pogingen mislukten, werd er een verkiezing geactiveerd op alle standby-servers. Als resultaat van de verkiezing werd de stand-by met de laatst ontvangen LSN gepromoveerd.
  • De standby-servers die de verkiezing hebben verloren, wachten op de melding van het nieuwe hoofdknooppunt en volgen deze zodra ze de melding hebben ontvangen.
  • Er was een storing in de schrijver-applicatie. Handmatige tussenkomst was vereist om het PostgreSQL-proces opnieuw te starten.
2 Stop het PostgreSQL-proces en breng het onmiddellijk terug nadat de statuscontrole is verlopen
  • repmgrd startte de 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-knooppunten.
  • De nieuw gekozen master heeft de bestaande standby-servers echter niet op de hoogte gebracht sinds de oude master terug was.
  • Cluster bleef in een onbepaalde staat en handmatig ingrijpen was vereist.
3 Herstart de server
  • repmgrd startte de verkiezing toen de statuscontrole van de hoofdverbinding op alle standby-servers mislukte.
  • De in aanmerking komende stand-by is gepromoot. Toen deze server terugkwam, nam deze geen deel aan het cluster en werd hij gemarkeerd als mislukt.
  • repmgr node rejoin-opdracht is uitgevoerd om de server weer aan het cluster toe te voegen. Er was een storing in de schrijver-applicatie.
4 Stop het repmgr-proces
  • De primaire server maakt geen deel uit van de geautomatiseerde failover-situatie.
  • Er is vastgesteld dat de PostgreSQL-service actief is. Er was geen onderbreking in de schrijverstoepassing.

Netwerkisolatietests

Sl. Nee Testscenario Observatie
1 Het netwerk isoleert de primaire server van andere servers (allemaal dezelfde waarde voor de locatie in de repmgr-configuratie)
  • repmgrd startte de verkiezing toen de statuscontrole van de hoofdverbinding op alle standby-servers mislukte.
  • De in aanmerking komende stand-by is gepromoveerd, maar het PostgreSQL-proces werd nog steeds uitgevoerd op het oude hoofdknooppunt.
  • Er waren twee knooppunten actief als master. Handmatige interventie was vereist nadat de netwerkisolatie was gecorrigeerd.
2 Het netwerk isoleert de primaire server van andere servers (de standby-servers hebben dezelfde waarde voor locatie, maar de primaire server had een andere waarde voor locatie in de repmgr-configuratie)
  • repmgrd startte de verkiezing toen de statuscontrole van de hoofdverbinding op alle standby-servers mislukte.
  • Maar er is geen nieuwe master gekozen omdat de standby-servers een andere locatie hadden dan de primaire.
  • repmgrd ging in degradatiebewakingsmodus. PostgreSQL draaide op alle nodes en er was maar één master in het cluster.

Gevolgtrekking

repmgr biedt verschillende opdrachten om PostgreSQL-replicatie in te stellen en te controleren. Het is rijk aan functies en verlicht ook het werk van de databasebeheerder (DBA). Het is echter geen volwaardige beheertool voor hoge beschikbaarheid, omdat de resources niet worden beheerd. Handmatig ingrijpen is vereist om ervoor te zorgen dat de bron in goede staat verkeert.

Dus in dit bericht hebben we de mogelijkheden en werking van Replication Manager by 2ndQuadrant besproken. In ons volgende bericht zullen we dezelfde hoge beschikbaarheidsaspecten bespreken met Patroni van Zalando. Voor gebruikers die hun hoge beschikbaarheid in de cloud willen automatiseren, bekijk onze PostgreSQL op Azure en PostgreSQL op AWS volledig beheerde oplossingen.


  1. Meerdere PostgreSQL-schema's gebruiken met Rails-modellen

  2. Selecteer laatste rij in MySQL

  3. Hoe het aantal bits in een string in MySQL te krijgen - BIT_LENGTH()

  4. Converteer een stringdatum naar datetime in Oracle