Hantera PostgreSQL High Availability – Del I:PostgreSQL Automatic Failover

Hantera High Availability (HA) i ditt PostgreSQL-värd är ett mycket viktigt ämne för att säkerställa att dina databasdistributionskluster bibehåller exceptionell drifttid och stark driftprestanda så att din data alltid är tillgänglig för din applikation. I ett tidigare blogginlägg introducerade vi dig för att konfigurera hög tillgänglighet för PostgreSQL med strömmande replikering, och nu ska vi visa dig hur du bäst hanterar hög tillgänglighet på klientsidan.

Det finns flera tillgängliga verktyg för att hantera hög tillgänglighet (HA) för dina PostgreSQL-distributionskluster med hjälp av strömmande replikering. Dessa lösningar erbjuder automatiska failover-funktioner, övervakar tillgänglighet och systemstatus, replikering, användarhantering och andra användbara administrativa uppgifter om användningsfall för Postgres-databaser. Några av de framträdande lösningarna med öppen källkod inkluderar:

1. PostgreSQL Automatic Failover av ClusterLabs

2. Replication Manager för PostgreSQL-kluster av repmgr (2ndQuadrant)

3. Patroni av Zalando

Varje verktyg tillhandahåller sitt eget sätt att hantera PostgreSQL-klustren med hög tillgänglighet. I vår tredelade serie med inlägg om HA för PostgreSQL kommer vi att dela en översikt, förutsättningarna och arbets- och testresultaten för vart och ett av dessa tre verktyg. Här i del 1 kommer vi att djupdyka in i PAF-lösningen från ClusterLabs.

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

Hur hanterar man hög tillgänglighet för din PostgreSQL-databas?

PostgreSQL Automatic Failover (PAF) är en hanteringslösning med hög tillgänglighet för PostgreSQL av ClusterLabs. Den använder Postgres synkron replikering för att garantera att ingen data går förlorad vid tidpunkten för failover-operationen. Den använder den populära industristandarden Pacemaker och Corosync-stacken. Med Pacemaker- och Corosync-applikationer tillsammans kommer du att kunna upptäcka PostgreSQL-databasfel i systemet och agera därefter.

Pacemaker är en tjänst som kan hantera många resurser och gör det med hjälp av sina resursagenter. Resursagenter har sedan ansvaret att hantera en specifik resurs, hur de ska bete sig och informera Pacemaker om deras resultat.

Din resursagentimplementering måste följa specifikationen för Open Cluster Framework (OCF). Denna specifikation definierar resursagenters beteende och implementering av metoder som att stoppa, starta, främja, degradera och interagera med Pacemaker.

PAF är en OCF-resursagent för Postgres skriven i Perl. När ditt databaskluster väl har byggts med hjälp av intern streamingreplikering kan PAF exponera för Pacemaker den aktuella statusen för PostgreSQL-instansen på var och en av databasernas noder:master, slav, stoppad, ikapp, lastbalanserare etc.

Så fungerar Postgres Automatic Failover

PAF kommunicerar med Pacemaker angående klusterstatus och övervakar PostgreSQL-databasens funktion. I händelse av ett misslyckande informerar den Pacemaker, och om det inte finns någon chans att den aktuella mastern återställs, kommer det att utlösa ett val mellan en av de nuvarande standby-databasservrarna. Med den robusta pacemakern på plats kommer Postgres Automatic Failover att utföra hanteringsåtgärder som start, stopp, övervakning och failover på alla Postgres-databasernas noder.

Hantera hög tillgänglighet i PostgreSQL - Del I:Automatic Failover av ClusterLabsKlicka för att tweeta

PostgreSQL Automatic Failover för konfiguration med hög tillgänglighet (HA)

• PAF stöder PostgreSQL version 9.3 och högre.
• PAF ansvarar inte för skapande av PostgreSQL-master/vänteläge eller dess inställningar – du måste skapa och ställa in streamingreplikering innan du använder PAF.
• PAF redigerar inga konfigurations- eller inställningskrav för PostgreSQL. Det kräver dock att databasanvändare följer några krav som:
  • Slaven måste konfigureras som hot standby. Heta standby-slavnoder kan frågas som skrivskyddade databaser.
  • En återställningsmallfil (standard:/recovery.conf.pcmk) måste tillhandahållas med nedanstående parametrar:
    • vänteläge =på
    • recovery_target_timeline ='senaste'
    • primär_konninfo måste ha parametern application_name definierad och inställd på lokalt nodnamn som i Pacemaker.
• PAF exponerar flera parametrar relaterade till hanteringen av en Postgres-resurs. Detta kan konfigureras för att passa ens krav. Nedan är parametrarna:
  • bindir: plats för PostgreSQL-binärfilerna (standard:/usr/bin)
  • pgdata: plats för PGDATA för din instans (standard:/var/lib/pgsql/data)
  • datakatalog: sökvägen till katalogen som anges i data_directory från din postgresql.conf-fil
  • pghost: socketkatalogen eller IP-adressen som ska användas för att ansluta till den lokala instansen (standard:/tmp)
  • pgport: porten för att ansluta till den lokala instansen (standard:5432)
  • återställningsmall: den lokala mallen som kommer att kopieras som filen PGDATA/recovery.conf. Denna mallfil måste finnas på alla noder (standard:$PGDATA/recovery.conf.pcmk)
  • start_opts: Ytterligare argument som ges till Postgres-processen vid start. Se "postgres -help" för tillgängliga alternativ. Användbart när postgresql.conf-filen inte finns i datakatalogen (PGDATA), t.ex.:-c config_file=/etc/postgresql/9.3/main/postgresql.conf
  • systemanvändare: systemägaren av din instanss process (standard:postgres)
  • maxlag: maximal fördröjning som tillåts i standby innan vi sätter ett negativt huvudpoäng på det

Postgres Automatic Failover Proffs

• PAF ger användaren en gratis praktisk konfiguration och installation av PostgreSQL.
• PAF kan hantera nodfel och utlösa val när mastern går ner.
• Kvorumbeteende kan upprätthållas i PAF.
• Det kommer att tillhandahålla en komplett lösning för hantering av databaser med hög tillgänglighet (HA) för resursen, inklusive start, stopp och övervakning och hantera scenarier för nätverksisolering.
• Det är en distribuerad lösning som möjliggör hantering av valfri nod från en annan nod.

Postgres Automatic Failover Nackdelar

• PAF upptäcker inte om en standbynod är felkonfigurerad med en okänd eller obefintlig nod i återställningskonfigurationen. Noden kommer att visas som slav, även om standby körs utan att ansluta till master/cascading standby nod.
• Kräver att en extra port (standard 5405) öppnas för Pacemaker- och Corosync-komponenternas kommunikation med UDP.
• Stöder inte NAT-baserad konfiguration.
• Inget stöd för pg_rewind.

Hög tillgänglighet för PostgreSQL-testscenarier

Vi genomförde några tester för att fastställa förmågan hos PostgreSQL-hanteringen med hög tillgänglighet (ha) med PAF i vissa användningsfall. Alla dessa tester kördes medan applikationen kördes och infogade data till PostgreSQL-databasen. Applikationen skrevs med hjälp av PostgreSQL Java JDBC-drivrutin som utnyttjar möjligheten för anslutningsfel.

Standby-servertest

Tester av master/primär server

Tester för nätverksisolering

Övriga tester

Är PAF lösningen för PostgreSQL High Availability?

Postgres Automatic Failover ger flera fördelar vid hantering av PostgreSQL hög tillgänglighet (HA) i många användningsfall. PAF använder IP-adress failover istället för att starta om standby för att ansluta till den nya mastern under en failover-händelse. Detta visar sig vara fördelaktigt i scenarier där användaren inte vill starta om standbynoderna. PAF behöver också mycket lite manuellt ingrepp och hanterar den övergripande hälsan för alla Postgres-databasers resurser. Det enda fallet där manuell intervention är ett krav är i händelse av en tidslinjedataavvikelse där användaren kan välja att använda pg_rewind.

I del 1 har vi diskuterat funktionerna och funktionerna för PostgreSQL Automatic Failover (PAF) av ClusterLabs, och i del 2 kommer vi att diskutera samma höga tillgänglighetsaspekter med hjälp av Replication Manager för PostgreSQL-kluster (repmgr) av 2ndQuadrant. Se till att komma tillbaka till del 3, där vi också kommer att täcka Patroni av Zalando och jämföra alla tre lösningarna med öppen källkod för att hjälpa dig att avgöra vilken passform som är bäst för din applikation.

I del 1-bloggen har vi diskuterat funktionerna, bästa praxis och hur PAF av ClusterLabs fungerar, och i del 2-blogginlägget kommer vi att diskutera samma ämne med hög tillgänglighetsaspekter med hjälp av replikeringshanteraren för Postgresql-kluster (repmgr) av 2ndQuadrant. Se till att komma tillbaka till vårt blogginlägg om del 3, där vi också kommer att täcka Patroni av Zalando och jämföra alla tre lösningarna med öppen källkod för att hjälpa dig avgöra de bästa metoderna och den perfekta passformen för dina affärsapplikationer.