Hoge beschikbaarheid van PostgreSQL beheren – Deel I:Automatische PostgreSQL-failover

Het beheren van hoge beschikbaarheid (HA) in uw PostgreSQL-hosting is een zeer belangrijk onderwerp om ervoor te zorgen dat uw database-implementatieclusters uitzonderlijke uptime en sterke operationele prestaties behouden, zodat uw gegevens altijd beschikbaar zijn voor uw app. In een eerdere blogpost hebben we u kennis laten maken met het configureren van hoge beschikbaarheid voor PostgreSQL met behulp van streamingreplicatie, en nu gaan we u laten zien hoe u de hoge beschikbaarheid aan de clientzijde het beste kunt beheren.

Er zijn meerdere tools beschikbaar voor het beheren van de hoge beschikbaarheid (HA) van uw PostgreSQL-implementatieclusters met behulp van streamingreplicatie. Deze oplossingen bieden automatische failover-mogelijkheden, bewaken beschikbaarheid en systeemstatus, replicatie, gebruikersbeheer en andere nuttige administratieve taken op use-cases voor Postgres-databases. Enkele van de prominente open source-oplossingen zijn:

1. PostgreSQL automatische failover door ClusterLabs

2. Replicatiebeheer voor PostgreSQL-clusters door repmgr (2ndQuadrant)

3. Patroni door Zalando

Elke tool biedt zijn eigen manier om de PostgreSQL-clusters met hoge beschikbaarheid te beheren. In onze driedelige serie berichten over HA voor PostgreSQL delen we een overzicht, de vereisten en de werk- en testresultaten voor elk van deze drie tools. Hier in deel 1 gaan we dieper in op de PAF-oplossing van ClusterLabs.

• Hoge beschikbaarheid beheren in PostgreSQL – Deel II:Replicatiebeheer
• Hoge beschikbaarheid beheren in PostgreSQL – Deel III:Patroni

Hoe beheert u hoge beschikbaarheid voor uw PostgreSQL-database?

PostgreSQL Automatic Failover (PAF) is een beheeroplossing met hoge beschikbaarheid voor PostgreSQL van ClusterLabs. Het maakt gebruik van Postgres synchrone replicatie om te garanderen dat er geen gegevens verloren gaan op het moment van de failover-bewerking. Het maakt gebruik van de populaire, industriestandaard Pacemaker en Corosync-stack. Met Pacemaker- en Corosync-applicaties samen kunt u PostgreSQL-databasefouten in het systeem detecteren en dienovereenkomstig handelen.

Pacemaker is een service die veel bronnen kan beheren, en dit met de hulp van hun bronagenten. Hulpbronagenten hebben dan de verantwoordelijkheid om met een specifieke hulpbron om te gaan, hoe ze zich moeten gedragen en Pacemaker op de hoogte stellen van hun resultaten.

De implementatie van uw resource agent moet voldoen aan de Open Cluster Framework (OCF)-specificatie. Deze specificatie definieert het gedrag van resource agents en de implementatie van methoden zoals stoppen, starten, promoten, degraderen en interactie met Pacemaker.

PAF is een OCF-hulpbronagent voor Postgres, geschreven in Perl. Zodra uw databasecluster is gebouwd met behulp van interne streamingreplicatie, kan PAF aan Pacemaker de huidige status van de PostgreSQL-instantie op elk van de knooppunten van de databases tonen:master, slave, gestopt, inhalen, load balancer enz.

Hoe de automatische failover van Postgres werkt

PAF communiceert met Pacemaker over de clusterstatus en controleert de werking van de PostgreSQL-database. In het geval van een storing informeert het Pacemaker, en als er geen kans is dat de huidige master wordt hersteld, zal het een verkiezing activeren tussen een van de huidige standby-databaseservers. Met de robuuste Pacemaker op zijn plaats, voert Postgres Automatic Failover beheeracties zoals starten, stoppen, bewaken en failover uit op alle knooppunten van de Postgres-databases.

Hoge beschikbaarheid beheren in PostgreSQL - Deel I:automatische failover door ClusterLabsKlik om te tweeten

PostgreSQL automatische failover voor configuratie met hoge beschikbaarheid (HA)

• PAF ondersteunt PostgreSQL versie 9.3 en hoger.
• PAF is niet verantwoordelijk voor het maken van PostgreSQL-master/standby of de configuratie ervan. U moet streamingreplicatie maken en instellen voordat u PAF gebruikt.
• PAF bewerkt geen configuratie- of instellingsvereisten van PostgreSQL. Het vereist echter dat databasegebruikers een paar vereisten volgen, zoals:
  • Slave moet worden geconfigureerd als hot standby. Hot standby-slave-knooppunten kunnen worden opgevraagd als alleen-lezen databases.
  • Een herstelsjabloonbestand (standaard:/recovery.conf.pcmk) moet worden geleverd met onderstaande parameters:
    • standby_mode =aan
    • recovery_target_timeline ='nieuwste'
    • primary_conninfo moet de parameter application_name hebben gedefinieerd en ingesteld op de naam van het lokale knooppunt zoals in Pacemaker.
• PAF onthult meerdere parameters met betrekking tot het beheer van een Postgres-bron. Dit kan naar eigen wens worden geconfigureerd. Hieronder staan ​​de parameters:
  • bindir: locatie van de PostgreSQL-binaire bestanden (standaard:/usr/bin)
  • pgdata: locatie van de PGDATA van uw instantie (standaard:/var/lib/pgsql/data)
  • datadir: pad naar de map die is ingesteld in data_directory van uw postgresql.conf-bestand
  • pghost: de socketdirectory of het IP-adres dat moet worden gebruikt om verbinding te maken met de lokale instantie (standaard:/tmp)
  • pgport: de poort om verbinding te maken met de lokale instantie (standaard:5432)
  • recovery_template: de lokale sjabloon die wordt gekopieerd als het PGDATA/recovery.conf-bestand. Dit sjabloonbestand moet op alle nodes aanwezig zijn (standaard:$PGDATA/recovery.conf.pcmk)
  • start_opts: Aanvullende argumenten voor het Postgres-proces bij het opstarten. Zie “postgres –help” voor beschikbare opties. Handig wanneer het postgresql.conf-bestand niet in de datadirectory (PGDATA) staat, bijv.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • system_user: de systeemeigenaar van het proces van uw instantie (standaard:postgres)
  • maxlag: maximale vertraging toegestaan ​​op een stand-by voordat we er een negatieve masterscore op instellen

Postgres Automatische Failover Pro's

• PAF biedt de gebruiker een gratis hands-on configuratie en setup van PostgreSQL.
• PAF kan knooppuntstoringen aan en verkiezingen starten wanneer de master uitvalt.
• Quorumgedrag kan worden afgedwongen in PAF.
• Het biedt een complete high-availability (HA) databasebeheeroplossing voor de resource, inclusief starten, stoppen en bewaken en afhandelen van scenario's voor netwerkisolatie.
• Het is een gedistribueerde oplossing die het beheer van elk knooppunt vanaf een ander knooppunt mogelijk maakt.

Nadelen na automatische failover van Postgres

• PAF detecteert niet of een standby-knooppunt verkeerd is geconfigureerd met een onbekend of niet-bestaand knooppunt in de herstelconfiguratie. Het knooppunt wordt weergegeven als slave, zelfs als stand-by actief is zonder verbinding te maken met het master/cascadering stand-byknooppunt.
• Vereist een extra poort (standaard 5405) om te worden geopend voor de communicatie van de pacemaker en Corosync-componenten met behulp van UDP.
• Ondersteunt geen NAT-gebaseerde configuratie.
• Geen pg_rewind-ondersteuning.

Hoge beschikbaarheid voor PostgreSQL-testscenario's

We hebben een paar tests uitgevoerd om de mogelijkheden van het PostgreSQL-beheer voor hoge beschikbaarheid (ha) met PAF in sommige gevallen te bepalen. 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-stuurprogramma dat gebruikmaakt van de failover-mogelijkheid voor verbindingen.

Stand-by servertests

Hoofd-/primaire servertests

Netwerkisolatietests

Diverse tests

Is PAF de oplossing voor PostgreSQL High Availability?

Automatische Postgres-failover biedt verschillende voordelen bij het afhandelen van PostgreSQL hoge beschikbaarheid (HA) in veel gebruikssituaties. PAF gebruikt IP-adres-failover in plaats van de stand-by opnieuw op te starten om verbinding te maken met de nieuwe master tijdens een failover-gebeurtenis. Dit blijkt voordelig in scenario's waarin de gebruiker de standby-knooppunten niet opnieuw wil opstarten. PAF heeft ook heel weinig handmatige tussenkomst nodig en beheert de algehele gezondheid van alle bronnen van de Postgres-database. Het enige geval waarin handmatige tussenkomst een vereiste is, is in het geval van een tijdlijngegevensverschil waarbij de gebruiker ervoor kan kiezen om pg_rewind te gebruiken.

In deel 1 hebben we de mogelijkheden en werking van PostgreSQL Automatic Failover (PAF) door ClusterLabs besproken, en in deel 2 bespreken we dezelfde hoge beschikbaarheidsaspecten met behulp van de Replication Manager voor PostgreSQL-clusters (repmgr) van 2ndQuadrant. Zorg ervoor dat je terugkomt voor deel 3, waar we ook Patroni van Zalando bespreken en alle drie de open source-oplossingen vergelijken om je te helpen bepalen wat het beste bij je toepassing past.

In deel 1 blog hebben we de mogelijkheden, best practices en werking van PAF door ClusterLabs besproken, en in deel 2 blogpost zullen we bespreek hetzelfde onderwerp van hoge-beschikbaarheidsaspecten met behulp van de Replicatiemanager voor Postgresql-clusters (repmgr) van 2ndQuadrant. Kom zeker nog eens terug voor onze blogpost over deel 3, waar we ook Patroni van Zalando bespreken en alle drie de open source-oplossingen vergelijken om u te helpen de best practices en de ideale pasvorm voor uw zakelijke toepassingen te bepalen.