Databaseback-ups plannen met ClusterControl

Databaseback-up is een cruciaal onderdeel van databasebeheer en moet zorgvuldig worden gepland. Het plannen van een back-up is niet voldoende, back-upgegevens moeten ook worden geverifieerd op consistentie en integriteit. Er zijn andere overwegingen, zoals codering en off-site archiveren. Een goede back-upmanager zou functies hebben die rekening houden met al deze verschillende overwegingen.

In deze blogpost gaan we kijken hoe u uw databaseback-ups kunt plannen met ClusterControl.

Databaseback-ups met ClusterControl

ClusterControl ondersteunt een aantal back-upmethoden, afhankelijk van het clustertype, zoals samengevat in de volgende tabel:

Bij het plannen van een back-up met ClusterControl, kan elk van de back-upmethoden worden geconfigureerd met een reeks opties voor hoe u wilt dat de back-up wordt uitgevoerd. Verschillende database-workloads en back-upstrategieën vereisen ondersteuning voor verschillende functies, bijvoorbeeld:

• Schijf-IOPS-beperking
• Netwerkbeperking
• Back-upvergrendelingen
• Encryptie
• Compressie
• Bewaarperiode
• Verificatie

ClusterControl stelt automatisch een aantal back-upopties in, volgens de best-practice van de betreffende databaseleverancier. Als het doeldatabaseknooppunt bijvoorbeeld een binair logboek heeft ingeschakeld, voegt het een extra vlag toe, --master-data om de binaire logcoördinaten (bestandsnaam en positie) van de gedumpte server op te nemen. Als het een Galera-knooppunt is en de back-upmethode xtrabackup is, voegt ClusterControl een extra vlag toe, --galera-info die de status van het lokale knooppunt bevat op het moment van de back-up.

Een back-up plannen

Voordat we een back-up plannen, moeten we plannen hoe de back-upbewerking zou moeten zijn. Het is handig om de volgende voorbeeldvragen te beantwoorden voordat u een back-upschema maakt:

• Welke back-upmethode wilt u gebruiken? Sommige back-upmethoden zijn niet-blokkerend, maar zeer arbeidsintensief. Begrijp de afwegingen, zodat u niet verbaasd bent over hoe het proces zich tijdens de productie gedraagt.
• Hoe vaak wilt u een back-up maken van uw databases? Het uitvoeren van een volledige back-up kan pijnlijk zijn als het back-upinterval te kort is. Je hebt waarschijnlijk een mix van volledige en incrementele back-ups nodig.
• Hoe snel wilt u uw gegevens herstellen? Fysieke back-up is meestal veel sneller dan logische back-up in termen van volledige hersteltijd. Aan de andere kant is een logische back-up meestal sneller voor gedeeltelijk herstel.
• Hoe groot is uw gegevensomvang? In sommige gevallen is logische back-up geen goede keuze voor enorme databases en is binaire back-up de enige manier om te gaan.
• Hoeveel vrije ruimte heb je om je back-up op te slaan? Back-ups nemen vaak veel ruimte in beslag. Bepaal of compressie nodig is en welk compressieniveau u zich kunt veroorloven. Betere compressie vereist een hoger CPU-gebruik.
• Wat als de back-upserver niet beschikbaar is tijdens de back-uptijd? Moet de back-up worden overgezet naar een andere beschikbare host? Een back-up overslaan vanwege een onderhoudsperiode is meestal geen goed idee.
• Hoe de integriteit van de gemaakte back-up te waarborgen? Onthoud dat een back-up geen back-up is als deze niet kan worden hersteld.
• Vertrouwt u de back-upopslag? Versleuteling kan een goed idee zijn om uw gegevens te beschermen.

Door deze vragen te beantwoorden, kunnen we over het algemeen een geschikte back-upstrategie bedenken. De lijst met vragen kan langer zijn, afhankelijk van uw back-up- en herstelbeleid.

We hebben dit hoofdstuk uitgebreid behandeld in onze whitepaper, The DevOps Guide to Database Backups for MySQL and MariaDB.

Een back-up plannen
 

Met ClusterControl is plannen vrij eenvoudig. Ga rechtstreeks naar Back-up -> Back-up maken -> Back-up plannen en u krijgt het volgende dialoogvenster te zien:

Afhankelijk van het clustertype kunnen de opties verschillen, zoals te zien is in de volgende schermafbeeldingen voor PostgreSQL en MongoDB:

De meeste opties spreken voor zich en worden gedetailleerd beschreven in de gebruikershandleiding. Nadat het schema is gemaakt, kunt u de configuratieback-ups bewerken, de back-up in-/uitschakelen of het schema verwijderen op het tabblad "Geplande back-ups":

Houd er rekening mee dat bij het plannen van back-up met ClusterControl, alle tijd moet worden gepland in de UTC-tijdzone van de ClusterControl-server. De reden hierachter is om de verwarring over de uitvoeringstijd van de back-up te voorkomen. Bij het werken met een cluster kunnen de databaseservers in verschillende tijdzones en verschillende geografische gebieden zijn verspreid. Het gebruik van één referentietijdzone om ze allemaal te beheren, zorgt ervoor dat de back-ups altijd op het juiste moment worden uitgevoerd.

U kunt de voortgang van een back-up volgen door te kijken naar Activiteit -> Taken zodra de tijd daar is. Als de back-uptaak ​​is mislukt, ziet u de fout meteen:

Het bovenstaande logboek is ook toegankelijk onder het tabblad Back-up op elk van de back-upitems:

Controles en verificatie na back-up

Als de back-uptaak ​​eenmaal is voltooid, betekent dit niet dat uw verantwoordelijkheid voorbij is. Er zijn een paar dingen die moeten worden opgevolgd. De belangrijkste is de status van de gemaakte back-up. ClusterControl zorgt voor e-mailmeldingen en informeert u over de status. Deze meldingsservice is natuurlijk configureerbaar op basis van de ernst onder Instellingen -> Algemene instellingen -> Instellingen voor e-mailmeldingen -> Back-up:

Bezorgen betekent dat ClusterControl direct een e-mailmelding stuurt nadat een alarm voor dit onderdeel is gegenereerd. Je zou het ook kunnen configureren als Negeren of Digest, waar ClusterControl een dagelijks overzicht van gegenereerde alarmen stuurt.

Als de back-up met succes is gemaakt, wordt het ten zeerste aanbevolen om te controleren of de back-up kan worden hersteld. U kunt de functie Back-upverificatie gebruiken door op de knop "Herstellen" van de gekozen back-up-ID te klikken en u krijgt twee herstelopties te zien:

"Herstellen en verifiëren op zelfstandige host" vereist een aparte host, die nog geen deel uitmaakt van de databaseconfiguratie. ClusterControl implementeert eerst een MySQL-instantie op de doelhost, start de service, kopieert de back-up uit de back-uprepository en start het herstel. Als u klaar bent, kunt u de server afsluiten nadat deze is hersteld of deze laten draaien, zodat u verder onderzoek op de server kunt uitvoeren.

Schoonmaak is ook belangrijk om alleen de nuttige back-ups in uw opslag te bewaren. Configureer dus de back-upretentie indien nodig. Standaard verwijdert ClusterControl back-ups die ouder zijn dan 30 dagen. U kunt ook elk van de back-upschema's aanpassen met verschillende bewaarperioden.

Als de back-upopslag de ruimtelimiet nadert, of als u uw back-up buitenspel wilt archiveren, kunt u ervoor kiezen om het bestand handmatig te verwijderen door op het prullenbakpictogram te klikken of het naar de cloud te uploaden, zoals hieronder aangegeven:

Op het moment van schrijven worden AWS S3 en GCP Cloud Storage ondersteund. De cloudreferenties moeten vooraf worden geconfigureerd onder Zijmenu -> Integraties -> Cloudproviders.

Dat is het, mensen. Veel plezier met clusteren!