Framgångsrika MySQL/MariaDB-strategier för säkerhetskopiering och återställning

En viktig del för att förhindra all form av dataförlust i alla situationer är att ha lämpliga säkerhetskopierings- och återställningspolicyer. Det är också viktigt att säkerställa dataåterställning när som helst under applikationens arbetsflödes livscykel. Både MySQL och MariaDB erbjuder lösningar för dessa fall. Den här artikeln kommer att utforska de befintliga alternativen och procedurerna samt andra potentiella säkerhetskopieringsalternativ för MySQL och MariaDB.

Säkerhetskopieringsstrategier

Eftersom data är den viktigaste delen av alla applikationer är det viktigt att skydda dess integritet för att överleva i striden om tillvaron. Varje störning av datatillgängligheten eller integriteten under någon tid kommer sannolikt att allvarligt skada applikationen och verksamheten/tjänsten den tillhandahåller.

För att säkerställa framgångsrikt applikationsarbetsflöde och affärskontinuitet måste du implementera lämpliga säkerhetskopierings- och återställningspolicyer med dagliga, veckovisa, månatliga och årliga säkerhetskopior. Sådana säkerhetskopior kommer att köras vid kritiska perioder, såsom:

före ett dagligt batchfönster;
före omfattande dataintag;
före någon programuppgradering;
veckovisa, månatliga och årliga säkerhetskopior för att uppfylla regulatoriska krav;
eller annat schemalagt dagligt/veckovis underhåll.

Säkerhetskopieringsverktyg

MySQL och MariaDB erbjuder flera sätt att ställa in och köra backup- och återställningsplaner. Dessa metoder inkluderar fysiska säkerhetskopior med MySQL:s Enterprise mysqlbackup-verktyg , MariaDB:s mariabackup-verktyg , eller Perconas XtraBackup-verktyg . Dessutom logiska säkerhetskopior skapade med Mysqls mysqldump-verktyg kan komma väl till pass. Ett annat alternativ är punkt-in-time återställning med databaserna bin-logs (transaktionsloggarna) i kombination med de verktyg som nämnts tidigare.

Du kan tillgodogöra dig lämpliga metoder i din säkerhetskopieringsstrategi för att maximera databasens återställningsbarhet i händelse av misslyckande eller katastrof.

Obs:I MariaDB version 10.4.6, mysqldumps symbollänk kallas mariadb-dump . I de senare versionerna, inklusive 10.5.2, ändrades namnen igen – mysqldump blev symlänk .

För att illustrera procedurerna kommer jag att använda verktyget mariabackup för att skapa fysiska säkerhetskopior. Verktygets grundläggande funktionalitet är densamma som i de tidigare nämnda verktygen, även om det finns några små skillnader som är unika för varje verktyg.

Säkerhetskopiering av fysiska databas

Fysiska säkerhetskopior är säkerhetskopior på filnivå som ger dig snabba filkopieringsmetoder. Sådana säkerhetskopior är att föredra i scenarier för katastrofåterställning, kloning av databaser och/eller skapande av slavdatabaser.

När du gör fysiska säkerhetskopior kan du välja att skapa fullständiga eller inkrementella säkerhetskopior. Fullständiga säkerhetskopior inkluderar en fullständig säkerhetskopia av databasservern. Inkrementella säkerhetskopior sparar endast ändringar från den senaste fullständiga eller inkrementella säkerhetskopian.

Viktigt:Databasens storlek reglerar tidpunkten för säkerhetskopieringen. Av den anledningen kan en bra strategi för att säkerhetskopiera en mycket stor databas vara att kombinera fullständiga och inkrementella säkerhetskopior. På så sätt sparar du både säkerhetskopiornas lagringsutrymme och den totala backup- och återställningstiden.

Ett annat ögonblick som du bör lägga märke till är att när du återställer data från en fysisk säkerhetskopia måste du stoppa din MySQL/MariaDB-databasinstansprocess tills de sista återställningsstegen är slutförda.

Du kan utföra en enkel fullständig fysisk säkerhetskopiering enligt följande:

 mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220 \
   --user=backupuser --password=backuppasswd

–target-dir alternativet talar om för säkerhetskopieringsverktyget var säkerhetskopian ska placeras.

I det här exemplet har jag organiserat min säkerhetskopia i katalogen DÅÅÅÅMMDD där varje fullständig säkerhetskopia lagras (D står för Daily). Genom att göra det har vi ett enkelt tillvägagångssätt för att återställa databasen från säkerhetskopian som togs vid ett specifikt datum.

Nästa exempel visar exekvering av en enkel inkrementell säkerhetskopiering:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc1/ \
   --incremental-basedir=/data/backups/mariadb/D20210220/ \
   --user=backupuser --password=backuppasswd

Den efterföljande inkrementella säkerhetskopieringen skulle se ut på följande sätt:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc2/ \
   --incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
   --user=backupuser --password=backuppasswd

Den –inkrementella-baserade katalogen option instruerar säkerhetskopieringsverktyget att använda den tidigare tagna fullständiga eller inkrementella säkerhetskopian som utgångspunkt för att bygga inkrementella deltafiler för den aktuella säkerhetskopian. På så sätt bygger den upp en kedja av en fullständig säkerhetskopia med efterföljande inkrementella säkerhetskopior. Tillsammans bildar de en enda säkerhetskopia för att återställa vid behov.

Låt oss nu ta reda på vad som är namnet på den fysiska databasfilen där all katalogdata är lagrad. Databasen som finns på domänkontrollanter är en Active Directory. Den här katalogen används för att hantera användare, data etc. Kärnan i en Active Directory är databasfilen NTDS.DIT som består av länkar, säkerhetsdeskriptorer och datatabeller. All katalogdata lagras i denna fysiska databasfil.

Det är nödvändigt att skilja mellan fysiska och logiska filer. Faktiska systemdata finns i fysiska filer, medan logiska filer innehåller beskrivningar av poster lagrade i fysiska filer.

Uppgiften att återställa MySQL-databasen från fysiska filer kan ibland vara svår. mysqldump kommandot kan vara till hjälp i det här fallet. Vi kommer att täcka detta ämne ytterligare.

Säkerhetskopiering av logiska databas

Logiska säkerhetskopior skapas med mysqldump verktyg. Denna säkerhetskopieringsmetod är mer flexibel än fysisk säkerhetskopiering. Den består av alla DML- och/eller DDL SQL-satser som är nödvändiga för att skapa en konsekvent säkerhetskopia, som kombinerar alla anslutna data och ändringar som gjorts före och under säkerhetskopieringen. Om du vill veta mer om hur du säkerhetskopierar och återställer alla databaser kan du läsa den här artikeln.

Den logiska säkerhetskopian kan vara en enda fil eller flera filer (skapade med ett specifikt skript). Vidare kan du återställa strukturen och/eller data utan att stänga av din MySQL/MariaDB-instans (process). Följaktligen utförs logiska säkerhetskopieringar på databas- och/eller tabellnivå, medan fysiska säkerhetskopieringar görs på filsystemsnivå (kataloger och filer).

Observera också att logiska säkerhetskopior uteslutande är fullständiga säkerhetskopior av de avsedda databaserna och/eller tabellerna.

Att skapa en logisk säkerhetskopia av hela MySQL/MariaDB-instansen är nedan:

mysqldump --all-databases --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql

Observera att fysiska säkerhetskopior och logiska säkerhetskopior särskiljs specifikt i filsystemet för säkerhetskopieringshantering.

Till skillnad från föregående exempel skapas en logisk säkerhetskopia av en enda databas (schema) på följande sätt:

mysqldump empdb --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Slutligen, för att skapa en logisk säkerhetskopia av en enskild tabell i en databas, lägg till tabellens namn efter databasen:

mysqldump empdb departments --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql

När du behöver redigera och lägga till DROP DATABASE- eller DROP TABLE-satserna till återställningsscenariot, kan arbete med stora säkerhetskopieringsfiler ha sammandragande effekter på textredigerare så att de kvävs.

I sådana fall kan du överväga att lägga till andra alternativ, till exempel –add-drop-databas och/eller –lägg till-släpp-tabell att inkludera dessa DROP-satser i säkerhetskopian. I andra scenarier kanske du vill utesluta dessa påståenden och ersätta dem med –skip-add-drop-table alternativ till kommandot.

Du kan dock också skapa säkerhetskopior av endast data eller endast DDL med –no-create-info eller –ingen data alternativ. Separata säkerhetskopior av data och struktur kan vara ett bra val i vissa återställningsscenarier, särskilt när du bara behöver DDL-strukturen för att skapa en tom klonad databas och/eller dess tabeller.

Säkerhetskopiera databas med hjälp av skivögonblicksbilder

När data växer kan det bli nödvändigt att organisera dem på flera diskar och/eller filsystem. Förutom prestandaskälen, eftersom I/O är distribuerad över flera diskar/filsystem, måste du se till att effektiva säkerhetskopierings- och återställningsstrategier inkluderar funktionerna för disk- och filsystemets ögonblicksbild.

Börja med att designa och bygga filsystemslayouterna där varje databas, grupp av tabeller och index finns. Organisera sedan dina tabeller och konfigurera databassystemet. De bör antingen finnas alla i en enda katalog:

innodb_home_dir = /<path where your InnoDB tables will reside>

Eller så kan du använda DATA_DIRECTORY och INDEX_DIRECTORY alternativen i SKAPA tabellsats för att distribuera dem separat till olika filsystemplatser.

För InnoDB, se till att använda file_per_table =PÅ (standard PÅ i de senaste versionerna). Välj sökvägen för InnoDB-tabellerna noggrant när du skapar dem. Det är omöjligt att ändra sökvägen utan att tappa och återskapa tabellen.

Det är bra att ha ordentliga filsystem med inbyggda snapshot-funktioner, t.ex. XFS och ZFS på Linux. Lägg märke till att skapa ögonblicksbild-säkerhetskopiorna liknar att skapa fysiska säkerhetskopior, men det har särdrag. Det kräver att skrivprocessen stoppas (SPOLA MED LÄSSLÅS eller liknande — se BACKUP-STED kommandot i MariaDB onlinedokumentation) innan du tar ögonblicksbilden och släpper LÅS omedelbart efter slutförandet av ögonblicksbilden. Det är nödvändigt att säkerställa datakonsistens.

Du bör överväga och använda säkerhetskopiorna för ögonblicksbilder i scenarier för katastrofåterställning. Men de är också lämpliga för kloning av databasinstanser.

Återställningsstrategier

Återställning från fysiska säkerhetskopior

Tidigare har vi beskrivit de fysiska säkerhetskopieringsstegen. På så sätt kan du antingen bygga upp en kedja av fullständiga säkerhetskopior eller en kedja av fullständiga och inkrementella säkerhetskopior. Det senare alternativet innebär att en fullständig säkerhetskopiering följt av en efterföljande inkrementell säkerhetskopiering är noll om ett fel inträffar.

En DBA tar till exempel fullständiga säkerhetskopior på söndagar och inkrementella säkerhetskopior på andra dagar. Ett fel uppstår efter att ha gjort en inkrementell säkerhetskopiering på onsdagen. Därför måste de återställa databasen. Under sådana omständigheter måste vår DBA använda den fullständiga säkerhetskopian som görs på söndagen och inkrementella säkerhetskopior som görs på måndag, tisdag och onsdag. Om det fanns dagliga fullständiga säkerhetskopior skulle det vara tillräckligt att återställa onsdagens säkerhetskopia.

För att återställa den "närmaste" säkerhetskopian efter ett fel, oavsett om det är en fullständig eller inkrementell säkerhetskopia, måste du försäkra dig om att ALLA säkerhetskopieringsfiler är konsekventa vid tidpunkten med tiden för närmaste backup-slut. Annars kommer InnoDB-motorn att avvisa data genom att anse att den är korrupt.

En annan viktig punkt är, när du förbereder säkerhetskopior, kopiera de involverade fullständiga säkerhetskopiorna till en annan plats innan du tillämpar stegen för att säkerställa konsistens vid tidpunkten. På så sätt bevarar du det ursprungliga säkerhetskopieringsläget, vilket kan vara praktiskt senare. Jag rekommenderar starkt att du håller dig till detta tillvägagångssätt.

För att förbereda en fullständig säkerhetskopia, välj den som ligger närmast felet, kopiera den till önskad plats och kör följande kommando:

mariabackup --prepare \
   --target-dir=data/backups/mariadb/COPY_D20210220

För att återställa till närmaste inkrementella säkerhetskopia, förbereder du en kopia av närmaste fullständiga säkerhetskopia och lägger till alla relevanta inkrementella säkerhetskopior i en efterföljande ordning . Den återställda databasbilden ska vara som följer:

Vi uppnår detta genom att utföra förberedelserna kommando för varje inkrementell säkerhetskopiering enligt nedan:

mariabackup --prepare \
   --target-dir=/data/backups/mariadb/COPY_D20210220 \
   --incremental-dir=/data/backups/mariadb/D20210220_INC#

Efter att ha förberett säkerhetskopian måste vi stänga av databasinstansen (bearbeta). Dessutom måste vi tömma databaskatalog innan du avslutar återställningsprocessen. Du kan utfärda antingen kommandot med –copy-back alternativ

mariabackup --copy-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

eller med –flytta tillbaka alternativ:

mariabackup --move-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

Det senare kommandot flyttar den kopierade katalogen till databaskatalogen. Att kopiera den ursprungliga säkerhetskopian till en annan plats är ett klokt val. Annars kommer säkerhetskopian att gå förlorad, eftersom den inte kan användas för andra situationer och scenarier.

Det sista steget innan du startar databasinstansen är att justera ägandet av filerna så att det matchar användaren och processens ägares grupp. Vanligtvis är det MySQL.

Återställning från logiska säkerhetskopior

Ganska ofta förbiser vi en viktig punkt när vi återställer databaser och/eller tabeller med logiska säkerhetskopior. Den här punkten ställer in max_allowed_packet storleken på sessionen (det kan vara klokare att ställa in det globalt) till maxvärdet 1073741824. Det är nödvändigt att se till att stora buffertar och INSERT-satser passar in i ett enda paket mellan klienten och servern. Detta bör minska återhämtningstiden.

En annan viktig aspekt när du gör en säkerhetskopia är att inkludera eller exkludera DROP-satserna som nämnts tidigare. Vi behöver det för att säkerställa att säkerhetskopieringsprocessen körs så smidigt som möjligt. Med det i åtanke, använd nedanstående kod för att utföra säkerhetskopieringsåterställningen:

mysql -u backupuser -p backuppasswd  < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Om du inte har någon databas inkluderad i säkerhetskopian, som med enskilda databassäkerhetskopior, eller om du behöver omdirigera återställningen till en annan databas, använd en annan kod:

mysql -u backupuser -p backuppasswd  newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Återställning med skivögonblicksbilder

För att återställa från diskens ögonblicksbild alltid börja med att se till att databassystemet är avstängt innan återställningsprocessen exekveras . Varje försök att återställa en livedatabas med hjälp av skivögonblicksbilden kommer att resultera i datainkonsekvenser och, mer troligt, datakorruption.

Återställning vid tidpunkt

Point in time recovery (PITR) är, som namnet antyder, en metod för att återställa databaser och tabeller så nära tiden före felet. Eller, om den dagliga batchprocessen har misslyckats och måste köras om, har du också det enda alternativet – återställ PITR-backup.

Det är viktigt att aktivera databasens bin-log och ställa in bin-log-formatet till antingen uttalandebaserad, radbaserad eller blandad loggning, beroende på vilken typ av arbetsbelastning din databas körs. Vidare kan du behöva aktivera komprimering med log_bin_compress =ON (standard AV) för att spara diskutrymme.

Eftersom bin-log är en transaktionslogg och skapad i en sekvens är det avgörande att säkerhetskopiera alla loggfiler. När det gäller PITR-processen är den omöjlig utan loggfiler. Dessutom bör bin-loggunderhållet och livscykeln följa livscykeln för alla fullständiga och inkrementella säkerhetskopior. Se därför till att bara rensa de loggar som är äldre än den äldsta säkerhetskopian i säkerhetskopieringspolicyn.

Du kan rensa binära loggar på två sätt. Först är det genom att deklarera det närmaste bin-log-namnet till den äldsta säkerhetskopian som visas i rensningskommandot nedan:

PURGE BINARY LOGS TO 'mariadb-bin.000063';

För det andra är det genom att deklarera datumet för den äldsta säkerhetskopian som finns i rensningskommandot:

PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';

För att förbereda oss för återhämtning måste vi hämta alla nödvändiga uttalanden för att spela upp till den nödvändiga tidpunkten. Samla alla tillgängliga bin-loggar från det att säkerhetskopieringen startade till den tidpunkt du återställer.

Börja med att granska logglistan från det att säkerhetskopieringen avslutades till PITR-tiden:

mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql

Granska sedan de tillfälliga filerna för att hitta de exakta loggpositionerna du vill använda och använda. Dessa är –startposition och –stop-position som ställer in de exakta positionerna i kommandot och kör mysqlbinlog igen kommando:

mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql

Vid denna tidpunkt har återställningsprocessen börjat. Den använder antingen fysiska eller logiska säkerhetskopior, fullständiga eller inkrementella.

Avsluta återställningen genom att använda final_temporary_PITR_file.sql använda MySQL-klienten enligt nedan:

mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sql

Vi har slutfört PITR-återställningen genom att återställa säkerhetskopian och återuppspelade transaktioner från loggen till den punkt som ligger närmast det ögonblick då felet inträffade.

Arbetsbänk

För databasdesign och utveckling, testning och underhåll i MySQL och MariaDB kan vi använda en Windows-applikation Workbench. Det fungerar på Linux också. Med denna applikation kan användare designa databaser, visa och ändra metadata, överföra data och metadata och mycket mer. Det är värt att tillägga att det är möjligt att använda dbForge Studio för MySQL istället för Workbench.

Slutsats

Sammantaget har vi kort diskuterat och illustrerat databassäkerhetskopiering och återställningstekniker med verktyg och metoder tillgängliga i MySQL och MariaDB.

För att framgångsrikt återställa databassystemet från eventuella fel måste vi implementera både fysisk och logisk säkerhetskopiering metoder som nämns ovan i policyerna och planerna, från hela systemet ner till enskilda tabeller.

För att utföra en PITR framgångsrikt behöver vi bin-log aktiverad och korrekt logghanteringsbehov på plats.

Men att använda bara en säkerhetskopieringsmetod och saknade bin-loggar skulle vara fel tillvägagångssätt. Det kan resultera i dataförlust och skada din applikations affärskontinuitet. Kombinera därför olika metoder och inkludera alltid loggfilerna i säkerhetskopierings- och återställningspolicyn!