Zálohy – jedna z nejdůležitějších věcí, o které je třeba se starat při správě databází. Říká se, že existují dva typy lidí – ti, kteří zálohují svá data, a ti, kteří budou zálohovat svá data. V tomto příspěvku na blogu probereme osvědčené postupy týkající se zálohování a ukážeme vám, jak můžete vytvořit spolehlivý zálohovací systém pomocí ClusterControl.
Uvidíme, jak vám ClusterControl’s poskytuje centralizovanou správu zálohování pro MySQL, MariaDB, MongoDB a PostgreSQL. Poskytuje vám horké zálohy velkých datových sad, obnovu v určitém okamžiku, šifrování dat v klidu a během přenosu, integritu dat prostřednictvím ověření automatického obnovení, cloudové zálohy (AWS, Google a Azure) pro zotavení po havárii, zásady uchovávání pro zajištění souladu. a automatická upozornění a hlášení.
Typy záloh
V ClusterControl můžeme provádět dva hlavní typy zálohování:
- Logická záloha – záloha dat je uložena ve formátu čitelném pro člověka, jako je SQL
- Fyzická záloha – záloha obsahuje binární data
Obojí se doplňují – logické zálohování umožňuje (více či méně snadno) získat až jeden řádek dat. Fyzické zálohy by k tomu vyžadovaly více času, ale na druhou stranu umožňují velmi rychlou obnovu celého hostitele (což může při použití logické zálohy trvat hodiny nebo dokonce dny).
ClusterControl podporuje zálohování pro MySQL/MariaDB/Percona Server, PostgreSQL a MongoDB.
Naplánovat zálohování
Spuštění zálohování v ClusterControl je jednoduché a efektivní pomocí průvodce. Plánování zálohování nabízí uživatelskou přívětivost a přístup k dalším funkcím, jako je šifrování, automatický test/ověření zálohy nebo cloudová archivace.
Dostupné plánované zálohy budou uvedeny na kartě Plánované zálohy, jak je vidět na obrázku níže:
Jako dobrý postup pro plánování zálohování musíte mít již definované uchovávání záloh a doporučuje se denní zálohování. Záleží však také na datech, která potřebujete, provozu, který můžete očekávat, a dostupnosti dat, kdykoli je potřebujete, zejména při obnově dat, kdy byla data omylem smazána nebo poškození disku – což jsou nevyhnutelné. Existují také situace, kdy je ztráta dat reprodukovatelná nebo může být duplikována ručně, jako je například generování sestav, miniatur nebo data uložená v mezipaměti. I když otázka závisí na tom, jak okamžitě je potřebujete, kdykoli dojde ke katastrofě; pokud je to možné, budete chtít denně provádět zálohy mysqldump i xtrabackup, abyste MySQL využili logické a fyzické dostupnosti záloh. Chcete-li pokrýt ještě více základen, možná budete chtít naplánovat několik přírůstkových běhů xtrabackup za den. To by mohlo ušetřit nějaké místo na disku, diskové I/O nebo dokonce CPU I/O než vytvoření plné zálohy.
V ClusterControl můžete tyto různé typy záloh snadno naplánovat. Je potřeba se rozhodnout pro několik nastavení. Zálohu můžete uložit na řadič nebo lokálně na databázový uzel, kde je záloha pořízena. Musíte se rozhodnout, kam má být záloha uložena, a které databáze chcete zálohovat – všechny datové sady nebo samostatná schémata? Viz obrázek níže:
Pokročilé nastavení by využilo konfiguraci podobnou cronu pro větší granularitu. Viz obrázek níže:
Kdykoli dojde k selhání, ClusterControl tyto problémy efektivně řeší a vytváří protokoly pro další diagnostiku selhání zálohování.
V závislosti na typu zálohy, který jste zvolili, je třeba nakonfigurovat samostatná nastavení. U Xtrabackup a Galera Cluster můžete mít možnost vybrat si, jaká nastavení bude vaše fyzická záloha platit při spuštění. Viz níže:
- Používejte kompresi
- Úroveň komprese
- Desynchronizovat uzel během zálohování
- Zálohovací zámky
- Zamknout DDL na tabulku
- Xtrabackup Parallel Copy Threads
- Rychlost omezení síťového streamování (MB/s)
- Pro paralelní gzip použijte PIGZ
- Povolit šifrování
- Uchování
Na obrázku níže můžete vidět, jak byste mohli odpovídajícím způsobem označit možnosti, a jsou zde ikony s popisem, které poskytují další informace o možnostech, které byste chtěli využít pro své zásady zálohování.
V závislosti na vaší politice zálohování může být ClusterControl přizpůsoben v souladu s osvědčenými postupy pro aktualizaci vašich záloh, které jsou k dispozici. Po definování zásad zálohování se předpokládá, že musíte mít k dispozici požadované nastavení od hardwaru přes software až po cloud, trvanlivost, vysokou dostupnost nebo škálovatelnost.
Při zálohování na clusteru Galera je dobrým zvykem nastavit uzel Galera wsrep_desync=ON, když záloha běží. To vyřadí uzel z účasti na řízení toku a ochrání celý cluster před zpožděním replikace, zejména pokud jsou vaše data, která mají být zálohována, velká. V ClusterControl mějte prosím na paměti, že to může také odstranit váš cílový záložní uzel ze sady pro vyrovnávání zátěže. To platí zejména, pokud používáte proxy servery HAProxy, ProxySQL nebo MaxScale. Pokud máte nastaven správce výstrah pro případ, že by uzel byl desynchronizován, můžete jej vypnout během doby, kdy byla záloha spuštěna.
Dalším oblíbeným způsobem, jak minimalizovat dopad zálohy na Galera Cluster nebo replikační master, je nasazení replikačního slave zařízení a jeho použití jako zdroje záloh – tímto způsobem nebude Galera Cluster v žádném okamžiku ovlivněn jako záloha na slave je odpojen od clusteru.
Pomocí ClusterControl můžete takového slavea nasadit pomocí několika kliknutí. Viz obrázek níže:
a jakmile kliknete na toto tlačítko, můžete si vybrat, na kterých uzlech chcete nastavit slave. Ujistěte se, že je povoleno binární protokolování uzlů. Povolení binárního protokolu lze také provést prostřednictvím ClusterControl, který přidává více proveditelnosti pro správu požadovaného hlavního serveru. Viz obrázek níže:
a můžete také nastavit existující replikační slave,
Pro PostgreSQL máte možnosti zálohovat buď logické, nebo fyzické zálohy. V ClusterControl můžete využít své zálohy PostgreSQL výběrem pg_dump nebo pg_basebackup. pg_basebackup nebude fungovat pro verze starší než 9.3.
Pro MongoDB nabízí ClusterControl konzistentní mongodump nebo mongodb. Možná budete muset vzít na vědomí, že mongodb konzistentní nepodporuje RHEL 7, ale možná jej budete moci nainstalovat ručně.
Ve výchozím nastavení ClusterControl zobrazí zprávu o všech pořízených zálohách, úspěšných i neúspěšných. Viz níže:
Můžete zkontrolovat seznam záložních sestav, které byly vytvořeny nebo naplánovány pomocí ClusterControl. V seznamu si můžete prohlédnout protokoly pro další vyšetřování a diagnostiku. Pokud se například záloha dokončila správně podle požadované zásady zálohování, zda je správně nastavena komprese a šifrování nebo je správná požadovaná velikost zálohovaných dat. Je to dobrý způsob, jak provést rychlou kontrolu zdravého rozumu – pokud má vaše datová sada velikost kolem 1 GB, neexistuje způsob, jak by plná záloha mohla mít velikost 100 kB – v určitém okamžiku se muselo něco pokazit.
Obnova po havárii
Ukládání záloh v rámci clusteru (buď přímo v databázovém uzlu nebo na hostiteli ClusterControl) se hodí, když chcete rychle obnovit svá data:všechny záložní soubory jsou na svém místě a lze je rychle dekomprimovat a obnovit. Pokud jde o zotavení po havárii (DR), nemusí to být nejlepší volba. Mohou nastat různé problémy – může dojít k pádu serverů, síť nemusí fungovat spolehlivě, dokonce celá datová centra nemusí být přístupná kvůli nějakému výpadku. Může se to stát, ať už pracujete s menším poskytovatelem služeb s jediným datovým centrem, nebo s globálním dodavatelem, jako je Amazon Web Services. Není proto bezpečné uchovávat všechna vejce v jednom košíku – měli byste se ujistit, že máte kopii zálohy uloženou na nějakém externím místě. ClusterControl podporuje Amazon S3, Google Storage a Azure Cloud Storage.
Pro ty, kteří by chtěli implementovat své vlastní zásady DR, jsou zálohy ClusterControl uloženy v pěkně strukturovaném adresáři. Máte také možnost nahrát zálohu do cloudu. Viz obrázek níže:
Můžete vybrat a nahrát do služeb Amazon Web Services, Google Cloud a Microsoft Azure. Viz obrázek níže:
Při archivaci záloh databází je dobrým zvykem, že se váš cílový cloudový cíl nachází ve stejné oblasti jako vaše databázové servery nebo alespoň v té nejbližší. Ujistěte se, že nabízí vysokou dostupnost, trvanlivost a škálovatelnost; protože musíte zvážit, jak často a okamžitě svá data potřebujete.
Kromě vytvoření logické nebo fyzické zálohy pro váš DR, vytvoření úplného snímku vašich dat (např. pomocí LVM Snapshot, Amazon EBS Snapshots nebo Volume Snapshots, pokud používáte systém souborů Veritas) na konkrétním uzlu může zvýšit obnovu zálohy. Můžete také použít WAL (pro Postgres) pro obnovení bodu v čase (PITR) nebo binární protokoly MySQL pro váš PITR. Proto musíte vzít v úvahu, že možná budete muset vytvořit vlastní archivaci pro váš PITR. Je tedy naprosto v pořádku vytvořit a nasadit vlastní sadu skriptů a zpracovat DR podle vašich přesných požadavků.
Dalším skvělým způsobem implementace zásad obnovy po havárii je použití asynchronního replikačního slave – něco, co jsme zmínili dříve v tomto blogovém příspěvku. Takovou asynchronní podřízenou jednotku můžete nasadit na vzdáleném místě, možná v nějakém jiném datovém centru, a pak ji použít k zálohování a uložení lokálně na podřízeném zařízení. Samozřejmě byste si chtěli udělat místní zálohu svého clusteru, abyste jej měli k dispozici lokálně, pokud byste potřebovali cluster obnovit. Přesouvání dat mezi datovými centry může trvat dlouho, takže místní dostupnost souborů zálohy vám může ušetřit čas. V případě, že ztratíte přístup k hlavnímu produkčnímu clusteru, můžete mít stále přístup k podřízenému. Toto nastavení je velmi flexibilní – za prvé máte spuštěného hostitele MySQL s vašimi produkčními daty, takže by nemělo být příliš těžké nasadit vaši plnou aplikaci na webu DR. Budete mít také zálohy produkčních dat, které můžete použít k rozšíření prostředí DR.
A konečně a to nejdůležitější, záloha, která nebyla testována, zůstává neověřenou zálohou, alias Schroedinger Backup. Abyste se ujistili, že máte funkční zálohu, musíte provést test obnovy. ClusterControl nabízí způsob, jak automaticky ověřit a otestovat zálohu.
Doufáme, že vám to poskytne dostatek informací k vytvoření bezpečného a spolehlivého zálohovacího postupu pro vaše databáze s otevřeným zdrojovým kódem.