En katastrofe forårsager normalt et udfald, hvilket betyder systemnedetid og potentielt tab af data. Når vi har opdaget blackoutet, udløser vi vores DR-plan for at komme sig over det. Men det ville være en overraskelse, hvis der ikke er nogen backup, eller efter mange timers gendannelse, kan du se, at det ikke er den, du har brug for.
Selv om afbrydelser kan være dyre - er der ofte en økonomisk påvirkning, som kan være skadelig for virksomheden, og tab af data kan være en grund til at lukke virksomheden.
For at minimere datatab skal vi have flere kopier af data forskellige steder. Vi kan designe vores infrastruktur i forskellige lag og abstrahere hvert lag fra det under det. For eksempel bygger vi et lag til klynger af databaseforekomster for at beskytte mod hardwarefejl. Vi replikerer databaser på tværs af datacentre, så vi kan forsvare os mod et datacenterfejl. Hvert ekstra lag tilføjer kompleksitet, hvilket kan blive et mareridt at håndtere. Men stadigvæk vil en sikkerhedskopi tage den centrale plads i katastrofegendannelsen.
Derfor er det afgørende at være sikker på, at det er noget, vi kan stole på. Men hvordan opnår man dette? Nå, en af mulighederne er at verificere, om sikkerhedskopier blev udført baseret på de sidste par linjer af backup-script.
Et simpelt eksempel:
#!/bin/sh
mysqldump -h 192.168.1.1 -u user -ppassword dbname > filename.sql
if [ "$?" -eq 0 ]; then
echo "Success."
else
echo "Error."
fiMen hvad nu hvis sikkerhedskopieringsscriptet slet ikke startede? Google tilbyder en hel del søgeresultater for "Linux cron, kører ikke."
Desværre tilbyder open source-databaser ofte ikke backup-lager.
Endnu en backup-test. Du har måske hørt om Schrödingers kat. En kendt Schrödingers Backup-teori er . "Betingelsen for enhver sikkerhedskopi er ukendt, indtil en gendannelse er forsøgt." Det lyder som en simpel tilgang, men et sådant forsøg ville betyde, at du skal opsætte et testmiljø, kopiere filer køre gendannelse ... efter hver sikkerhedskopiering.
I denne artikel vil vi se, hvordan du kan bruge ClusterControl til at sikre, at din backup udføres for at opnå Enterprise-Grade-databaser med Open Source-databaser.
Sikkerhedskopieringsrapporter
ClusterControl har været rettet mod driftsrapporter. Operationel rapportering giver støtte til den daglige virksomhedsaktivitetsovervågning og -kontrol. Backup-rapporten er en af mange. Du kan finde rapporter som:
- Daglig systemrapport
- Pakkeopgraderingsrapport
- Skemaændringsrapport
- Tilgængelighed
- Sikkerhedskopiering
Men hvorfor skulle du bruge dette?
Du har muligvis allerede et glimrende overvågningsværktøj med alle mulige målinger/grafer, og du har sikkert også sat alarmer op baseret på målinger og tærskler (nogle vil endda have automatiske rådgivere, der giver dem anbefalinger eller ordner ting automatisk). Det er godt - at have synlighed i din systemet er vigtigt; ikke desto mindre skal du være i stand til at behandle en masse information.
Hvordan fungerer dette? ClusterControl indsamler oplysninger om backup-processen, systemerne, platformene og enheder i backup-infrastrukturen, når backup-jobbet udløses. Alle disse oplysninger er aggregeret og gemt i en CMON (intern database), så der er ingen grund til at forespørge særlige databaser yderligere. Derudover, når den opdager, at du har en kørende klynge, men der ikke var nogen backup, vil det også blive rapporteret.
I rapportoplysningerne kan du spore et backup-id med detaljerede data om placering, størrelse, tidspunkt og backupmetode. Skabeloner fungerer med data til forskellige databasetyper, så når du administrerer dit blandede miljø, får du den samme følelse og udseende. Det hjælper med at administrere forskellige databasesikkerhedskopier bedre.
CLI-rapporter
For dem, der foretrækker kommandolinjegrænsefladen, er en god mulighed for at spore sikkerhedskopier ClusterControl Command Line Interface (CLI).
CLI lader dig udføre de fleste af de funktioner, der er tilgængelige i ClusterControl ved hjælp af simple kommandoer. Sikkerhedskopieringsudførelse og backuprapporter er en af dem.
Brugt i forbindelse med den kraftfulde GUI giver det ClusterControl-brugere alternative måder at administrere deres open source-databasemiljøer ved at bruge den motor, de foretrækker.
$ 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.gzBegyndende fra version 1.4.1 vil installationsscriptet automatisk installere denne pakke på ClusterControl-noden. CLI er en del af s9s-tools-pakken. Du kan også installere det separat på en anden maskine for at administrere databaseklyngen eksternt. I lighed med ClusterControl bruger den sikker SSH-kommunikation.
Automatisk sikkerhedskopiering
En sikkerhedskopi er ikke en sikkerhedskopi, hvis vi ikke er i stand til at hente dataene. Bekræftelse af sikkerhedskopier er noget, der normalt overses af mange virksomheder. Lad os se, hvordan ClusterControl kan automatisere bekræftelsen af sikkerhedskopier og hjælpe med at undgå overraskelser.
I ClusterControl skal du vælge din klynge og gå til sektionen "Backup", og derefter vælge "Opret sikkerhedskopi".
Den automatiske bekræftelse af sikkerhedskopiering er tilgængelig for de planlagte sikkerhedskopier, så lad os vælge muligheden "Schedule Backup".
Når vi planlægger en sikkerhedskopi, skal vi ud over at vælge de almindelige muligheder som metode eller lagring også specificere tidsplan/hyppighed. I dette eksempel skal vi konfigurere MySQL-sikkerhedskopibekræftelse. Det samme kan dog opnås for PostgreSQL- og Timescale-databaser.
Når sikkerhedskopieringsbekræftelse er markeret, vises en anden fane.
Her kan vi indstille alle de nødvendige trin for at forberede miljøet. Når IP er leveret, er vi gode til at gå og planlægge en sådan backup. Når sikkerhedskopieringen afsluttes, vil den blive kopieret til et midlertidigt sikkerhedskopieringsmiljø ("gendan sikkerhedskopiering til"). Efter vellykket opdatering vil du se status for bekræftelse på fanen backup-lager.
Mislykkede sikkerhedskopierings- og integrationstjenester
En anden interessant mulighed for at få flere ledetråde om sikkerhedskopiering er at bruge ClusterControl-integrationstjenester. Du kan kontrollere sikkerhedskopieringsudførelsesstatus med tredjepartstjenester.
Integration af tredjepartsværktøjer giver dig mulighed for at automatisere advarsler med andre populære systemer. I øjeblikket understøtter ClusterControl ServiceNow, PagerDuty, VictorOps, OpsGenie, Slack, Telegram og Webhooks.
Nedenfor kan vi se et eksempel på Slack-kanalintegration. Hver gang en sikkerhedskopieringshændelse opstår, vises den i den slappe kanal.
Konklusion
Sikkerhedskopier er obligatoriske i ethvert miljø. De hjælper dig med at beskytte dine data og er i centrum af ethvert scenarie for gendannelse af katastrofer. ClusterControl kan hjælpe med at automatisere backup-processen for dine databaser og, i tilfælde af fejl, genskabe den med et par klik. Du kan også være sikker på, at de udføres med succes og pålideligt, så i tilfælde af en katastrofe mister du ikke dine data.