En vigtig del af at forhindre enhver form for tab af data i enhver situation er at have passende sikkerhedskopierings- og gendannelsespolitikker. Det er også vigtigt at sikre datagendannelse på et hvilket som helst tidspunkt i applikationens arbejdsprocess livscyklus. Både MySQL og MariaDB tilbyder løsninger til disse tilfælde. Denne artikel vil undersøge de eksisterende muligheder og procedurer samt andre potentielle sikkerhedskopieringsmuligheder for MySQL og MariaDB.
Sikkerhedskopieringsstrategier
Da data er den vigtigste del af enhver applikation, er beskyttelse af dens integritet afgørende for at overleve i kampen om tilværelsen. Enhver afbrydelse af datatilgængeligheden eller integriteten til enhver tid vil sandsynligvis skade applikationen og den virksomhed/tjeneste, den leverer, alvorligt.
For at sikre en vellykket applikations-workflow og forretningskontinuitet skal du implementere passende sikkerhedskopierings- og gendannelsespolitikker med daglige, ugentlige, månedlige og årlige sikkerhedskopier. Sådanne sikkerhedskopier vil køre i kritiske perioder, såsom:
- før et dagligt batchvindue;
- før massive dataindtagelser;
- før enhver applikationsopgradering;
- ugentlig, månedlig og årlig sikkerhedskopiering for at opfylde lovkrav;
- eller anden daglig/ugentlig planlagt vedligeholdelse.
Sikkerhedskopieringsværktøjer
MySQL og MariaDB tilbyder flere måder at opsætte og udføre backup- og gendannelsesplaner på. Disse metoder omfatter fysiske sikkerhedskopier med MySQL's Enterprise mysqlbackup-værktøj , MariaDBs mariabackup-værktøj , eller Perconas XtraBackup-værktøj . Også logiske sikkerhedskopier oprettet med Mysqls mysqldump-værktøj kan komme til nytte. En anden mulighed er punkt-i-tidsgendannelse med databasernes bin-logs (transaktionsloggene) i kombination med de værktøjer, der er nævnt tidligere.
Du kan assimilere passende metoder i din sikkerhedskopieringsstrategi for at maksimere databasens retablering i tilfælde af fejl eller katastrofe.
Bemærk:I MariaDB version 10.4.6, mysqldumps symbollink kaldes mariadb-dump . I de senere versioner, inklusive 10.5.2, blev navnene ændret igen – mysqldump blev symlink .
For at illustrere procedurerne vil jeg bruge mariabackup-værktøjet at lave fysiske backups. Værktøjets grundlæggende funktionalitet er den samme som i de førnævnte værktøjer, selvom der er nogle små forskelle, der er unikke for hvert værktøj.
Sikkerhedskopier af fysiske databaser
Fysiske sikkerhedskopier er sikkerhedskopier på filniveau, der giver dig hurtige filkopieringsmetoder. Sådanne sikkerhedskopier er at foretrække i scenarier for gendannelse af katastrofer, kloning af databaser og/eller oprettelse af slavedatabaser.
Når du laver fysiske sikkerhedskopier, kan du vælge at oprette fuld eller trinvis sikkerhedskopiering. Fuld backup inkluderer en komplet backup af databaseserveren. Inkrementelle sikkerhedskopier gemmer kun ændringer fra den sidste fulde eller trinvise sikkerhedskopiering.
Vigtigt:Størrelsen af databasen regulerer tidspunktet for sikkerhedskopieringen. Af den grund kan en god strategi til backup af en meget stor database være at kombinere fulde og trinvise backups. På denne måde sparer du både backup-lagerplads og den samlede backup- og gendannelsestid.
Et andet øjeblik, du bør bemærke, er, at når du gendanner dataene fra en fysisk sikkerhedskopi, skal du stoppe din MySQL/MariaDB-databaseforekomstproces, indtil de sidste gendannelsestrin er gennemført.
Du kan udføre udførelsen af en simpel fuld fysisk backup som følger:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
–target-dir option fortæller sikkerhedskopieringsværktøjet, hvor sikkerhedskopien skal placeres.
I dette eksempel har jeg organiseret min sikkerhedskopi i mappen DÅÅÅÅMMDD hvor hver fuld backup er gemt (D står for Daily). På den måde har vi en nem fremgangsmåde til at gendanne databasen fra sikkerhedskopien taget på en bestemt dato.
Det næste eksempel viser udførelse af en simpel trinvis sikkerhedskopiering:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
Den efterfølgende trinvise sikkerhedskopiering ville se ud i følgende retning:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
Den –inkrementelle-baserede oversigt option instruerer sikkerhedskopieringsværktøjet til at bruge den tidligere taget fulde eller trinvise backup som udgangspunkt i opbygningen af trinvise deltafiler til den aktuelle backup. På denne måde bygger den en kæde af én fuld backup med efterfølgende trinvise sikkerhedskopier. Sammen danner de én enkelt sikkerhedskopi, der kan gendannes efter behov.
Lad os nu finde ud af, hvad der er navnet på den fysiske databasefil, hvori alle mappedata er gemt. Databasen, der er placeret på domænecontrollere, er en Active Directory. Denne mappe bruges til at administrere brugere, data osv. Kernen i en Active Directory er NTDS.DIT-databasefilen, som består af link, sikkerhedsdeskriptor og datatabeller. Alle mappedata opbevares i denne fysiske databasefil.
Det er nødvendigt at skelne mellem fysiske og logiske filer. Faktiske systemdata er placeret i fysiske filer, mens logiske filer indeholder beskrivelsen af poster gemt i fysiske filer.
Opgaven med at gendanne MySQL-databasen fra fysiske filer kan nogle gange være vanskelig. mysqldump kommando kan være nyttig i dette tilfælde. Vi vil dække dette emne yderligere.
Sikkerhedskopier af logiske databaser
Logiske sikkerhedskopier oprettes med mysqldump værktøj. Denne backupmetode er mere fleksibel end fysisk backup. Den består af alle de DML- og/eller DDL SQL-sætninger, der er nødvendige for at danne en konsistent backup, der kombinerer alle forpligtede data og ændringer foretaget før og under sikkerhedskopieringen. Hvis du vil vide mere om, hvordan du sikkerhedskopierer og gendanner alle databaser, kan du læse denne artikel.
Den logiske backup kan være en enkelt fil eller flere filer (oprettet med et specifikt script). Yderligere kan du gendanne strukturen og/eller data uden at lukke din MySQL/MariaDB-instans (proces). Derfor udføres logiske sikkerhedskopier på database- og/eller tabelniveau, mens fysiske sikkerhedskopier er på filsystemniveau (mapper og filer).
Bemærk også, at logiske sikkerhedskopier udelukkende er fuldstændige backupbilleder af de tilsigtede databaser og/eller tabeller.
Oprettelse af en logisk sikkerhedskopi af hele MySQL/MariaDB-instansen er nedenfor:
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
Bemærk, at fysiske sikkerhedskopier og logiske sikkerhedskopier skelnes specifikt i filsystemet til sikkerhedskopieringsformål.
I modsætning til det foregående eksempel oprettes en logisk backup af en enkelt database (skema) på følgende måde:
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
Til sidst, for at oprette en logisk sikkerhedskopi af en enkelt tabel i en database, skal du tilføje tabellens navn 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 har brug for at redigere og tilføje DROP DATABASE- eller DROP TABLE-sætningerne til gendannelsesscenariet, kan arbejde med store sikkerhedskopieringsfiler have begrænsende virkninger på teksteditorer, så de kvæler.
I sådanne tilfælde kan du overveje at tilføje andre muligheder, såsom –add-drop-database og/eller –add-drop-table at inkludere disse DROP-sætninger i sikkerhedskopien. I andre scenarier vil du måske udelukke disse udsagn og erstatte dem med –skip-add-drop-tablen mulighed for kommandoen.
Du kan dog også oprette sikkerhedskopier udelukkende til data eller DDL ved hjælp af –no-create-info eller –ingen data muligheder. Separate data- og struktursikkerhedskopier kan være et godt valg i nogle gendannelsesscenarier, især når du kun har brug for DDL-strukturen til at oprette en tom klonet database og/eller dens tabeller.
Sikkerhedskopiering af database ved hjælp af disksnapshots
Efterhånden som dataene vokser, kan det blive nødvendigt at organisere dem på flere diske og/eller filsystemer. Udover ydeevneårsagerne, da I/O er fordelt på tværs af flere diske/filsystemer, skal du sikre, at effektive sikkerhedskopierings- og gendannelsesstrategier inkluderer disk- og filsystemets snapshot-funktioner.
Start med at designe og bygge filsystemlayouterne, hvor hver database, gruppe af tabeller og indekser findes. Organiser derefter dine tabeller og konfigurer databasesystemet. De skal enten ligge alle i en enkelt mappe:
innodb_home_dir = /<path where your InnoDB tables will reside>Eller du kan bruge DATA_DIRECTORY og INDEX_DIRECTORY muligheder i OPRET tabelsætning for at distribuere dem separat til forskellige filsystemplaceringer.
For InnoDB skal du sørge for at bruge file_per_table =TIL (standard TIL i nyeste versioner). Vælg stien til InnoDB-tabellerne omhyggeligt, når du opretter dem. Det er umuligt at ændre stien uden at slippe og genskabe tabellen.
Det er nyttigt at have ordentlige filsystemer med indbyggede snapshot-funktioner, f.eks. XFS og ZFS på Linux. Bemærk, at oprettelse af snapshot-sikkerhedskopier svarer til at oprette fysiske sikkerhedskopier, men det har særlige egenskaber. Det kræver at stoppe skriveprocessen (SKYL med LÆSELÅS eller lignende — se BACKUP STAGE kommando i MariaDB online-dokumentationen), før du tager snapshottet og frigiver LOCKS umiddelbart efter færdiggørelsen af øjebliksbilledet. Det er nødvendigt at sikre datakonsistens.
Du bør overveje og bruge snapshot-sikkerhedskopierne i scenarier for gendannelse af katastrofer. Men de er også velegnede til kloning af databaseforekomster.
Gendannelsesstrategier
Gendannelse fra fysiske sikkerhedskopier
Tidligere har vi beskrevet de fysiske sikkerhedskopieringstrin. På denne måde kan du enten opbygge en kæde af fulde sikkerhedskopier eller en kæde af fulde og trinvise sikkerhedskopier. Sidstnævnte mulighed betyder, at en fuld backup efterfulgt af en efterfølgende trinvis backup er nul, hvis der opstår en fejl.
For eksempel tager en DBA fuld backup om søndagen og trinvis backup på andre dage. Der opstår en fejl efter at have lavet en trinvis sikkerhedskopiering onsdag. Derfor skal de gendanne databasen. Under sådanne omstændigheder skal vores DBA bruge den fulde backup lavet om søndagen og inkrementelle backups lavet mandag, tirsdag og onsdag. Hvis der var daglige fuld backup, ville det være tilstrækkeligt at gendanne onsdagens backup.
For at gendanne den "nærmeste" sikkerhedskopi efter en fejl, uanset om det er en fuld eller trinvis sikkerhedskopiering, skal du sikre, at ALLE backupfiler er konsistente på tidspunktet med tidspunktet for den nærmeste backup-afslutning. Ellers vil InnoDB-motoren afvise dataene ved at anse dem for korrupte.
Et andet vigtigt punkt er, når du forbereder sikkerhedskopier, kopierer de involverede fulde sikkerhedskopier til en anden placering før du anvender trinene for at sikre konsistens på tidspunktet. På denne måde bevarer du den oprindelige backup-tilstand, hvilket kan være praktisk senere. Jeg anbefaler stærkt, at du holder dig til denne tilgang.
For at forberede en fuld sikkerhedskopi skal du vælge den nærmeste til fejlen, kopiere den til den foretrukne placering og udføre følgende kommando:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
For at gendanne til den nærmeste trinvise sikkerhedskopi skal du forberede en kopi af den nærmeste fulde backup og tilføje alle relevante trinvise sikkerhedskopier i en efterfølgende rækkefølge . Det gendannede databasebillede skal være som følger:
Vi opnår dette ved at udføre forberedelsen kommando for hver trinvis sikkerhedskopiering som vist nedenfor:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Efter at have forberedt sikkerhedskopien, skal vi lukke databaseinstansen (behandle). Vi skal også tømme databasemappe før du afslutter gendannelsesprocessen. Du kan afgive kommandoen enten med –copy-back mulighed
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
eller med –move-back mulighed:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Sidstnævnte kommando flytter den kopierede mappe til databasemappen. Kopiering af den originale sikkerhedskopi til en anden placering er et klogt valg. Ellers vil sikkerhedskopien gå tabt, da den ikke kan bruges til andre situationer og scenarier.
Det sidste trin, før du starter databaseinstansen, er at justere ejerskabet af filerne, så det matcher brugeren og procesejerens gruppe. Typisk er det MySQL.
Gendannelse fra logiske sikkerhedskopier
Ganske ofte overser vi et nøglepunkt, når vi genopretter databaser og/eller tabeller ved hjælp af logiske sikkerhedskopier. Dette punkt angiver max_allowed_packet størrelsen af sessionen (det kan være klogere at sætte det globalt) til den maksimale værdi på 1073741824. Det er nødvendigt at sikre, at store buffere og INSERT-sætninger passer ind i en enkelt pakke mellem klienten og serveren. Dette burde reducere restitutionstiden.
Et andet vigtigt aspekt, når du laver en sikkerhedskopi, er at inkludere eller udelukke DROP-sætningerne som nævnt tidligere. Vi har brug for det for at sikre, at backup-gendannelsesprocessen kører så glat som muligt. Med det i tankerne skal du bruge nedenstående kode til at udføre backupgendannelsen:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlHvis du ikke har nogen database inkluderet i sikkerhedskopien, som med individuelle databasesikkerhedskopier, eller du skal omdirigere gendannelsen til en anden database, skal du bruge en anden kode:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlGendannelse med disksnapshots
altid for at gendanne fra disk-snapshot begynd med at sikre at databasesystemet er lukket ned før gendannelsesprocessen udføres . Ethvert forsøg på at gendanne en live database ved hjælp af disk-øjebliksbilledet vil resultere i datainkonsistens og, mere sandsynligt, datakorruption.
Gendannelse på tidspunkter
Point in time recovery (PITR) er, som navnet antyder, en metode til at gendanne databaser og tabeller så tæt på tiden før fejlen. Eller, hvis den daglige batchproces er mislykket og skal genudføres, har du også den eneste mulighed – gendannelse af PITR-sikkerhedskopi.
Det er vigtigt at aktivere databasens bin-log og indstille bin-log-formatet til enten Statement-Based, Row-Based eller Mixed loging, afhængigt af den type arbejdsbelastning, din database kører. Yderligere skal du muligvis aktivere komprimering ved hjælp af log_bin_compress =ON (standard FRA) for at spare diskplads.
Da bin-log er en transaktionslog og oprettet i en rækkefølge, er det afgørende at lave en backup af alle logfiler. Hvad angår PITR-processen, er det umuligt uden logfiler. Desuden bør bin-log vedligeholdelsen og livscyklussen følge livscyklussen for enhver fuld og trinvis sikkerhedskopiering. Sørg derfor for kun at rense de logfiler, der er ældre end den ældste backup i sikkerhedskopieringspolitikken.
Du kan rense binære logfiler på to måder. For det første er det ved at erklære det nærmeste bin-log navn til den ældste backup som vist i nedenstående rensekommando:
PURGE BINARY LOGS TO 'mariadb-bin.000063';For det andet er det ved at angive datoen for den ældste sikkerhedskopi, der er gemt i rensekommandoen:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';For at forberede os til bedring skal vi hente alle de nødvendige udsagn for at genafspille til det nødvendige tidspunkt. Saml alle tilgængelige bin-logs fra det tidspunkt, hvor sikkerhedskopieringen startede til det tidspunkt, hvor du genopretter.
Begynd med at undersøge loglisten fra det tidspunkt, hvor sikkerhedskopieringen sluttede til PITR-tidspunktet:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Undersøg derefter de midlertidige filer for at finde de nøjagtige logpositioner, du vil anvende og bruge. Disse er –startposition og –stop-position der indstiller de nøjagtige positioner i kommandoen og genudfører mysqlbinlog kommando:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
På dette tidspunkt er genopretningsprocessen begyndt. Den bruger enten fysiske eller logiske sikkerhedskopier, fuld eller trinvis.
Afslut gendannelsen ved at anvende final_temporary_PITR_file.sql ved at bruge MySQL-klienten som vist nedenfor:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlVi har fuldført PITR-gendannelsen ved at gendanne backup og genafspillede transaktioner fra loggen til det nærmeste punkt på tidspunktet for fejlforekomsten.
Arbejdsbænk
Til databasedesign og udvikling, test og vedligeholdelse i MySQL og MariaDB kan vi bruge en Windows-applikation Workbench. Det virker også på Linux. Med denne applikation kan brugere designe databaser, se og ændre metadata, overføre data og metadata og meget mere. Det er værd at tilføje, at det er muligt at bruge dbForge Studio til MySQL i stedet for Workbench.
Konklusion
Alt i alt har vi kort diskuteret og illustreret databasens backup- og gendannelsesteknikker med værktøjer og metoder, der er tilgængelige i MySQL og MariaDB.
For at gendanne databasesystemet fra enhver fejl, skal vi implementere både fysisk og logisk backup metoder nævnt ovenfor i politikkerne og planerne, fra hele systemet ned til individuelle tabeller.
For at udføre en PITR med succes har vi brug for bin-log-aktiverede og korrekte log-administrationsbehov på plads.
Men at bruge kun én backupmetode og manglende bin-logs ville være den forkerte tilgang. Det kan resultere i tab af data og skade din applikations forretningskontinuitet. Kombiner derfor forskellige metoder og medtag altid logfilerne i sikkerhedskopierings- og gendannelsespolitikkerne!