Twee servers kunnen tegelijk uitvallen. Misschien gebruiken ze dezelfde opslag, hangen ze aan dezelfde switch of krijgen ze allebei dezelfde foutieve update. Het aantal replica's zegt weinig over hoe een dienst na een storing herstelt.

Begin met een concreet scenario: de databasehost reageert niet meer, een beheerder verwijdert een volume of het gebouw valt zonder stroom. Ga na wat er met de applicatie gebeurt, wie een melding krijgt en waar de herstelprocedure staat.

Spreek af hoeveel uitval en dataverlies aanvaardbaar zijn

De recovery time objective (RTO) is de beoogde tijd om de dienst te herstellen. De recovery point objective (RPO) geeft aan hoeveel recente data verloren mag gaan. Bepaal die twee grenzen per dienst voordat je de architectuur kiest.

Stel dat een interne rapportagetool tot de volgende ochtend mag uitvallen en dat je de invoer opnieuw kunt importeren. Herstel vanuit een back-up kan dan volstaan. Voor een bestelsysteem dat veel sneller weer moet werken, heb je een andere opzet nodig. Dit zijn voorbeeldvereisten; de mensen die de systemen gebruiken, moeten de werkelijke grenzen bepalen.

Tel de afhankelijkheden mee. Een herstelde applicatie waarvan de gebruikers niet kunnen aanmelden, is voor hen nog steeds onbeschikbaar.

Zoek wat je dubbele componenten delen

Zet hosts, opslag, switches, voedingen, DNS en identiteitsdiensten op één schema. Duid aan welke onderdelen door dezelfde storing kunnen wegvallen.

Een tweede voeding helpt alleen als ze nog stroom krijgt wanneer de eerste uitvalt. Een tweede applicatie-instance helpt alleen als de resterende infrastructuur het verkeer aankan. Test die verminderde capaciteit met een realistische belasting.

Replica's nemen ook fouten over. Een geldig commando dat records verwijdert, kan die verwijdering via replicatie verspreiden. Bewaar herstelkopieën met passende bewaartermijnen en toegangsbeperkingen. Controleer of de beheerrechten voor productie ook toelaten om elke back-up te vernietigen.

Maak onderscheid tussen replicatie en failover

PostgreSQL streaming replication houdt een standby bij. Het detecteert op zichzelf geen defecte primary en regelt niet zelfstandig de automatische omschakeling. De PostgreSQL-documentatie over failover beschrijft de bijkomende coördinatie, waaronder voorkomen dat de oude primary terugkomt en opnieuw schrijfbewerkingen aanvaardt.

Leg voor jouw databaseopstelling vast wie of wat een standby promoveert, hoe clients die vinden en hoe de oude primary wordt geïsoleerd. Meet het resultaat. Een te korte timeout kan een tijdelijke netwerkonderbreking omzetten in een onnodige failover.

Een tweede locatie vraagt nog een afweging. Wachten op een schrijfbewerking op afstand kan transacties vertragen. Asynchrone replicatie kan recente wijzigingen verliezen als de primaire locatie uitvalt. Kies op basis van de afgesproken hersteldoelen en meet de replicatieachterstand tijdens drukke periodes.

Herstel een dienst en gebruik hem

Kies één applicatie voor een hersteloefening. Zet ze met de geschreven procedure terug in een geïsoleerde omgeving. Laat iemand anders dan de gebruikelijke beheerder de stappen uitvoeren.

Noteer hoelang het duurt om toegang te krijgen, de back-up op te halen, data terug te zetten, de applicatie te starten en een gewone gebruikerstaak uit te voeren. Controleer hoe oud de herstelde gegevens zijn. Test aanmelden, lezen, schrijven en de noodzakelijke koppelingen.

Vul de procedure daarna aan met wat ontbrak. Misschien stond een sleutel in de uitgevallen omgeving, was niemand verantwoordelijk voor een DNS-wijziging of duurde het herstel langer dan afgesproken. Los die punten op voordat je extra infrastructuur toevoegt. Als je de applicatie daarvoor moet verplaatsen, neem dezelfde oefening dan op in het migratieplan.