Høj tilgængelighed er et must i disse dage, da de fleste organisationer ikke kan tillade sig selv at miste sine data. Høj tilgængelighed kommer dog altid med et prisskilt (som kan variere meget.) Enhver opsætning, der kræver næsten øjeblikkelig handling, ville typisk kræve et dyrt miljø, som ville afspejle præcis produktionsopsætningen. Men der er andre muligheder, der kan være billigere. Disse tillader muligvis ikke et øjeblikkeligt skift til en katastrofegendannelsesklynge, men de vil stadig tillade forretningskontinuitet (og vil ikke dræne budgettet).
Et eksempel på denne type opsætning er et "kold-standby" DR-miljø. Det giver dig mulighed for at reducere dine udgifter, mens du stadig er i stand til at skabe et nyt miljø på et eksternt sted, hvis katastrofen rammer. I dette blogindlæg vil vi demonstrere, hvordan man laver sådan en opsætning.
Den indledende opsætning
Lad os antage, at vi har en ret standard Master/Slave MySQL-replikeringsopsætning i vores eget datacenter. Det er meget tilgængeligt opsætning med ProxySQL og Keepalved til virtuel IP-håndtering. Den største risiko er, at datacentret bliver utilgængeligt. Det er en lille DC, måske er det kun én internetudbyder uden BGP på plads. Og i denne situation vil vi antage, at hvis det ville tage timer at bringe databasen tilbage, er det ok, så længe det er muligt at bringe den tilbage.
For at implementere denne klynge brugte vi ClusterControl, som du kan downloade gratis. Til vores DR-miljø vil vi bruge EC2 (men det kan også være en hvilken som helst anden cloud-udbyder.)
Udfordringen
Hovedproblemet, vi skal forholde os til, er, hvordan skal vi sikre, at vi har friske data til at gendanne vores database i katastrofegendannelsesmiljøet? Selvfølgelig ville vi ideelt set have en replikeringsslave oppe at køre i EC2... men så skal vi betale for det. Hvis vi er stramme på budgettet, kan vi prøve at omgå det med backups. Dette er ikke den perfekte løsning, da vi i værste fald aldrig vil være i stand til at gendanne alle data.
Med "det værste tilfælde" mener vi en situation, hvor vi ikke har adgang til de originale databaseservere. Hvis vi vil være i stand til at nå dem, ville data ikke være gået tabt.
Løsningen
Vi vil bruge ClusterControl til at konfigurere en sikkerhedskopieringsplan for at reducere risikoen for, at dataene går tabt. Vi vil også bruge ClusterControl-funktionen til at uploade sikkerhedskopier til skyen. Hvis datacentret ikke vil være tilgængeligt, kan vi håbe, at den cloud-udbyder, vi har valgt, er tilgængelig.
Opsætning af sikkerhedskopieringsplanen i ClusterControl
Først skal vi konfigurere ClusterControl med vores cloud-legitimationsoplysninger.
Vi kan gøre dette ved at bruge "Integrationer" fra menuen til venstre.
Du kan vælge Amazon Web Services, Google Cloud eller Microsoft Azure som skyen du vil have ClusterControl til at uploade sikkerhedskopier til. Vi vil gå videre med AWS, hvor ClusterControl vil bruge S3 til at gemme sikkerhedskopier.
Vi skal derefter videregive nøgle-id og nøglehemmelighed, vælg standardområdet og vælg et navn til dette sæt legitimationsoplysninger.
Når dette er gjort, kan vi se de legitimationsoplysninger, vi lige har tilføjet, anført i ClusterControl.
Nu skal vi fortsætte med at opsætte backup-plan.
ClusterControl giver dig mulighed for enten at oprette backup med det samme eller planlægge den. Vi vil gå med den anden mulighed. Det, vi ønsker, er at oprette en følgende tidsplan:
- Fuld sikkerhedskopi oprettet én gang om dagen
- Inkrementelle sikkerhedskopier oprettet hvert 10. minut.
Idéen her er som følger. I værste fald mister vi kun 10 minutter af trafikken. Hvis datacentret bliver utilgængeligt udefra, men det ville fungere internt, kunne vi forsøge at undgå datatab ved at vente 10 minutter, kopiere den seneste inkrementelle sikkerhedskopi på en bærbar computer, og så kan vi manuelt sende den til vores DR-database ved at bruge telefoninternet og en cellulær forbindelse til at undgå ISP-fejl. Hvis vi ikke vil være i stand til at få dataene ud af det gamle datacenter i et stykke tid, har dette til formål at minimere mængden af transaktioner, vi manuelt skal flette ind i DR-databasen.
Vi starter med fuld backup, som vil ske dagligt kl. 02.00. Vi vil bruge masteren til at tage backup fra, vi gemmer den på controlleren under mappen /root/backups/. Vi vil også aktivere "Upload sikkerhedskopi til skyen".
Dernæst vil vi lave nogle ændringer i standardkonfigurationen. Vi besluttede at gå med automatisk valgt failover-vært (i tilfælde af at vores master ikke ville være tilgængelig, vil ClusterControl bruge enhver anden node, som er tilgængelig). Vi ønskede også at aktivere kryptering, da vi vil sende vores sikkerhedskopier over netværket.
Så skal vi vælge legitimationsoplysningerne, vælge eksisterende S3-bøtte eller oprette en ny, hvis det er nødvendigt.
Vi gentager grundlæggende processen for den trinvise sikkerhedskopiering, denne gang brugte vi dialogboksen "Avanceret" for at køre sikkerhedskopierne hvert 10. minut.
Resten af indstillingerne ligner hinanden, vi kan også genbruge S3-bøtten.
Sikkerhedskopieringsplanen ser ud som ovenfor. Vi behøver ikke starte fuld sikkerhedskopiering manuelt, ClusterControl vil køre trinvis backup som planlagt, og hvis den opdager, at der ikke er fuld backup tilgængelig, vil den køre en fuld backup i stedet for trinvis.
Med en sådan opsætning kan vi med sikkerhed sige, at vi kan gendanne dataene på ethvert eksternt system med 10 minutters granularitet.
Manuel sikkerhedskopieringsgendannelse
Hvis det sker, at du bliver nødt til at gendanne sikkerhedskopien på katastrofegendannelsesinstansen, er der et par trin, du skal tage. Vi anbefaler kraftigt at teste denne proces fra tid til anden for at sikre, at den fungerer korrekt, og at du er dygtig til at udføre den.
Først skal vi installere AWS kommandolinjeværktøj på vores målserver:
[email protected]:~# apt install python3-pip
[email protected]:~# pip3 install awscli --upgrade --userSå skal vi konfigurere det med de rigtige legitimationsoplysninger:
[email protected]:~# ~/.local/bin/aws configure
AWS Access Key ID [None]: yourkeyID
AWS Secret Access Key [None]: yourkeySecret
Default region name [None]: us-west-1
Default output format [None]: jsonVi kan nu teste, om vi har adgang til dataene i vores S3-bøtte:
[email protected]:~# ~/.local/bin/aws s3 ls s3://drbackup/
PRE BACKUP-1/
PRE BACKUP-2/
PRE BACKUP-3/
PRE BACKUP-4/
PRE BACKUP-5/
PRE BACKUP-6/
PRE BACKUP-7/Nu skal vi downloade dataene. Vi vil oprette en mappe til sikkerhedskopierne - husk, vi skal downloade hele sikkerhedskopieringssættet - startende fra en fuld sikkerhedskopi til den sidste trinvise, vi ønsker at anvende.
[email protected]:~# mkdir backups
[email protected]:~# cd backups/Nu er der to muligheder. Vi kan enten downloade sikkerhedskopier én efter én:
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-1/ BACKUP-1 --recursive
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
Completed 30.4 MiB/36.2 MiB (4.9 MiB/s) with 1 file(s) remaining
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256
[email protected]:~# ~/.local/bin/aws s3 cp s3://drbackup/BACKUP-2/ BACKUP-2 --recursive
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256Vi kan også, især hvis du har en stram rotationsplan, synkronisere alt indhold i bøtten med det, vi har lokalt på serveren:
[email protected]:~/backups# ~/.local/bin/aws s3 sync s3://drbackup/ .
download: s3://drbackup/BACKUP-2/cmon_backup.metadata to BACKUP-2/cmon_backup.metadata
download: s3://drbackup/BACKUP-4/cmon_backup.metadata to BACKUP-4/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/cmon_backup.metadata to BACKUP-3/cmon_backup.metadata
download: s3://drbackup/BACKUP-6/cmon_backup.metadata to BACKUP-6/cmon_backup.metadata
download: s3://drbackup/BACKUP-5/cmon_backup.metadata to BACKUP-5/cmon_backup.metadata
download: s3://drbackup/BACKUP-7/cmon_backup.metadata to BACKUP-7/cmon_backup.metadata
download: s3://drbackup/BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 to BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/cmon_backup.metadata to BACKUP-1/cmon_backup.metadata
download: s3://drbackup/BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 to BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256
download: s3://drbackup/BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256 to BACKUP-7/backup-incr-2019-08-20_123008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256 to BACKUP-6/backup-incr-2019-08-20_122008.xbstream.gz.aes256
download: s3://drbackup/BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256 to BACKUP-5/backup-incr-2019-08-20_121007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256 to BACKUP-4/backup-incr-2019-08-20_120007.xbstream.gz.aes256
download: s3://drbackup/BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 to BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256Som du husker, er sikkerhedskopierne krypteret. Vi skal have en krypteringsnøgle, som er gemt i ClusterControl. Sørg for, at du har dens kopi opbevaret et sikkert sted uden for hoveddatacenteret. Hvis du ikke kan nå det, vil du ikke være i stand til at dekryptere sikkerhedskopier. Nøglen kan findes i ClusterControl-konfiguration:
[email protected]:~# grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM='Det er kodet med base64, så vi skal først afkode det og gemme det i filen, før vi kan begynde at dekryptere sikkerhedskopien:
ekko "aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM=" | openssl enc -base64 -d> pass
Nu kan vi genbruge denne fil til at dekryptere sikkerhedskopier. Lad os nu sige, at vi vil lave en fuld og to trinvise sikkerhedskopier.
mkdir 1
mkdir 2
mkdir 3
cat BACKUP-1/backup-full-2019-08-20_113009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/1/
cat BACKUP-2/backup-incr-2019-08-20_114009.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/2/
cat BACKUP-3/backup-incr-2019-08-20_115005.xbstream.gz.aes256 | openssl enc -d -aes-256-cbc -pass file:/root/backups/pass | zcat | xbstream -x -C /root/backups/3/Vi har dekrypteret data, nu skal vi fortsætte med at opsætte vores MySQL-server. Ideelt set bør dette være nøjagtig den samme version som på produktionssystemerne. Vi vil bruge Percona Server til MySQL:
cd ~
wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
sudo dpkg -i percona-release_latest.generic_all.deb
apt-get update
apt-get install percona-server-5.7Intet komplekst, bare almindelig installation. Når det er oppe og klar, er vi nødt til at stoppe det og fjerne indholdet af dets databibliotek.
service mysql stop
rm -rf /var/lib/mysql/*For at gendanne sikkerhedskopien skal vi bruge Xtrabackup - et værktøj CC bruger til at oprette den (i det mindste for Perona og Oracle MySQL bruger MariaDB MariaBackup). Det er vigtigt, at dette værktøj er installeret i samme version som på produktionsserverne:
apt install percona-xtrabackup-24Det er alt, vi skal forberede. Nu kan vi begynde at gendanne sikkerhedskopien. Med inkrementelle sikkerhedskopier er det vigtigt at huske på, at du skal forberede og anvende dem oven på basissikkerhedskopieringen. Basis backup skal også forberedes. Det er afgørende at køre forberedelse med '--anvend-log-only'-indstillingen for at forhindre xtrabackup i at køre tilbagerulningsfasen. Ellers vil du ikke være i stand til at anvende næste trinvise sikkerhedskopiering.
xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/
xtrabackup --prepare --apply-log-only --target-dir=/root/backups/1/ --incremental-dir=/root/backups/2/
xtrabackup --prepare --target-dir=/root/backups/1/ --incremental-dir=/root/backups/3/I den sidste kommando tillod vi xtrabackup at køre tilbagerulning af ikke gennemførte transaktioner - vi vil ikke anvende flere trinvise sikkerhedskopier bagefter. Nu er det tid til at udfylde databiblioteket med backup, start MySQL og se om alt fungerer som forventet:
[email protected]:~/backups# mv /root/backups/1/* /var/lib/mysql/
[email protected]:~/backups# chown -R mysql.mysql /var/lib/mysql
[email protected]:~/backups# service mysql start
[email protected]:~/backups# mysql -ppass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.26-29 Percona Server (GPL), Release '29', Revision '11ad961'
Copyright (c) 2009-2019 Percona LLC and/or its affiliates
Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> show schemas;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| proxydemo |
| sbtest |
| sys |
+--------------------+
6 rows in set (0.00 sec)
mysql> select count(*) from sbtest.sbtest1;
+----------+
| count(*) |
+----------+
| 10506 |
+----------+
1 row in set (0.01 sec)Som du kan se, er alt godt. MySQL startede korrekt, og vi var i stand til at få adgang til det (og dataene er der!) Det lykkedes os at bringe vores database op-og-kørende igen på et separat sted. Den samlede tid, der kræves, afhænger strengt af størrelsen af dataene - vi skulle downloade data fra S3, dekryptere og dekomprimere dem og til sidst forberede sikkerhedskopien. Alligevel er dette en meget billig mulighed (du skal kun betale for S3-data), som giver dig mulighed for forretningskontinuitet, hvis en katastrofe rammer.