• Auteur: Root
  • Datum: 17-12-2018

PostgreSQL behoort al jaren tot de meest gebruikte database servers ter wereld. Doordat PostgreSQL flexibel en stabiel is en gemakkelijk grote databases kan bevatten, is PostgreSQL voor veel software ontwikkelaars een geliefde keuze.

Doordat er zoveel aandacht is besteed aan stabiliteit en performance, lijken veel beheerders niet echt de noodzaak te zien voor een PostgreSQL failover oplossing. Toch is het beter voor je nachtrust als je een failover optie hebt ingeval er iets misgaat waardoor je database server niet meer bereikbaar is.

PostgreSQL hot-standby

De configuratie van een hot-standby PostgreSQL server is vrij eenvoudig. Er wordt een tweede database server geplaatst die als replica achter de master hangt.


De Hot-Standby server is puur een slave. Een read-only database server die dezelfde data bevat als de master, maar die geen writes accepteert. In geval van een calamiteit kan de Hot-Standby server eenvoudig Master worden gemaakt en dient op de applicatieserver de locatie van de database server te worden gewijzigd.


Automatische failover

Hoewel er niets mis is met deze oplossing, kan er misschien de voorkeur aan worden gegeven om de failover automatisch te laten verlopen. Het voordeel hiervan is dat als er een calamiteit met de Master plaatsvindt, binnen enkele seconden een failover geregeld is. Dit kan op verschillende manieren, maar onze voorkeur gaat uit naar de volgende opties:

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

Keepalived vrrp ip-adres met een failover script

In deze setup maken we verbinding vanaf de applicatie server met het keepalived vrrp adres dat zweeft tussen beide PostgreSQL servers. Een script bewaakt het PostgreSQL proces op de server en zodra deze faalt sprint het zwevende ip-adres over naar de Hot-standby server waar het failover script ervoor zorgt dat de read-only status verandert in Master.

Dit is een redelijk simpele manier om een automatische failover te realiseren met PostgreSQL. Zorg er wel voor dat er geen fallback plaatsvindt naar de oude Master mocht deze weer beschikbaar worden, deze is immers niet meer up-to-date met zijn data.

Na de failover is er geen Hot-standby meer aanwezig en verkeert de database setup zich in een zogenaamde  “degenerated state”. Als er nu een calamiteit plaatsvindt met de nieuwe master is er geen failover mogelijkheid meer aanwezig. De database beheerder moet er zo snel mogelijk voor zorgen dat er een nieuwe Hot-Standby slave aan de nieuwe Master gekoppeld wordt. 


PostgreSQL proxy PGPool2

Een wat meer geavanceerde oplossing 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 load balanced reads 
  • Ingebouwde health checks en failover scripts

Ook voor een setup met een PostgreSQL proxy zoals PGPool2 dienen we ervoor te zorgen dat er geen automatische fallback plaatsvindt naar de oude master, mocht deze onverhoopt terugkomen.


Maak altijd een plan

Zorg ervoor dat vastligt hoe een failover en een fallback geregeld is. Zorg ervoor dat je houvast hebt op het moment dat er een calamiteit plaatsvindt. Schrijf het uit, desnoods letterlijk zodat je stapsgewijs, 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 backup.

Zoals al eerder gezegd slaap je lekkerder als je weet dat alles goed geregeld is. Wij zijn erg gesteld op onze nachtrust. U ook? Neem gerust contact met ons op als u meer over dit onderwerp wilt weten.

Neem contact op met
een van onze specialisten