Databázové systémy mají povinnost ukládat a zajišťovat konzistentní dostupnost relevantních dat, kdykoli jsou potřeba a kdykoli v provozu. Většina společností nedokáže pokračovat v podnikání po případech ztráty dat v důsledku selhání databáze, bezpečnostního mostu, lidské chyby nebo katastrofického selhání, které může zcela zničit provozní uzly ve výrobě. Uchovávání databází ve stejném datovém centru vystavuje člověka vysokému riziku ztráty všech dat v případě těchto nehorázností.
Replikace a zálohování jsou běžně používané způsoby zajištění vysoké dostupnosti dat. Výběr mezi těmito dvěma závisí na tom, jak často se data mění. Zálohování je nejvhodnější tam, kde se data nemění častěji a neočekává se, že budete mít tolik záložních souborů. Na druhé straně je replikace upřednostňována pro často se měnící data kromě některých dalších výhod spojených s poskytováním dat na konkrétním místě snížením latence požadavků. Replikaci i zálohování však lze použít pro maximální integritu a konzistenci dat během obnovy v každém případě selhání.
Zálohování databáze poskytuje další výhody kromě toho, že poskytuje bod obnovení k poskytování základů pro vytváření nových prostředí pro vývoj, otevřený přístup a staging bez temperování s výrobou. Vývojový tým může rychle a snadno testovat nově integrované funkce a urychlit jejich vývoj. Zálohy lze také použít ke kontrolnímu bodu pro chyby kódu všude tam, kde výsledná data nejsou konzistentní.
Úvahy o zálohování MongoDB
Zálohy jsou vytvářeny v určitých bodech, aby odrážely (fungující jako snímek databáze), jaká data databáze v daný okamžik hostí. Pokud databáze v daném bodě selže, můžeme použít poslední záložní soubor k vrácení DB do bodu před selháním. Před provedením obnovy je však třeba vzít v úvahu některé faktory, mezi něž patří:
- Cíl bodu obnovy
- Cíl doby zotavení
- Izolace databáze a snímku
- Komplikace se sdílením
- Proces obnovy
- Faktory výkonu a dostupné úložiště
- Flexibilita
- Složitost nasazení
Cíl bodu obnovy
To se provádí za účelem zjištění, kolik dat jste připraveni ztratit během procesu zálohování a obnovy. Máme-li například uživatelská data a data clickstream, uživatelská data budou mít přednost před analýzou clickstreamu, protože ta může být po obnovení regenerována monitorováním operací ve vaší aplikaci. Pro kritická data, jako jsou bankovní informace, data výrobního průmyslu a informace o komunikačních systémech, by mělo být preferováno nepřetržité zálohování, které by mělo být prováděno v krátkých intervalech. Pokud se data často nemění, může být levnější ztratit většinu z nich, pokud provedete obnovený snímek například o 6 měsíců nebo 1 rok dříve.
Cíl doby zotavení
Toto slouží k analýze a určení, jak rychle lze operaci obnovení provést. Během obnovy budou vaše aplikace mít určité prostoje, které jsou také přímo úměrné množství dat, která je třeba obnovit. Pokud obnovujete velkou sadu dat, bude to trvat déle.
Izolace databáze a snímku
Izolace je měřítkem toho, jak blízko jsou snímky zálohy od primárních databázových serverů z hlediska logické konfigurace a fyzicky. Pokud jsou náhodou dostatečně blízko, zkracuje se doba obnovy na úkor zvýšené pravděpodobnosti zničení ve stejnou dobu, kdy je zničena databáze. Není vhodné hostovat zálohy a produkční prostředí ve stejném systému, aby se předešlo jakémukoli narušení serverů, které by se také zmírnilo v zálohách.
Komplikace se sdílením
U distribuovaného databázového systému prostřednictvím shardingu se projevuje určitá složitost zálohování a může být nutné pozastavit činnosti zápisu v celém systému. Různé fragmenty dokončí různé typy záloh v různých časech. S ohledem na logické zálohy a zálohy snímků
Logické zálohy
- Střepy mají různé velikosti, a proto skončí v různých časech
- Výpisy databáze MongoDB budou ignorovat --oplog, a proto nebudou konzistentní u každého fragmentu.
- Vyvažovačka může být vypnutá, zatímco má být zapnutá, protože některé úlomky možná nedokončily proces obnovy
Zálohy snímků
- Funguje dobře pro jednu repliku od verze 3.2 a novější. Měli byste proto zvážit aktualizaci verze MongoDB.
Proces obnovy
Někteří lidé provádějí zálohy bez testování, zda budou v případě obnovy fungovat. Záloha má v podstatě poskytnout schopnost obnovy, jinak bude zbytečná. Vždy byste se měli pokusit spustit zálohy na různých testovacích serverech, abyste zjistili, zda fungují.
Faktory výkonu a dostupné úložiště
Zálohy mají také tendenci mít mnoho velikostí jako data ze samotné databáze a je třeba je dostatečně zkomprimovat, aby nezabíraly mnoho zbytečného místa, což by mohlo snížit celkové úložné prostředky systému. Mohou být archivovány do souborů zip, čímž se sníží jejich celková velikost. Kromě toho, jak již bylo zmíněno výše, je možné zálohy archivovat v různých datových centrech ze samotné databáze.
Zálohy mohou určovat různý výkon databáze v tom, že některé ji mohou snížit. V takovém případě budou průběžné zálohy způsobovat určité neúspěchy, a proto by měly být převedeny na plánované zálohy, aby nedošlo k vyčerpání období údržby. Ve většině případů jsou na podporu zálohování nasazeny sekundární servery. V tomto případě:
- Jednotlivé uzly nelze konzistentně zálohovat, protože MongoDB používá při použití příkazu mongodump čtení-nepotvrzené bez oplog a v takovém případě zálohy nebudou bezpečné.
- Pro zálohování používejte sekundární uzly, protože samotný proces trvá dlouho v závislosti na množství zahrnutých dat a připojené aplikace budou mít určité prostoje. Pokud používáte primární, který musí také aktualizovat Oplogy, můžete během tohoto výpadku ztratit některá data
- Proces obnovy trvá hodně času, ale přidělené úložné prostředky jsou malé.
Flexibilita
Mnohokrát možná nebudete chtít některá data během zálohování, jako v případě cíle Recovery Point Objective můžete chtít provést obnovu a odfiltrovat data o kliknutích uživatele. K tomu potřebujete strategii částečného zálohování, která poskytne flexibilitu pro odfiltrování dat, o která nebudete mít zájem, a zkrátí tak dobu obnovy a zkrátí zdroje, které by byly plýtvány. Přírůstkové zálohování může být také užitečné, takže z posledního snímku budou zálohovány pouze změněné části dat, nikoli celé zálohy pro každý snímek.
Složitost nasazení
Vaši strategii zálohování by mělo být snadné nastavit a udržovat. Můžete si také naplánovat zálohy, abyste je nemuseli dělat ručně, kdykoli budete chtít.
Závěr
Databázové systémy zaručují „život po smrti“, pouze pokud je na místě zaveden dobře zavedený záložní systém. Databázi by mohly zničit katastrofické faktory, lidská chyba nebo bezpečnostní útoky, které mohou vést ke ztrátě nebo poškození dat. Před provedením zálohy je třeba zvážit typ dat z hlediska velikosti a důležitosti. Vždy se nedoporučuje uchovávat zálohy ve stejném datovém centru jako databáze, aby se snížila pravděpodobnost, že budou zálohy zničeny současně. Zálohy mohou změnit výkon databáze, proto je třeba dávat pozor na strategii, kterou použít, a na to, kdy zálohu provést. Neprovádějte zálohy na primárním uzlu, protože to může mít za následek výpadek systému během zálohování a následně ztrátu důležitých dat.