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.
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.
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:
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.
Een wat meer geavanceerde automatische failover mogelijkheid is het gebruik maken van een PostgreSQL proxy PGPool2. De voordelen van een proxy zijn:
Ook met deze variant zal ervoor gezorgd moeten worden dat er geen automatische fallback naar de oude master plaatsvindt, mocht deze onverhoopt terugkomen.
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.
Neem contact op