Hög tillgänglighet är ett måste nuförtiden eftersom de flesta organisationer inte kan tillåta sig att förlora sina data. Hög tillgänglighet kommer dock alltid med en prislapp (som kan variera mycket.) Alla inställningar som kräver nästan omedelbar åtgärd skulle vanligtvis kräva en dyr miljö som skulle spegla produktionsinställningen exakt. Men det finns andra alternativ som kan vara billigare. Dessa tillåter kanske inte en omedelbar byte till ett katastrofåterställningskluster, men de kommer fortfarande att möjliggöra affärskontinuitet (och kommer inte att tömma budgeten.)
Ett exempel på den här typen av installation är en DR-miljö med "kall standby". Det låter dig minska dina utgifter samtidigt som du kan skapa en ny miljö på en extern plats om katastrofen skulle inträffa. I det här blogginlägget kommer vi att visa hur man skapar en sådan installation.
Initial installation
Låt oss anta att vi har en ganska vanlig Master/Slav MySQL-replikeringsuppsättning i vårt eget datacenter. Det är mycket tillgänglig installation med ProxySQL och Keepalved för virtuell IP-hantering. Den största risken är att datacentret blir otillgängligt. Det är en liten DC, kanske är det bara en ISP utan BGP på plats. Och i den här situationen kommer vi att anta att om det skulle ta timmar att ta tillbaka databasen så är det ok så länge det är möjligt att ta tillbaka den.
För att distribuera detta kluster använde vi ClusterControl, som du kan ladda ner gratis. För vår DR-miljö kommer vi att använda EC2 (men det kan också vara vilken annan molnleverantör som helst.)
Utmaningen
Huvudfrågan vi måste ta itu med är hur ska vi säkerställa att vi har färska data för att återställa vår databas i katastrofåterställningsmiljön? Naturligtvis skulle vi helst ha en replikeringsslav igång i EC2... men då måste vi betala för det. Om vi håller hårt på budgeten kan vi försöka komma runt det med backuper. Detta är inte den perfekta lösningen eftersom vi i värsta fall aldrig kommer att kunna återställa all data.
Med "det värsta scenariot" menar vi en situation där vi inte kommer att ha tillgång till de ursprungliga databasservrarna. Om vi kommer att kunna nå dem skulle data inte ha gått förlorade.
Lösningen
Vi kommer att använda ClusterControl för att ställa in ett säkerhetskopieringsschema för att minska risken för att data skulle gå förlorade. Vi kommer också att använda ClusterControl-funktionen för att ladda upp säkerhetskopior till molnet. Om datacentret inte kommer att vara tillgängligt kan vi hoppas att den molnleverantör vi har valt kommer att vara tillgänglig.
Ställa in säkerhetskopieringsschemat i ClusterControl
Först måste vi konfigurera ClusterControl med våra molnuppgifter.
Vi kan göra detta genom att använda "Integrationer" från menyn till vänster.
Du kan välja Amazon Web Services, Google Cloud eller Microsoft Azure som moln du vill att ClusterControl ska ladda upp säkerhetskopior till. Vi kommer att gå vidare med AWS där ClusterControl kommer att använda S3 för att lagra säkerhetskopior.
Vi måste sedan skicka nyckel-ID och nyckelhemlighet, välj standardregion och välj ett namn för denna uppsättning autentiseringsuppgifter.
När detta är gjort kan vi se inloggningsuppgifterna vi just lade till listade i ClusterControl.
Nu ska vi fortsätta med att ställa in säkerhetskopieringsschemat.
ClusterControl låter dig antingen skapa säkerhetskopia omedelbart eller schemalägga den. Vi går med det andra alternativet. Vad vi vill är att skapa ett följande schema:
- Fullständig säkerhetskopia skapas en gång om dagen
- Inkrementella säkerhetskopior skapas var tionde minut.
Idén här är som följer. I värsta fall förlorar vi bara 10 minuter av trafiken. Om datacentret blir otillgängligt utifrån men det skulle fungera internt, kan vi försöka undvika all dataförlust genom att vänta 10 minuter, kopiera den senaste inkrementella säkerhetskopian på någon bärbar dator och sedan kan vi manuellt skicka den till vår DR-databas med jämn telefondelning och en mobilanslutning för att komma runt ISP-fel. Om vi inte kommer att kunna få ut data från det gamla datacentret på ett tag, är detta avsett att minimera mängden transaktioner som vi måste manuellt sammanfoga med DR-databasen.
Vi börjar med fullständig säkerhetskopiering som kommer att ske dagligen kl. 02.00. Vi kommer att använda mastern för att ta säkerhetskopian från, vi kommer att lagra den på styrenheten under katalogen /root/backups/. Vi kommer också att aktivera alternativet "Ladda upp säkerhetskopia till molnet".
Närnäst vill vi göra några ändringar i standardkonfigurationen. Vi bestämde oss för att gå med automatiskt vald failover-värd (om vår master skulle vara otillgänglig kommer ClusterControl att använda vilken annan nod som helst som är tillgänglig). Vi ville också aktivera kryptering eftersom vi kommer att skicka våra säkerhetskopior över nätverket.
Då måste vi välja inloggningsuppgifterna, välja befintlig S3-bucket eller skapa en ny om det behövs.
Vi upprepar i princip processen för den inkrementella säkerhetskopieringen, denna gång använde vi dialogrutan "Avancerat" för att köra säkerhetskopieringarna var tionde minut.
Resten av inställningarna är liknande, vi kan också återanvända S3-hinken.
Säkerhetskopieringsschemat ser ut som ovan. Vi behöver inte starta fullständig säkerhetskopiering manuellt, ClusterControl kommer att köra inkrementell säkerhetskopiering som planerat och om den upptäcker att det inte finns någon fullständig säkerhetskopiering tillgänglig kommer den att köra en fullständig säkerhetskopiering istället för den inkrementella.
Med en sådan konfiguration kan vi med säkerhet säga att vi kan återställa data på vilket externt system som helst med 10 minuters granularitet.
Manuell återställning av säkerhetskopiering
Om det händer att du behöver återställa säkerhetskopian på katastrofåterställningsinstansen, finns det ett par steg du måste ta. Vi rekommenderar starkt att du testar den här processen då och då, för att säkerställa att den fungerar korrekt och att du är skicklig i att utföra den.
Först måste vi installera AWS kommandoradsverktyg på vår målserver:
[email protected]:~# apt install python3-pip
[email protected]:~# pip3 install awscli --upgrade --userDå måste vi konfigurera det med korrekta referenser:
[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 testa om vi har tillgång till data i vår S3-bucket:
[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 måste vi ladda ner data. Vi kommer att skapa en katalog för säkerhetskopiorna - kom ihåg att vi måste ladda ner hela säkerhetskopieringen - från en fullständig säkerhetskopia till den sista inkrementella vi vill använda.
[email protected]:~# mkdir backups
[email protected]:~# cd backups/Nu finns det två alternativ. Vi kan antingen ladda ner säkerhetskopior en efter en:
[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 också, speciellt om du har ett snävt rotationsschema, synkronisera allt innehåll i hinken med det vi har lokalt på servern:
[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 minns är säkerhetskopiorna krypterade. Vi måste ha en krypteringsnyckel som lagras i ClusterControl. Se till att du har dess kopia lagrad någonstans säkert, utanför huvuddatacentret. Om du inte kan nå det kommer du inte att kunna dekryptera säkerhetskopior. Nyckeln finns i ClusterControl-konfigurationen:
[email protected]:~# grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM='Den är kodad med base64, så vi måste avkoda den först och lagra den i filen innan vi kan börja dekryptera säkerhetskopian:
echo "aoxhIelVZr1dKv5zMbVPLxlLucuYpcVmSynaeIEeBnM=" | openssl enc -base64 -d> pass
Nu kan vi återanvända den här filen för att dekryptera säkerhetskopior. För nu, låt oss säga att vi kommer att göra en fullständig och två inkrementella säkerhetskopieringar.
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 dekrypterad data, nu måste vi fortsätta med att ställa in vår MySQL-server. Helst bör detta vara exakt samma version som på produktionssystemen. Vi kommer att använda Percona Server för 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.7Inget komplicerat, bara vanlig installation. När den är klar och klar måste vi stoppa den och ta bort innehållet i dess datakatalog.
service mysql stop
rm -rf /var/lib/mysql/*För att återställa säkerhetskopian behöver vi Xtrabackup - ett verktyg som CC använder för att skapa den (åtminstone för Perona och Oracle MySQL använder MariaDB MariaBackup). Det är viktigt att detta verktyg är installerat i samma version som på produktionsservrarna:
apt install percona-xtrabackup-24Det är allt vi behöver förbereda. Nu kan vi börja återställa säkerhetskopian. Med inkrementella säkerhetskopior är det viktigt att komma ihåg att du måste förbereda och applicera dem ovanpå basbackupen. Basbackup måste också förberedas. Det är avgörande att köra förbereda med "--apply-log-only"-alternativet för att förhindra att xtrabackup kör återställningsfasen. Annars kommer du inte att kunna använda nästa inkrementella säkerhetskopiering.
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 det senaste kommandot tillät vi xtrabackup att köra återställning av ej slutförda transaktioner - vi kommer inte att använda fler inkrementella säkerhetskopior efteråt. Nu är det dags att fylla i datakatalogen med säkerhetskopian, starta MySQL och se om allt fungerar som förväntat:
[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 är allt bra. MySQL startade korrekt och vi kunde komma åt den (och data finns där!) Vi lyckades med framgång få vår databas igång igen på en separat plats. Den totala tiden som krävs beror strikt på storleken på data - vi var tvungna att ladda ner data från S3, dekryptera och dekomprimera den och slutligen förbereda säkerhetskopian. Ändå är detta ett mycket billigt alternativ (du måste bara betala för S3-data) som ger dig möjlighet till affärskontinuitet om en katastrof skulle inträffa.