Een essentieel onderdeel van het voorkomen van gegevensverlies in elke situatie is het hebben van een geschikt back-up- en herstelbeleid. Het is ook essentieel om op elk moment van de levenscyclus van de applicatieworkflow te zorgen voor gegevensherstel. Zowel MySQL als MariaDB bieden oplossingen voor deze gevallen. In dit artikel worden de bestaande opties en procedures onderzocht, evenals andere mogelijke back-upopties voor MySQL en MariaDB.
Back-upstrategieën
Aangezien data het belangrijkste onderdeel van elke applicatie is, is het beschermen van de integriteit ervan van vitaal belang om te overleven in de strijd om het bestaan. Elke verstoring van de toegankelijkheid of integriteit van gegevens voor eender welk moment zal waarschijnlijk de applicatie en het bedrijf/de dienst die het levert ernstig schaden.
Om een succesvolle applicatieworkflow en bedrijfscontinuïteit te garanderen, moet u een geschikt back-up- en herstelbeleid implementeren met dagelijkse, wekelijkse, maandelijkse en jaarlijkse back-ups. Dergelijke back-ups worden uitgevoerd in kritieke perioden, zoals:
- vóór een dagelijks batchvenster;
- vóór massale gegevensopname;
- vóór een applicatie-upgrade;
- wekelijkse, maandelijkse en jaarlijkse back-ups om te voldoen aan wettelijke vereisten;
- of ander dagelijks/wekelijks gepland onderhoud.
Back-uptools
MySQL en MariaDB bieden verschillende manieren om back-up- en herstelplannen op te zetten en uit te voeren. Deze methoden omvatten fysieke back-ups met MySQL's Enterprise mysqlbackup-tool , MariaDB's mariabackup-tool , of Percona's XtraBackup-tool . Ook logische back-ups gemaakt met de Mysql's mysqldump tool kan van pas komen. Een andere optie is de point-in-time recovery met de databases bin-logs (de transactielogs) in combinatie met de eerder genoemde tools.
U kunt geschikte methoden opnemen in uw back-upstrategie om de herstelbaarheid van de database te maximaliseren in geval van een storing of calamiteit.
Opmerking:in de MariaDB-versie 10.4.6, symlink van mysqldump heet mariadb-dump . In de latere versies, waaronder 10.5.2, zijn de namen opnieuw veranderd - mysqldump werd symlink .
Om de procedures te illustreren, gebruik ik de mariabackup-tool om fysieke back-ups te maken. De basisfunctionaliteit van de tool is hetzelfde als in de bovengenoemde tools, hoewel er enkele kleine verschillen zijn die uniek zijn voor elke tool.
Fysieke databaseback-ups
Fysieke back-ups zijn back-ups op bestandsniveau die u snelle methoden voor het kopiëren van bestanden bieden. Dergelijke back-ups hebben de voorkeur in scenario's voor noodherstel, het klonen van databases en/of het maken van slave-databases.
Bij het maken van fysieke back-ups kunt u ervoor kiezen om volledige of incrementele back-ups te maken. Volledige back-ups omvatten een volledige back-up van de databaseserver. Incrementele back-ups slaan alleen wijzigingen op van de laatste volledige of incrementele back-up.
Belangrijk:De grootte van de database regelt het tijdstip van de back-up. Om die reden kan een goede strategie voor het maken van een back-up van een zeer grote database zijn om volledige en incrementele back-ups te combineren. Op deze manier bespaart u zowel de opslagruimte voor back-ups als de totale back-up- en hersteltijd.
Een ander moment dat u moet opmerken, is dat wanneer u de gegevens van een fysieke back-up herstelt, u uw MySQL/MariaDB-database-instantieproces moet stoppen totdat de laatste herstelstappen zijn voltooid.
U kunt als volgt een eenvoudige volledige fysieke back-up uitvoeren:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
De –target-dir optie vertelt de back-uptool waar de back-up moet worden geplaatst.
In dit voorbeeld heb ik mijn back-up georganiseerd in de map met de naam DYYYYMMDD waar elke volledige back-up wordt opgeslagen (D staat voor Daily). Door dit te doen, hebben we een eenvoudige manier om de database te herstellen vanaf de back-up die op een specifieke datum is gemaakt.
Het volgende voorbeeld demonstreert het uitvoeren van een eenvoudige incrementele back-up:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
De daaropvolgende incrementele back-up ziet er als volgt uit:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
De –incremental-basedir optie geeft de back-uptool de opdracht om de eerder genomen volledige of incrementele back-up te gebruiken als uitgangspunt bij het bouwen van incrementele deltabestanden voor de huidige back-up. Op deze manier bouwt het een keten op van één volledige back-up met daaropvolgende incrementele back-ups. Samen vormen ze één enkele back-up die u indien nodig kunt herstellen.
Laten we nu eens kijken wat de naam is van het fysieke databasebestand waarin alle directorygegevens zijn opgeslagen. De database die zich op Domain Controllers bevindt, is een Active Directory. Deze directory wordt gebruikt om gebruikers, gegevens, enz. te beheren. De kern van een Active Directory is het NTDS.DIT-databasebestand dat bestaat uit een link, een beveiligingsdescriptor en datatabellen. Alle directorygegevens worden bewaard in dit fysieke databasebestand.
Het is noodzakelijk om onderscheid te maken tussen fysieke en logische bestanden. Werkelijke systeemgegevens bevinden zich in fysieke bestanden, terwijl logische bestanden de beschrijving bevatten van records die zijn opgeslagen in fysieke bestanden.
Het herstellen van de MySQL-database vanuit fysieke bestanden kan soms moeilijk zijn. De mysqldump commando kan in dit geval nuttig zijn. We zullen dit onderwerp verder behandelen.
Logische databaseback-ups
Logische back-ups worden gemaakt met de mysqldump hulpmiddel. Deze back-upmethode is flexibeler dan fysieke back-up. Het bestaat uit alle DML- en/of DDL SQL-instructies die nodig zijn om een consistente back-up te vormen, waarbij alle vastgelegde gegevens en wijzigingen die vóór en tijdens de back-up zijn aangebracht, worden gecombineerd. Als je meer wilt weten over het maken van back-ups en het herstellen van alle databases, kun je dit artikel lezen.
De logische back-up kan een enkel bestand zijn of meerdere bestanden (gemaakt met een specifiek script). Verder kunt u de structuur en/of gegevens herstellen zonder uw MySQL/MariaDB-instantie (proces) af te sluiten. Dienovereenkomstig worden logische back-ups uitgevoerd op database- en/of tabelniveau, terwijl fysieke back-ups op bestandssysteemniveau (directories en bestanden) plaatsvinden.
Merk ook op dat logische back-ups uitsluitend volledige back-ups zijn van afbeeldingen van de beoogde databases en/of tabellen.
Hieronder staat het maken van een logische back-up van de gehele MySQL/MariaDB-instantie:
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
Merk op dat fysieke back-ups en logische back-ups specifiek worden onderscheiden in het bestandssysteem voor back-upbeheerdoeleinden.
In tegenstelling tot het vorige voorbeeld wordt een logische back-up van een enkele database (schema) op de volgende manier gemaakt:
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
Ten slotte, om een logische back-up van een enkele tabel in een database te maken, voegt u de naam van de tabel toe na de database:
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
Wanneer u de DROP DATABASE- of DROP TABLE-instructies moet bewerken en toevoegen aan het herstelscenario, kan het werken met grote back-upbestanden beperkende effecten hebben op teksteditors tot ze stikken.
Overweeg in dergelijke gevallen andere opties toe te voegen, zoals –add-drop-database en/of –add-drop-table om deze DROP-instructies in de back-up op te nemen. In andere scenario's wilt u deze uitspraken misschien uitsluiten en vervangen door de –skip-add-drop-tabel optie voor het commando.
U kunt echter ook back-ups met alleen gegevens of alleen DDL maken met –no-create-info of –geen gegevens opties. Afzonderlijke back-ups van gegevens en structuren kunnen in sommige herstelscenario's een goede keuze zijn, vooral wanneer u alleen de DDL-structuur nodig hebt om een lege gekloonde database en/of de bijbehorende tabellen te maken.
Back-up van database maken met schijfsnapshots
Naarmate de gegevens groeien, kan het nodig zijn deze op verschillende schijven en/of bestandssystemen te ordenen. Naast de prestatieredenen, aangezien I/O wordt verdeeld over meerdere schijven/bestandssystemen, moet u ervoor zorgen dat efficiënte back-up- en herstelstrategieën de schijf- en bestandssysteem-snapshotmogelijkheden omvatten.
Begin met het ontwerpen en bouwen van de bestandssysteemlay-outs waarin elke database, groep tabellen en indexen zich bevinden. Organiseer vervolgens uw tabellen en configureer het databasesysteem. Ze moeten ofwel allemaal in een enkele map staan:
innodb_home_dir = /<path where your InnoDB tables will reside>Of u kunt de DATA_DIRECTORY . gebruiken en INDEX_DIRECTORY opties in de CREATE table-statement om ze afzonderlijk te distribueren naar verschillende bestandssysteemlocaties.
Zorg ervoor dat u voor InnoDB file_per_table =ON . gebruikt (standaard AAN in de nieuwste versies). Kies het pad voor de InnoDB-tabellen zorgvuldig wanneer u ze maakt. Het is onmogelijk om het pad te wijzigen zonder de tabel te laten vallen en opnieuw aan te maken.
Het is handig om de juiste bestandssystemen te hebben met ingebouwde snapshot-mogelijkheden, b.v. XFS en ZFS op Linux. Merk op dat het maken van snapshot-back-ups vergelijkbaar is met het maken van fysieke back-ups, maar het heeft specifieke kenmerken. Het vereist het stoppen van het schrijfproces (FLUSH met READ LOCK of iets dergelijks — zie de BACKUP-FASE commando in de MariaDB online documentatie) voordat u de momentopname maakt en LOCKS releasing loslaat onmiddellijk na het voltooien van de momentopname. Het is noodzakelijk om gegevensconsistentie te waarborgen.
U moet de snapshot-back-ups overwegen en gebruiken in scenario's voor noodherstel. Ze zijn echter ook geschikt voor het klonen van database-instanties.
Herstelstrategieën
Herstel van fysieke back-ups
Eerder hebben we de fysieke back-upstappen beschreven. Op deze manier kunt u ofwel een keten van volledige back-ups opbouwen of een keten van volledige en incrementele back-ups. De laatste optie betekent dat een volledige back-up gevolgd door een daaropvolgende incrementele back-up nul is als er een storing optreedt.
Een DBA maakt bijvoorbeeld volledige back-ups op zondag en incrementele back-ups op andere dagen. Er treedt een storing op na het maken van een incrementele back-up op woensdag. Daarom moeten ze de database herstellen. Onder dergelijke omstandigheden moet onze DBA de volledige back-up gebruiken die op zondag is gemaakt en incrementele back-ups die op maandag, dinsdag en woensdag zijn gemaakt. Als er dagelijks volledige back-ups zouden zijn, zou het voldoende zijn om de back-up van woensdag te herstellen.
Om de "dichtstbijzijnde" back-up te herstellen na een storing, of het nu een volledige of incrementele back-up is, moet u ervoor zorgen dat ALLE back-upbestanden consistent zijn op een bepaald tijdstip met de tijd van de dichtstbijzijnde back-upfinish. Anders zal de InnoDB-engine de gegevens weigeren door deze als corrupt te beschouwen.
Een ander belangrijk punt is dat wanneer u back-ups maakt, de betrokken volledige back-ups naar een andere locatie kopieert voordat u de stappen toepast om consistentie op een bepaald tijdstip te garanderen. Op deze manier behoudt u de oorspronkelijke back-upstatus, wat later van pas kan komen. Ik raad ten zeerste aan om je aan deze aanpak te houden.
Om een volledige back-up voor te bereiden, kiest u de back-up die het dichtst bij de storing ligt, kopieert u deze naar de gewenste locatie en voert u de volgende opdracht uit:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Om te herstellen naar de dichtstbijzijnde incrementele back-up, maak een kopie van de dichtstbijzijnde volledige back-up en voeg alle relevante incrementele back-ups toe in een volgende bestelling . De herstelde database-afbeelding zou als volgt moeten zijn:
We bereiken dit door de prepare . uit te voeren commando voor elke incrementele back-up zoals hieronder getoond:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Nadat we de reservekopie hebben gemaakt, moeten we de database-instantie afsluiten (Verwerken). Ook moeten we de . leegmaken databasemap voordat u het herstelproces voltooit. U kunt ofwel de opdracht geven met de –copy-back optie
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
of met de –move-back optie:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
De laatste opdracht verplaatst de gekopieerde directory naar de databasedirectory. Het kopiëren van de originele back-up naar een andere locatie is een verstandige keuze. Anders gaat de back-up verloren, omdat deze niet voor andere situaties en scenario's kan worden gebruikt.
De laatste stap voordat de database-instantie wordt gestart, is om het eigendom van de bestanden aan te passen aan de gebruiker en de groep van de proceseigenaar. Meestal is dit MySQL.
Herstel van logische back-ups
Heel vaak zien we een belangrijk punt over het hoofd bij het herstellen van databases en/of tabellen met behulp van logische back-ups. Dit punt is het instellen van het max_allowed_packet grootte van de sessie (het kan verstandiger zijn om deze globaal in te stellen) op de maximale waarde van 1073741824. Het is noodzakelijk om ervoor te zorgen dat grote buffers en INSERT-instructies in een enkel pakket tussen de client en de server passen. Dit zou de hersteltijd moeten verkorten.
Een ander belangrijk aspect bij het maken van een back-up is het opnemen of uitsluiten van de DROP-instructies zoals eerder vermeld. We hebben het nodig om het back-upherstelproces zo soepel mogelijk te laten verlopen. Gebruik daarom de onderstaande code om de back-upherstel uit te voeren:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlAls u geen database in de back-up hebt opgenomen, zoals bij individuele databaseback-ups, of als u het herstel naar een andere database moet omleiden, gebruikt u een andere code:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlHerstel met schijf-snapshots
Om te herstellen van de schijf-snapshot altijd begin met ervoor zorgen dat het databasesysteem vooraf wordt afgesloten het herstelproces wordt uitgevoerd . Elke poging om een live database te herstellen met behulp van de schijf-snapshot zal resulteren in inconsistenties in de gegevens en, meer waarschijnlijk, gegevensbeschadiging.
Herstel op een bepaald moment
Point-in-time recovery (PITR) is, zoals de naam al aangeeft, een methode om databases en tabellen zo dicht mogelijk bij de tijd voor de storing te herstellen. Of, als het dagelijkse batchproces is mislukt en opnieuw moet worden uitgevoerd, hebt u ook de enige optie:PITR-back-upherstel uitvoeren.
Het is essentieel om de database bin-log in te schakelen en de bin-log-indeling in te stellen op Statement-Based, Row-Based of Mixed logging, afhankelijk van het type werkbelasting dat uw database uitvoert. Verder moet u mogelijk compressie inschakelen met log_bin_compress =ON (standaard UIT) om schijfruimte te besparen.
Aangezien bin-log een transactielogboek is en in een reeks wordt gemaakt, is het cruciaal om een back-up te maken van alle logbestanden. Wat betreft het PITR-proces, het is onmogelijk zonder logbestanden. Bovendien moeten het onderhoud en de levenscyclus van de bin-log de levenscyclus van alle volledige en incrementele back-ups volgen. Zorg er dus voor dat u alleen de logboeken opschoont die ouder zijn dan de oudste back-up in het back-upbeleid.
U kunt binaire logboeken op twee manieren opschonen. Ten eerste door de dichtstbijzijnde bin-lognaam te declareren bij de oudste back-up, zoals weergegeven in de onderstaande opschoonopdracht:
PURGE BINARY LOGS TO 'mariadb-bin.000063';Ten tweede is het door de datum van de oudste back-up die is bewaard in het opschooncommando aan te geven:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Om ons voor te bereiden op herstel, moeten we alle noodzakelijke verklaringen ophalen om opnieuw af te spelen tot het noodzakelijke tijdstip. Verzamel alle beschikbare bin-logs vanaf het moment dat de back-up begon tot het moment dat u aan het herstellen bent.
Begin met het bekijken van de loglijst vanaf het moment dat de back-up eindigde tot de PITR-tijd:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Bekijk vervolgens de tijdelijke bestanden om de exacte logposities te vinden die u wilt toepassen en gebruiken. Dit zijn –startpositie en –stoppositie die de exacte posities in de opdracht instellen en de mysqlbinlog . opnieuw uitvoeren commando:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
Op dit punt is het herstelproces begonnen. Het maakt gebruik van fysieke of logische back-ups, volledig of incrementeel.
Voltooi het herstel door de final_temporary_PITR_file.sql toe te passen met behulp van de MySQL-client zoals hieronder weergegeven:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlWe hebben het PITR-herstel voltooid door de back-up en herhaalde transacties van het logboek te herstellen naar het dichtstbijzijnde punt tot het moment waarop de fout zich voordeed.
Werkbank
Voor database ontwerp en ontwikkeling, testen en onderhoud in MySQL en MariaDB kunnen we gebruik maken van een Windows applicatie Workbench. Het werkt ook op Linux. Met deze applicatie kunnen gebruikers databases ontwerpen, metadata bekijken en wijzigen, data en metadata overdragen en nog veel meer. Het is de moeite waard om toe te voegen dat het mogelijk is om dbForge Studio for MySQL te gebruiken in plaats van Workbench.
Conclusie
Al met al hebben we de technieken voor back-up en herstel van databases kort besproken en geïllustreerd met tools en methoden die beschikbaar zijn in MySQL en MariaDB.
Om het databasesysteem met succes te herstellen van een storing, moeten we zowel fysieke als logische back-up . implementeren bovengenoemde methoden in het beleid en de plannen, van het hele systeem tot individuele tabellen.
Om een PITR met succes uit te voeren, hebben we de bin-log ingeschakeld en een goed logbeheer nodig op zijn plaats.
Het gebruik van slechts één back-upmethode en ontbrekende bin-logs zou echter de verkeerde benadering zijn. Het kan leiden tot gegevensverlies en de bedrijfscontinuïteit van uw toepassing schaden. Combineer dus verschillende methoden en neem altijd de logbestanden op in het back-up- en herstelbeleid!