PostgreSQL Failover geeft je een betere nachtrust

Gepubliceerd op 7 januari 2021 Leestijd : 3 minuten

PostgreSQL is al jaren één van de meest gebruikte database servers wereldwijd. PostgreSQL is door vele software ontwikkelaars zeer geliefd doordat het flexibel en stabiel is en gemakkelijk grote databases kan bevatten.

Doordat er enorm veel aandacht is besteed aan stabiliteit en performance, lijken veel beheerders de noodzaak van een PostgreSQL failover oplossing niet te zien. Toch is het beter voor je nachtrust als je een failover optie hebt in geval er iets mis gaat waardoor je database server niet meer bereikbaar is.

Scenario 1: Hot-standby PostgreSQL

Bij een hot-standby PostgreSQL server wordt een replica database server geplaatst achter de master server.

De hot-standby server heeft slechts de slave functionaliteit. Dit houdt in dat deze database server dezelfde data bevat als de master maar fungeert slechts als een read-only database server en accepteert geen writes. In geval van een calamiteit, kan de hot-standby server eenvoudig master worden gemaakt en op de applicatieserver wordt de locatie van de database server gewijzigd.

PostgreSQL - blog 1

 

Scenario 2: Automatische failover

Een andere mogelijke scenario is een automatische failover. Een groot voordeel hiervan is dat wanneer er een calamiteit met de master plaatsvindt, een failover binnen enkele seconden gerealiseerd is. Dit kan op verschillende manieren worden uitgevoerd, onze voorkeur gaat uit naar de volgende opties:

  1. Keepalived vrrp ip-adres met een failover script
  2. PostgreSQL proxy PGPool2
1. Keepalived vrrp IP-adres met een failover script

Op een eenvoudige wijze kan een automatische failover met PostgreSQL worden gerealiseerd. Dat doe je door vanaf de applicatieserver verbinding te maken met het keepalived vrrp adres, dat tussen beide PostgreSQL servers zweeft. Met een script wordt het ProgreSQL proces op de server bewaakt. Zodra deze faalt springt het zwevende IP-adres over naar de hot-standby server. Het failover script zorgt ervoor dat de read-only status in master verandert.

Waar je voor moet waken is dat er geen fallback plaatsvindt naar de oude master mocht deze weer beschikbaar worden. De data op deze oude master is immers niet meer up-to-date.

Nadat de failover heeft plaatsgevonden is er geen hot-standby meer aanwezig en verkeert de database setup zich in een zgn. “degenerated state”. Wanneer er een nieuwe calamiteit met de nieuwe master optreedt, is er geen failover mogelijkheid meer aanwezig. In dit geval zal de database beheerder zo snel mogelijk een nieuwe hot-standby slave aan de nieuwe master moeten koppelen.

PostgreSQL - blog 2
2. PostgreSQL proxy PGPool2

Een wat meer geavanceerde automatische failover mogelijkheid is het gebruik maken van een PostgreSQL proxy PGPool2. De voordelen van een proxy zijn:

  • Centrale configuratie database verbindingen
  • Constante database verbinding, dus geen overhead nieuwe sessies
  • Uitsplitsen read-write verkeer voor loadbalanced reads
  • Ingebouwde health checks en failover scripts

Ook met deze variant zal ervoor gezorgd moeten worden dat er geen automatische fallback naar de oude master plaatsvindt, mocht deze onverhoopt terugkomen.

PostgreSQL - blog 3

Maak altijd een plan

Het is belangrijk om vast te leggen hoe een failover en een fallback geregeld is. Zorg ervoor dat je houvast hebt op het moment dat er een calamiteit plaatsvindt. Schrijf de stappen volledig uit, zodat je met het kopiëren en plakken van de commando’s, een failover kan uitvoeren (indien dit niet automatisch gaat) of een database kunt herstellen vanuit een back-up.

Je slaapt immers lekkerder als je weet dat alles goed geregeld is. Wij zijn erg gesteld op onze nachtrust. Jij ook? Neem gerust contact met ons op als je meer over dit onderwerp wilt weten.