Důležitou součástí prevence jakékoli ztráty dat v jakékoli situaci je mít vhodné zásady zálohování a obnovy. Je také nezbytné zajistit obnovu dat v kterémkoli okamžiku životního cyklu pracovního postupu aplikace. Řešení pro tyto případy nabízí MySQL i MariaDB. Tento článek prozkoumá stávající možnosti a postupy a také další potenciální možnosti zálohování pro MySQL a MariaDB.
Strategie zálohování
Protože data jsou nejdůležitější součástí každé aplikace, ochrana jejich integrity je zásadní pro přežití v bitvě o existenci. Jakékoli narušení dostupnosti nebo integrity dat na jakoukoli dobu pravděpodobně vážně poškodí aplikaci a obchod/službu, kterou poskytuje.
Chcete-li zajistit úspěšný pracovní postup aplikací a kontinuitu podnikání, musíte implementovat vhodné zásady zálohování a obnovy s denními, týdenními, měsíčními a ročními zálohami. Takové zálohy budou probíhat v kritických obdobích, jako jsou:
- před denním dávkovým oknem;
- před masivním zpracováním dat;
- před jakýmkoli upgradem aplikace;
- týdenní, měsíční a roční zálohy pro splnění regulačních požadavků;
- nebo jinou denní/týdenní plánovanou údržbu.
Zálohovací nástroje
MySQL a MariaDB nabízejí několik způsobů, jak nastavit a spustit plány zálohování a obnovy. Tyto metody zahrnují fyzické zálohování pomocí nástroje MySQL Enterprise mysqlbackup , nástroj mariabackup společnosti MariaDB nebo nástroj XtraBackup společnosti Percona . Také logické zálohy vytvořené pomocí nástroje Mysql's mysqldump může přijít vhod. Další možností je obnovení v určitém okamžiku pomocí databázových bin-logů (protokolů transakcí) v kombinaci s výše zmíněnými nástroji.
Do své strategie zálohování můžete začlenit vhodné metody, abyste maximalizovali obnovitelnost databáze v případě selhání nebo katastrofy.
Poznámka:Ve verzi MariaDB 10.4.6 symlink mysqldump se nazývá mariadb-dump . V pozdějších verzích, včetně 10.5.2, se názvy opět změnily – mysqldump se stal symlinkem .
Pro ilustraci postupů použiji nástroj mariabackup k vytváření fyzických záloh. Základní funkce nástroje jsou stejné jako u výše uvedených nástrojů, i když existují určité drobné rozdíly, které jsou jedinečné pro každý nástroj.
Fyzické zálohy databáze
Fyzické zálohy jsou zálohy na úrovni souborů, které vám poskytují rychlé metody kopírování souborů. Takové zálohy jsou vhodnější ve scénářích obnovy po havárii, klonování databází a/nebo vytváření podřízených databází.
Při vytváření fyzických záloh si můžete vybrat, zda chcete vytvořit plné nebo přírůstkové zálohy. Úplné zálohy zahrnují kompletní zálohu databázového serveru. Přírůstkové zálohy ukládají pouze změny z poslední plné nebo přírůstkové zálohy.
Důležité:Velikost databáze určuje dobu zálohování. Z tohoto důvodu může být dobrou strategií pro zálohování velmi velké databáze kombinovat plné a přírůstkové zálohy. Tímto způsobem ušetříte jak úložný prostor pro zálohy, tak celkovou dobu zálohování a obnovy.
Dalším momentem, kterého byste si měli všimnout, je, že když obnovujete data z fyzické zálohy, musíte zastavit proces instance databáze MySQL/MariaDB, dokud nebudou dokončeny poslední kroky obnovy.
Provedení jednoduché úplné fyzické zálohy můžete provést následovně:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220 \
--user=backupuser --password=backuppasswd
–target-dir Tato možnost říká zálohovacímu nástroji, kam má zálohu umístit.
V tomto příkladu jsem uspořádal zálohu do adresáře s názvem RRRRMMDD kde je uložena každá plná záloha (D znamená Daily). Díky tomu máme snadný postup k obnovení databáze ze zálohy pořízené k určitému datu.
Další příklad ukazuje provádění jednoduché přírůstkové zálohy:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc1/ \
--incremental-basedir=/data/backups/mariadb/D20210220/ \
--user=backupuser --password=backuppasswd
Následná přírůstková záloha by vypadala takto:
mariabackup --backup \
--target-dir=/data/backups/mariadb/D20210220_inc2/ \
--incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
--user=backupuser --password=backuppasswd
– inkrementální-basedir Volba dává nástroji zálohování pokyn, aby použil dříve pořízenou plnou nebo přírůstkovou zálohu jako výchozí bod při vytváření přírůstkových rozdílových souborů pro aktuální zálohu. Tímto způsobem vytvoří řetězec jedné plné zálohy s následnými přírůstkovými zálohami. Společně tvoří jedinou zálohu, kterou lze v případě potřeby obnovit.
Nyní zjistíme, jaký je název fyzického databázového souboru, ve kterém jsou uložena všechna data adresáře. Databáze, která je umístěna na řadičích domény, je Active Directory. Tento adresář se používá ke správě uživatelů, dat atd. Jádrem Active Directory je databázový soubor NTDS.DIT, který se skládá z odkazů, popisovačů zabezpečení a datových tabulek. Všechna data adresáře jsou uložena v tomto fyzickém databázovém souboru.
Je nutné rozlišovat mezi fyzickými a logickými soubory. Skutečná systémová data jsou umístěna ve fyzických souborech, zatímco logické soubory obsahují popis záznamů uložených ve fyzických souborech.
Úkol obnovení databáze MySQL z fyzických souborů může být někdy obtížný. mysqldump v tomto případě může být užitečný příkaz. Tímto tématem se budeme dále zabývat.
Logické zálohy databáze
Logické zálohy se vytvářejí pomocí mysqldump nářadí. Tato metoda zálohování je flexibilnější než fyzická záloha. Skládá se ze všech příkazů DML a/nebo DDL SQL nezbytných k vytvoření konzistentní zálohy, která kombinuje všechna potvrzená data a změny provedené před a během zálohování. Pokud se chcete dozvědět více o tom, jak zálohovat a obnovit všechny databáze, můžete si přečíst tento článek.
Logická záloha může být jeden soubor nebo více souborů (vytvořených specifickým skriptem). Dále můžete obnovit strukturu a/nebo data bez vypnutí instance (procesu) MySQL/MariaDB. V souladu s tím se logické zálohy provádějí na úrovni databáze a/nebo tabulky, zatímco fyzické zálohy jsou na úrovni souborového systému (adresáře a soubory).
Všimněte si také, že logické zálohy jsou výhradně obrazy úplných záloh zamýšlených databází a/nebo tabulek.
Vytvoření logické zálohy celé instance MySQL/MariaDB je uvedeno níže:
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
Všimněte si, že fyzické zálohy a logické zálohy jsou specificky rozlišovány v souborovém systému pro účely správy záloh.
Na rozdíl od předchozího příkladu je logická záloha jedné databáze (schéma) vytvořena následujícím způsobem:
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
Nakonec, chcete-li vytvořit logickou zálohu jedné tabulky v databázi, přidejte název tabulky za databázi:
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
Když potřebujete upravit a přidat příkazy DROP DATABASE nebo DROP TABLE do scénáře obnovy, práce s velkými záložními soubory může mít omezující účinky na textové editory tak, že se dusí.
V takových případech zvažte přidání dalších možností, jako je –add-drop-database a/nebo –add-drop-table zahrnout tyto příkazy DROP do zálohy. V jiných scénářích můžete chtít tyto příkazy vyloučit a nahradit je –skip-add-drop-table možnost k příkazu.
Můžete však také vytvořit zálohy pouze pro data nebo pouze DDL pomocí –no-create-info nebo –žádná data možnosti. Oddělené zálohy dat a struktur mohou být dobrou volbou v některých scénářích obnovy, zvláště když potřebujete strukturu DDL pouze k vytvoření prázdné klonované databáze a/nebo jejích tabulek.
Zálohování databáze pomocí snímků disku
Jak data rostou, může být nutné je uspořádat na několik disků a/nebo souborových systémů. Kromě důvodů výkonu, protože I/O je distribuován na více disků/systémů souborů, musíte zajistit, aby efektivní strategie zálohování a obnovy zahrnovaly možnosti snímku disku a souborového systému.
Začněte tím, že navrhnete a vytvoříte rozložení souborového systému, kde sídlí každá databáze, skupina tabulek a indexy. Poté uspořádejte tabulky a nakonfigurujte databázový systém. Všechny by měly být umístěny v jediném adresáři:
innodb_home_dir = /<path where your InnoDB tables will reside>Nebo můžete použít DATA_DIRECTORY a INDEX_DIRECTORY možnosti v CREATE table k jejich samostatné distribuci do různých umístění souborového systému.
Pro InnoDB se ujistěte, že používáte file_per_table =ON (výchozí ON v nejnovějších verzích). Při vytváření tabulek InnoDB pečlivě vyberte cestu. Není možné změnit cestu, aniž byste tabulku zrušili a znovu vytvořili.
Je užitečné mít správné souborové systémy s vestavěnými schopnostmi snímků, např. XFS a ZFS na Linuxu. Všimněte si, že vytváření záloh snímků je podobné vytváření fyzických záloh, ale má svá specifika. Vyžaduje zastavení procesu zápisu (FLUSH with READ LOCK nebo podobné — viz FÁZE ZÁLOHY příkaz v online dokumentaci MariaDB), než pořídíte snímek a uvolníte LOCKS ihned po dokončení snímku. Je nutné zajistit konzistenci dat.
Měli byste zvážit a použít zálohy snímků ve scénářích obnovy po havárii. Jsou však také vhodné pro klonování instancí databáze.
Strategie obnovy
Obnova z fyzických záloh
Dříve jsme popsali kroky fyzického zálohování. Tímto způsobem můžete buď vytvořit řetězec plných záloh, nebo řetězec plných a přírůstkových záloh. Druhá možnost znamená, že plná záloha následovaná následnou přírůstkovou zálohou je bod nula, pokud dojde k selhání.
DBA například provádí plné zálohy v neděli a přírůstkové zálohy v jiné dny. Po vytvoření přírůstkové zálohy ve středu dojde k selhání. Proto potřebují obnovit databázi. Za takových okolností musí náš DBA použít plnou zálohu vytvořenou v neděli a přírůstkové zálohy vytvořené v pondělí, úterý a středu. Pokud by existovaly denní plné zálohy, stačilo by obnovit středeční zálohu.
Chcete-li po selhání obnovit „nejbližší“ zálohu, ať už se jedná o plnou nebo přírůstkovou zálohu, musíte zajistit, aby VŠECHNY záložní soubory byly konzistentní v časovém okamžiku s časem nejbližšího ukončení zálohování. Jinak engine InnoDB odmítne data tím, že je bude považovat za poškozená.
Dalším klíčovým bodem je, že když připravujete zálohy, zkopírujte příslušné plné zálohy do jiného umístění před použitím kroků k zajištění konzistence v určitém okamžiku. Tímto způsobem zachováte původní stav zálohy, což se může hodit později. Důrazně doporučuji používat tento přístup.
Chcete-li připravit úplnou zálohu, vyberte tu, která je nejblíže k selhání, zkopírujte ji do preferovaného umístění a spusťte následující příkaz:
mariabackup --prepare \
--target-dir=data/backups/mariadb/COPY_D20210220
Chcete-li obnovit do nejbližší přírůstkové zálohy, připravte si kopii nejbližší plné zálohy a přidejte všechny relevantní přírůstkové zálohy v následné objednávce . Obraz obnovené databáze by měl vypadat následovně:
Toho dosáhneme provedením prepare příkaz pro každou přírůstkovou zálohu, jak je uvedeno níže:
mariabackup --prepare \
--target-dir=/data/backups/mariadb/COPY_D20210220 \
--incremental-dir=/data/backups/mariadb/D20210220_INC#
Po přípravě záložní kopie musíme vypnout instanci databáze (proces). Také musíme vyprázdnit adresář databáze před dokončením procesu obnovy. Příkaz můžete zadat pomocí –copy-back možnost
mariabackup --copy-back \
--target-dir=data/backups/mariadb/COPY_D20210220
nebo pomocí –move-back možnost:
mariabackup --move-back \
--target-dir=data/backups/mariadb/COPY_D20210220
Poslední příkaz přesune zkopírovaný adresář do adresáře databáze. Kopírování původní zálohy do jiného umístění je moudrá volba. V opačném případě bude záloha ztracena, protože ji nebude možné použít pro jiné situace a scénáře.
Posledním krokem před spuštěním instance databáze je upravit vlastnictví souborů tak, aby odpovídalo uživateli a skupině vlastníka procesu. Obvykle je to MySQL.
Obnova z logických záloh
Poměrně často přehlížíme jeden klíčový bod při obnově databází a/nebo tabulek pomocí logických záloh. Tímto bodem je nastavení max_allowed_packet velikost relace (možná bude rozumnější nastavit ji globálně) na maximální hodnotu 1073741824. Je nutné zajistit, aby se velké buffery a příkazy INSERT vešly do jednoho paketu mezi klientem a serverem. To by mělo zkrátit dobu obnovy.
Dalším klíčovým aspektem při vytváření zálohy je zahrnutí nebo vyloučení příkazů DROP, jak bylo zmíněno dříve. Potřebujeme to, abychom zajistili co nejhladší průběh procesu obnovení zálohy. S ohledem na to použijte k provedení obnovení zálohy níže uvedený kód:
mysql -u backupuser -p backuppasswd < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlPokud nemáte žádnou databázi zahrnutou v záloze, jako u jednotlivých záloh databází, nebo potřebujete přesměrovat obnovu do jiné databáze, použijte jiný kód:
mysql -u backupuser -p backuppasswd newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sqlObnova pomocí snímků disku
Chcete-li obnovit ze snímku disku vždy začněte tím, že zajistíte že databázový systém je předtím vypnut proces obnovy se provede . Jakýkoli pokus o obnovu živé databáze pomocí snímku disku bude mít za následek nekonzistenci dat a pravděpodobněji poškození dat.
Obnova v určitém okamžiku
Obnova bodu v čase (PITR) je, jak název napovídá, metodou pro obnovu databází a tabulek co nejblíže době před selháním. Nebo, pokud selhal denní dávkový proces a je třeba jej znovu spustit, máte také jedinou možnost – provést obnovu zálohy PITR.
Je životně důležité povolit bin-log databáze a nastavit formát bin-log buď na Statement-Based, Row-Based nebo Mixed logging, v závislosti na typu zátěže, na které vaše databáze běží. Dále může být nutné povolit kompresi pomocí log_bin_compress =ON (výchozí OFF) pro úsporu místa na disku.
Vzhledem k tomu, že bin-log je protokol transakcí a vytváří se v sekvenci, je důležité vytvořit zálohu všech souborů protokolu. Pokud jde o proces PITR, ten je nemožný bez souborů protokolu. Kromě toho by údržba a životní cyklus bin-logu měly sledovat životní cyklus všech úplných a přírůstkových záloh. Proto se ujistěte, že vyčistíte pouze protokoly, které jsou starší než nejstarší záloha v zásadách zálohování.
Binární protokoly můžete vyčistit dvěma způsoby. Nejprve je to deklarováním nejbližšího názvu bin-log k nejstarší záloze, jak je znázorněno v níže uvedeném příkazu čištění:
PURGE BINARY LOGS TO 'mariadb-bin.000063';Za druhé, je to deklarováním data nejstarší zálohy uchovávané v příkazu čištění:
PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';Abychom se připravili na zotavení, musíme získat všechna potřebná prohlášení, abychom je mohli přehrát do potřebného okamžiku. Shromážděte všechny dostupné bin-logy od začátku zálohování až do okamžiku, kdy obnovujete.
Začněte prozkoumáním seznamu protokolů od okamžiku ukončení zálohování do času PITR:
mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql
Poté prozkoumejte dočasné soubory a najděte přesné pozice protokolu, které chcete použít a použít. Jedná se o – start-position a –stop-position které nastaví přesné pozice v příkazu a znovu spustí mysqlbinlog příkaz:
mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql
V tomto okamžiku začal proces obnovy. Používá buď fyzické nebo logické zálohy, plné nebo přírůstkové.
Dokončete obnovu použitím souboru final_temporary_PITR_file.sql pomocí klienta MySQL, jak je uvedeno níže:
mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sqlDokončili jsme obnovu PITR obnovením zálohovaných a přehraných transakcí z protokolu na nejbližší bod k okamžiku výskytu selhání.
Pracovní plocha
Pro návrh a vývoj databází, testování a údržbu v MySQL a MariaDB můžeme použít Windows aplikaci Workbench. Funguje to i na Linuxu. Pomocí této aplikace mohou uživatelé navrhovat databáze, zobrazovat a měnit metadata, přenášet data a metadata a mnoho dalšího. Stojí za to dodat, že místo Workbench je možné použít dbForge Studio pro MySQL.
Závěr
Celkově jsme stručně probrali a ilustrovali techniky zálohování a obnovy databáze pomocí nástrojů a metod dostupných v MySQL a MariaDB.
Abychom úspěšně obnovili databázový systém z jakéhokoli selhání, musíme implementovat fyzickou i logickou zálohu výše uvedených metod do politik a plánů, od celého systému až po jednotlivé tabulky.
Abychom úspěšně provedli PITR, potřebujeme aktivovaný bin-log a náležitou správu protokolů na místě.
Použití pouze jedné metody zálohování a chybějících bin-logů by však byl špatný přístup. Může to vést ke ztrátě dat a poškodit kontinuitu podnikání vaší aplikace. Proto kombinujte různé metody a vždy zahrňte soubory protokolu do zásad zálohování a obnovy!