Een ramp veroorzaakt meestal een storing, wat neerkomt op systeemuitval en mogelijk verlies van gegevens. Zodra we de black-out hebben gedetecteerd, activeren we ons DR-plan om ervan te herstellen. Maar het zou een verrassing zijn, als er geen back-up is, of als je na urenlang herstel ziet dat dit niet degene is die je nodig hebt.
Hoewel uitval kostbaar kan zijn, zijn er vaak financiële gevolgen die schadelijk kunnen zijn voor het bedrijf en gegevensverlies kan een reden zijn om het bedrijf te sluiten.
Om gegevensverlies tot een minimum te beperken, moeten we meerdere kopieën van gegevens op verschillende plaatsen hebben. We kunnen onze infrastructuur in verschillende lagen ontwerpen en elke laag abstraheren van de onderliggende laag. We bouwen bijvoorbeeld een laag voor clusters van database-instances om te beschermen tegen hardwarestoringen. We repliceren databases over datacenters, zodat we ons kunnen verdedigen tegen een datacenterstoring. Elke extra laag voegt complexiteit toe, wat een nachtmerrie kan worden om te beheren. Maar toch zal in wezen een back-up de centrale plaats innemen bij het herstel na calamiteiten.
Daarom is het cruciaal om er zeker van te zijn dat we erop kunnen vertrouwen. Maar hoe dit te bereiken? Welnu, een van de opties is om te controleren of back-ups zijn uitgevoerd op basis van de laatste paar regels van het back-upscript.
Een eenvoudig voorbeeld:
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fiMaar wat als het back-upscript helemaal niet is gestart? Google biedt nogal wat zoekresultaten voor 'Linux cron, not running'.
Helaas bieden open-source databases vaak geen back-uprepository.
Nog een back-uptest. Je hebt misschien gehoord over de kat van Schrödinger. Een bekende back-uptheorie van Schrödinger is . "De staat van een back-up is onbekend totdat een herstelpoging wordt gedaan." Klinkt als een eenvoudige aanpak, maar zo'n poging zou betekenen dat je een testomgeving moet opzetten, bestanden moet kopiëren en restore moet uitvoeren ... na elke back-up.
In dit artikel zullen we zien hoe u ClusterControl kunt gebruiken om ervoor te zorgen dat uw back-up wordt uitgevoerd om Enterprise-Grade-databases te realiseren met open source-databases.
Back-uprapporten
ClusterControl is gericht op operationele rapportages. Operational Reporting biedt ondersteuning voor de dagelijkse bewaking en controle van bedrijfsactiviteiten. Het back-uprapport is een van de vele. U kunt rapporten vinden zoals:
- Dagelijks systeemrapport
- Pakketupgraderapport
- Schemawijzigingsrapport
- Beschikbaarheid
- Back-up
Maar waarom zou je dit nodig hebben?
Je hebt misschien al een uitstekende monitoringtool met alle mogelijke statistieken/grafieken en je hebt waarschijnlijk ook waarschuwingen ingesteld op basis van statistieken en drempels (sommige hebben zelfs geautomatiseerde adviseurs die hen aanbevelingen doen of dingen automatisch oplossen.) Dat is goed - inzicht hebben in je systeem is belangrijk; toch moet je veel informatie kunnen verwerken.
Hoe werkt dit? ClusterControl verzamelt informatie over het back-upproces, de systemen, platforms en apparaten in de back-upinfrastructuur wanneer de back-uptaak wordt geactiveerd. Al die informatie wordt geaggregeerd en opgeslagen in een CMON (interne database), dus het is niet nodig om bepaalde databases extra te doorzoeken. Bovendien, wanneer het ontdekt dat u een actief cluster heeft, maar er geen back-up was, wordt dit ook gerapporteerd.
In de rapportdetails kunt u een back-up-ID volgen met gedetailleerde gegevens over de locatie, grootte, tijd en back-upmethode. Sjablonen werken met gegevens voor verschillende databasetypen, dus wanneer u uw gemengde omgeving beheert, krijgt u hetzelfde gevoel en uiterlijk. Het helpt om back-ups van verschillende databases beter te beheren.
CLI-rapporten
Voor degenen die de voorkeur geven aan de opdrachtregelinterface, een goede optie om back-ups te volgen ClusterControl Command Line Interface (CLI).
Met CLI kunt u de meeste functies binnen ClusterControl uitvoeren met behulp van eenvoudige opdrachten. Back-upuitvoering en back-uprapporten zijn er een van.
Gebruikt in combinatie met de krachtige GUI, geeft het ClusterControl-gebruikers alternatieve manieren om hun open-source databaseomgevingen te beheren met elke gewenste engine.
$ s9s backup --list --cluster-id=1 --long --human-readable
ID CID STATE OWNER HOSTNAME CREATED SIZE FILENAME
1 1 COMPLETED dba 10.0.0.5 07:21:39 252K mysqldump_2017-05-09_072135_mysqldb.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:21:43 1014 mysqldump_2017-05-09_072135_schema.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:03 109M mysqldump_2017-05-09_072135_data.sql.gz
1 1 COMPLETED dba 10.0.0.5 07:22:07 679 mysqldump_2017-05-09_072135_triggerseventsroutines.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:20 252K mysqldump_2017-05-09_073016_mysqldb.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:24 1014 mysqldump_2017-05-09_073016_schema.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:44 109M mysqldump_2017-05-09_073016_data.sql.gz
2 1 COMPLETED dba 10.0.0.5 07:30:49 679 mysqldump_2017-05-09_073016_triggerseventsroutines.sql.gzVanaf versie 1.4.1 zal het installatiescript dit pakket automatisch installeren op het ClusterControl-knooppunt. CLI maakt deel uit van het s9s-tools-pakket. U kunt het ook afzonderlijk op een andere computer installeren om het databasecluster op afstand te beheren. Net als ClusterControl maakt het gebruik van beveiligde SSH-communicatie.
Automatische back-upverificatie
Een back-up is geen back-up als we de gegevens niet kunnen ophalen. Het verifiëren van back-ups is iets dat door veel bedrijven over het hoofd wordt gezien. Laten we eens kijken hoe ClusterControl de verificatie van back-ups kan automatiseren en verrassingen kan voorkomen.
Selecteer in ClusterControl uw cluster en ga naar het gedeelte "Back-up" en selecteer vervolgens "Back-up maken".
De functie voor automatisch verifiëren van back-ups is beschikbaar voor de geplande back-ups, dus laten we kiezen de optie "Back-up plannen".
Bij het plannen van een back-up moeten we naast het selecteren van de algemene opties zoals methode of opslag ook de planning/frequentie specificeren. In dit voorbeeld gaan we MySQL-back-upverificatie instellen. Hetzelfde kan echter worden bereikt voor PostgreSQL- en Timescale-databases.
Als back-upverificatie is aangevinkt, verschijnt er een ander tabblad.
Hier kunnen we alle noodzakelijke stappen instellen om de omgeving voor te bereiden. Wanneer IP wordt verstrekt, zijn we klaar om een dergelijke back-up te plannen. Telkens wanneer de back-up is voltooid, wordt deze gekopieerd naar een tijdelijke back-upverificatie-omgeving (“back-up terugzetten op” optie). Na een succesvolle vernieuwing ziet u de status van de verificatie op het tabblad back-uprepository.
Mislukte back-upuitvoeringen en integratieservices
Een andere interessante optie om meer aanwijzingen te krijgen over het uitvoeren van back-ups is het gebruik van ClusterControl Integration-services. U kunt de uitvoeringsstatus van de back-up beheren met services van derden.
Met de integratie van tools van derden kunt u waarschuwingen automatiseren met andere populaire systemen. Momenteel ondersteunt ClusterControl ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram en Webhooks.
Hieronder zien we een voorbeeld van Slack-kanaalintegratie. Telkens wanneer een back-upgebeurtenis optreedt, verschijnt deze in het slappe kanaal.
Conclusie
Back-ups zijn verplicht in elke omgeving. Ze helpen u uw gegevens te beschermen en staan centraal in elk scenario voor noodherstel. ClusterControl kan helpen het back-upproces voor uw databases te automatiseren en, in geval van storing, met een paar klikken te herstellen. U kunt er ook zeker van zijn dat ze met succes en betrouwbaar worden uitgevoerd, zodat u in geval van een ramp uw gegevens niet kwijtraakt.