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 uw nachtrust als
u een failover optie hebt ingeval er iets misgaat waardoor uw database
server niet meer bereikbaar is.
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.
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
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:
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.
Zorg ervoor dat vastligt hoe een failover en een fallback geregeld is. Zorg ervoor dat u houvast heeft op het moment dat er een calamiteit plaatsvindt. Schrijf het uit, desnoods letterlijk zodat u 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 back-up.
Zoals al eerder gezegd slaapt u lekkerder als u 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.
Vond je deze blog interessant? Schrijf je hieronder in voor onze nieuwsbrief, en blijf regelmatig op de hoogte van onze blogs!
Meer informatie over dit onderwerp