Zálohování a obnovení na flexibilním serveru Azure Database for MySQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for MySQL

Flexibilní server Azure Database for MySQL automaticky vytváří zálohy serveru a bezpečně je ukládá do místního redundantního úložiště v rámci oblasti. Zálohy lze použít k obnovení serveru do určitého bodu v čase. Zálohování a obnovení jsou základní součástí jakékoli strategie kontinuity podnikových procesů, protože chrání data před náhodným poškozením nebo odstraněním.

Přehled služby Backup

Flexibilní server Azure Database for MySQL podporuje dva typy záloh, které poskytují vylepšenou flexibilitu při údržbě záloh důležitých obchodních dat.

Automatizované zálohování

Flexibilní server Azure Database for MySQL vytváří zálohy snímků datových souborů a ukládá je do místního redundantního úložiště. Server také provádí zálohování transakčních protokolů a také je ukládá do místního redundantního úložiště. Tyto zálohy umožňují obnovit server k jakémukoli bodu v čase v rámci nakonfigurovaného období uchovávání záloh. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů. Všechny zálohy se šifrují pomocí 256bitového šifrování AES pro neaktivní uložená data.

Zálohování na vyžádání

Flexibilní server Azure Database for MySQL také umožňuje aktivovat zálohy produkční úlohy na vyžádání, kromě automatizovaných záloh provedených službou a uložit ho v souladu se zásadami uchovávání záloh serveru. Tyto zálohy můžete použít jako nejrychlejší bod obnovení k provedení obnovení k určitému bodu v čase, abyste zkrátili dobu obnovení až o 90 %. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů. Z portálu můžete aktivovat celkem 50 záloh na vyžádání. Všechny zálohy se šifrují pomocí 256bitového šifrování AES pro neaktivní uložená data.

Tyto záložní soubory nelze exportovat. Zálohy je možné použít pouze pro operace obnovení na flexibilním serveru Azure Database for MySQL. Ke kopírování databáze můžete také použít mysqldump z klienta MySQL.

Frekvence zálohování

Zálohy na flexibilních serverech jsou založené na snímcích. První záloha snímků je naplánována okamžitě po vytvoření serveru. Zálohy snímků se pořizují jednou denně. Zálohování transakčních protokolů probíhá každých pět minut. Pokud naplánované zálohování selže, naše služba zálohování se bude každých 20 minut pokoušet vytvořit zálohu, dokud se zálohování nezdaří. K těmto selháním zálohování může dojít kvůli vysokému transakčnímu produkčnímu zatížení instance serveru.

možnosti redundance zálohy

Flexibilní server Azure Database for MySQL ukládá několik kopií záloh, aby vaše data byla chráněna před plánovanými a neplánovanými událostmi, včetně přechodných selhání hardwaru, výpadků sítě nebo napájení a obrovských přírodních katastrof. Flexibilní server Azure Database for MySQL nabízí flexibilitu pro výběr mezi místně redundantním, zónově redundantním nebo geograficky redundantním úložištěm zálohování v úrovních Basic, Pro obecné účely a Pro důležité obchodní informace. Ve výchozím nastavení je úložiště zálohování flexibilního serveru Azure Database for MySQL místně redundantní pro servery s vysokou dostupností se stejnou zónou nebo bez konfigurace vysoké dostupnosti a zónově redundantní pro servery s konfigurací zónově redundantní vysoké dostupnosti.

Redundance zálohování zajišťuje, že vaše databáze splňuje cíle dostupnosti a stálosti i v případě selhání a flexibilního serveru Azure Database for MySQL rozšiřuje tři možnosti pro uživatele –

  • Místně redundantní úložiště zálohování: Pokud jsou zálohy uloženy v místně redundantním úložišti zálohování, jsou ve stejném datacentru uloženy více kopií záloh. Tato možnost chrání vaše data před selháním serverového racku a jednotky. To také poskytuje alespoň 99,999999999% (11 9) stálost objektů Backups za daný rok. Ve výchozím nastavení je úložiště záloh pro servery se stejnou zónou vysoká dostupnost (HA) nebo konfigurace vysoké dostupnosti nastavená na místně redundantní.

  • Zónově redundantní úložiště zálohování: Pokud jsou zálohy uložené v zónově redundantním úložišti zálohování, několik kopií se neuloží jenom v zóně dostupnosti, ve které je server hostovaný, ale replikují se také do jiné zóny dostupnosti ve stejné oblasti. Tuto možnost můžete využít ve scénářích, které vyžadují vysokou dostupnost nebo omezení replikace dat do určité země nebo oblasti, aby splňovaly požadavky na rezidenci dat. To také poskytuje alespoň 99,9999999999 % (12 9) stálost objektů Backups za daný rok. Můžete vybrat možnost Zónově redundantní vysoká dostupnost na serveru vytvořit čas, aby se zajistilo zónově redundantní úložiště zálohování. Vysoká dostupnost serveru může být po vytvoření zakázaná, ale úložiště zálohování zůstává zónově redundantní.

  • Geograficky redundantní úložiště zálohování: Pokud jsou zálohy uložené v geograficky redundantním úložišti záloh, několik kopií se neuloží jenom v oblasti, ve které je váš server hostovaný, ale replikují se také do geograficky spárované oblasti. To zajišťuje lepší ochranu a možnost obnovení serveru v jiné oblasti v případě havárie. To také poskytuje alespoň 99,999999999999999% (16 9) stálost objektů Backups za daný rok. Jednu z možností geografické redundance můžete povolit při vytváření serveru, aby se zajistilo geograficky redundantní úložiště zálohování. Kromě toho můžete přejít z místně redundantního úložiště na geograficky redundantní úložiště po vytvoření serveru. Geografická redundance je podporovaná pro servery hostované ve kterékoli ze spárovaných oblastí Azure.

Poznámka:

Zónově redundantní vysoká dostupnost pro podporu redundance zón se aktuálně zobrazuje pouze jako operace vytvoření času. V současné době je možné povolit nebo zakázat geografickou redundanci serveru s zónově redundantní vysokou dostupností pouze při vytváření serveru.

Přechod z jiných možností úložiště zálohování na geograficky redundantní úložiště zálohování

Existující úložiště záloh můžete přesunout do geograficky redundantního úložiště pomocí následujících navrhovaných způsobů:

  • Přechod z místně redundantního úložiště na geograficky redundantní úložiště zálohování – Pokud chcete přesunout úložiště záloh z místně redundantního úložiště do geograficky redundantního úložiště, můžete změnit konfiguraci serveru Compute + Storage z webu Azure Portal a povolit geografickou redundanci pro místně redundantní zdrojový server. Stejné zónově redundantní servery s vysokou dostupností je také možné obnovit jako geograficky redundantní server podobným způsobem, jako je základní záložní úložiště místně redundantní pro stejné.

  • Přechod z zónově redundantního úložiště na geograficky redundantní úložiště zálohování – Flexibilní server Azure Database for MySQL nepodporuje zónově redundantní úložiště na geograficky redundantní převod úložiště prostřednictvím změny nastavení Compute + Storage po zřízení serveru. Pokud chcete přesunout úložiště záloh z zónově redundantního úložiště do geograficky redundantního úložiště, máte dvě možnosti: a) K obnovení serveru s požadovanou konfigurací použijte obnovení k určitému bodu v čase. b) Vytvořte nový server s požadovanou konfigurací a migrujte data pomocí výpisu a obnovení.

Uchování záloh

Zálohy se uchovávají na základě nastavení doby uchovávání záloh na serveru. Můžete vybrat dobu uchovávání 1 až 35 dnů s výchozím obdobím uchovávání dat sedm dní. Dobu uchovávání můžete nastavit během vytváření serveru nebo později aktualizací konfigurace zálohování pomocí webu Azure Portal.

Doba uchovávání záloh určuje, jak daleko zpět v čase se dá provést operace obnovení k určitému bodu v čase, protože je založená na dostupných zálohách. Doba uchovávání záloh se dá také považovat za okno obnovení z pohledu obnovení. Všechny zálohy potřebné k obnovení k určitému bodu v čase v rámci doby uchovávání záloh se uchovávají v úložišti záloh. Pokud je například doba uchovávání záloh nastavená na sedm dnů, okno obnovení se považuje za posledních sedm dnů. V tomto scénáři se zachovají všechny zálohy potřebné k obnovení serveru za posledních 7 dnů. V intervalu uchovávání záloh 7 dnů se snímky databáze a zálohy transakčních protokolů ukládají po dobu posledních osmi dnů (1 den před oknem).

Náklady na úložiště zálohování

Flexibilní server Azure Database for MySQL poskytuje až 100 % zřízeného úložiště serveru jako úložiště záloh bez dalších poplatků. Všechna další využitá úložiště záloh se účtují v GB za měsíc. Pokud jste například zřídili server s 250 GB úložiště, máte k dispozici 250 GB úložiště pro zálohování serverů bez dalších poplatků. Pokud je denní využití zálohování 25 GB, můžete mít až 10 dnů volného úložiště záloh. Úložiště spotřebované pro zálohy větší než 250 GB se účtuje podle cenového modelu.

K monitorování úložiště zálohování spotřebovaného serverem můžete použít metriku využité ve službě Azure Monitor, která je dostupná na webu Azure Portal. Použitá metrika Úložiště zálohování představuje součet úložiště spotřebovaného všemi zálohami databáze a zálohami protokolů, které se uchovávají na základě doby uchovávání záloh nastavené pro server. Náročné transakční aktivity na serveru můžou způsobit zvýšení využití úložiště zálohování bez ohledu na celkovou velikost databází. Úložiště zálohování používané pro geograficky redundantní server je dvakrát místně redundantní server.

Primárním způsobem řízení nákladů na úložiště zálohování je nastavení příslušné doby uchovávání záloh. Můžete vybrat dobu uchovávání mezi 1 a 35 dny.

Důležité

Zálohy z databázového serveru nakonfigurovaného v konfiguraci zónově redundantní vysoké dostupnosti probíhají z primárního databázového serveru, protože režie je minimální při zálohování snímků.

Zobrazit dostupné úplné zálohy

Okno Zálohování a obnovení na webu Azure Portal poskytuje úplný seznam úplných záloh, které máte k dispozici v libovolném časovém okamžiku. To zahrnuje automatizované zálohování i zálohy na vyžádání. Toto okno můžete použít k zobrazení časových razítek dokončení pro všechny dostupné úplné zálohy v rámci doby uchovávání serveru a k provádění operací obnovení pomocí těchto úplných záloh. Seznam dostupných záloh zahrnuje všechny úplné zálohy v rámci doby uchovávání, časové razítko znázorňující úspěšné dokončení, časové razítko označující, jak dlouho bude záloha zachována, a akci obnovení.

Obnovení

Na flexibilním serveru Azure Database for MySQL se při obnovení vytvoří nový server ze záloh původního serveru. K dispozici jsou dva typy obnovení:

  • Obnovení k určitému bodu v čase: je k dispozici s možností redundance zálohování a vytvoří nový server ve stejné oblasti jako původní server.
  • Geografické obnovení: je k dispozici pouze v případě, že jste server nakonfigurovali pro geograficky redundantní úložiště a umožňuje obnovit server do geograficky spárované oblasti nebo jakékoli jiné podpora Azure oblasti, kde je flexibilní server dostupný.

Odhadovaný čas obnovení serveru závisí na několika faktorech:

  • Velikost databází
  • Počet zahrnutých transakčních protokolů
  • Množství aktivity, kterou je potřeba přehrát k obnovení do bodu obnovení
  • Šířka pásma sítě, pokud je obnovení v jiné oblasti
  • Počet souběžných žádostí o obnovení zpracovávaných v cílové oblasti
  • Přítomnost primárního klíče v tabulkách v databázi. Pro rychlejší obnovení zvažte přidání primárního klíče pro všechny tabulky v databázi.

Poznámka:

Po obnovení k obnovení k určitému bodu v čase i geografickému obnovení se server s podporou vysoké dostupnosti stane nedostupnou dostupností (vysoká dostupnost zakázaná).

Obnovení k určitému bodu v čase

Na flexibilním serveru Azure Database for MySQL vytvoří provedení obnovení k určitému bodu v čase nový server ze záloh flexibilního serveru ve stejné oblasti jako zdrojový server. Vytvoří se s konfigurací původního serveru pro výpočetní úroveň, počet virtuálních jader, velikost úložiště, doba uchovávání záloh a možnost redundance zálohování. Značky a nastavení, jako je virtuální síť a brána firewall, se také dědí ze zdrojového serveru. Po dokončení obnovení je možné změnit nastavení výpočetních prostředků a úložiště obnoveného serveru, konfiguraci a zabezpečení.

Poznámka:

Po operaci obnovení existují dva parametry serveru, které se resetují na výchozí hodnoty (a nezkopírují se z primárního serveru).

  • time_zone – tato hodnota je nastavená na VÝCHOZÍ hodnotu SYSTEM.
  • event_scheduler – tento parametr je na obnoveném serveru nastavený na OFF (vypnuto).

Obnovení k určitému bodu v čase je užitečné v několika scénářích. Mezi běžné případy použití patří :

  • Když uživatel omylem odstraní data v databázi
  • Uživatel zahodí důležitou tabulku nebo databázi.
  • Uživatelská aplikace omylem přepíše dobrá data chybnými daty kvůli vadě aplikace.

Můžete si vybrat mezi nejnovějším bodem obnovení, vlastním bodem obnovení a nejrychlejším bodem obnovení (obnovení pomocí úplného zálohování) prostřednictvím webu Azure Portal.

  • Nejnovější bod obnovení: Nejnovější možnost bodu obnovení vám pomůže obnovit server do časového razítka při aktivaci operace obnovení. Tato možnost je užitečná k rychlému obnovení serveru do nejaktuálnějšího stavu.
  • Vlastní bod obnovení: Tato možnost umožňuje zvolit libovolný bod v čase v období uchovávání definovaném pro tento server. Tato možnost je užitečná k obnovení serveru v přesném časovém okamžiku, aby se zotavil z chyby uživatele.
  • Nejrychlejší bod obnovení: Tato možnost umožňuje uživatelům obnovit server v nejrychlejším možném čase pro daný den v rámci doby uchovávání definované pro svůj server. Nejrychlejší obnovení je možné výběrem bodu obnovení k určitému bodu v čase, ve kterém je dokončena úplná záloha. Tato operace obnovení jednoduše obnoví úplné zálohování snímků a nezaručí obnovení ani obnovení protokolů, což z něj dělá rychlé. Doporučujeme vybrat časové razítko úplné zálohy, které je větší než nejstarší bod obnovení v čase pro úspěšnou operaci obnovení.

Odhadovaná doba obnovení závisí na několika faktorech, včetně velikosti databáze, velikosti zálohování transakčního protokolu, velikosti výpočetních prostředků skladové položky a času obnovení. Obnovení transakčního protokolu je časově nejnáročnější součástí procesu obnovení. Pokud je čas obnovení zvolen blíže plánu zálohování snímků, operace obnovení jsou rychlejší, protože aplikace transakčního protokolu je minimální. Pokud chcete odhadnout přesný čas obnovení pro váš server, důrazně doporučujeme ho otestovat ve vašem prostředí, protože má příliš mnoho proměnných specifických pro prostředí.

Důležité

Pokud obnovujete instanci flexibilního serveru Azure Database for MySQL nakonfigurovanou s zónově redundantní vysokou dostupností, obnovený server se nakonfiguruje ve stejné oblasti a zóně jako primární server a nasadí se jako jeden server v režimu bez vysoké dostupnosti. Informace o zónově redundantní vysoké dostupnosti pro flexibilní server

Důležité

Odstraněný prostředek flexibilního serveru Azure Database for MySQL můžete obnovit do 5 dnů od odstranění serveru. Podrobný průvodce obnovením odstraněného serveru najdete v zdokumentovaných krocích. K ochraně prostředků serveru po nasazení před náhodným odstraněním nebo neočekávanými změnami můžou správci využít zámky správy.

Geografické obnovení

Server můžete obnovit do geograficky spárované oblasti, kde je služba dostupná, pokud jste server nakonfigurovali pro geograficky redundantní zálohy nebo jakoukoli jinou podpora Azure oblast, ve které je k dispozici flexibilní server Azure Database for MySQL. Možnost obnovení do jakékoli spárované podpora Azure oblasti (s výjimkou Brazil SouthUSGov Virginia a West US 3) označuje se jako Univerzální geografické obnovení).

Geografické obnovení je výchozí možností obnovení, pokud server není dostupný kvůli incidentu v oblasti, kde je server hostovaný. Pokud velký incident v oblasti vede k nedostupnosti vaší databázové aplikace, můžete obnovit server z geograficky redundantních záloh na server v jakékoli jiné oblasti. Geografické obnovení využívá nejnovější zálohu serveru. Mezi provedeným zálohováním a replikací do jiné oblasti dochází ke zpoždění. Toto zpoždění může být až hodinu, takže pokud dojde k havárii, může dojít až k hodinové ztrátě dat.

Geografické obnovení je možné provést také na zastaveném serveru s využitím Azure CLI. Další informace o geografickém obnovení serveru pomocí Azure CLI najdete v tématu Obnovení flexibilního serveru Azure Database for MySQL pomocí Azure CLI.

Odhadovaná doba obnovení závisí na několika faktorech, mezi které patří velikost databází, velikost transakčního protokolu, šířka pásma sítě a celkový počet obnovovaných databází ve stejné oblasti a ve stejnou dobu.

Poznámka:

Pokud geograficky obnovujete instanci flexibilního serveru Azure Database for MySQL nakonfigurovanou s zónově redundantní vysokou dostupností, obnovený server se nakonfiguruje v geograficky spárované oblasti a stejné zóně jako primární server a nasadí se jako jedna instance flexibilního serveru Azure Database for MySQL v režimu bez vysoké dostupnosti. Projděte si zónově redundantní vysokou dostupnost flexibilního serveru Azure Database for MySQL.

Důležité

Pokud je primární oblast mimo provoz, nemůžete v příslušné geograficky spárované oblasti vytvářet geograficky redundantní servery, protože úložiště není možné zřídit v primární oblasti. Musíte počkat, až primární oblast zřídí geograficky redundantní servery v geograficky spárované oblasti. Když je primární oblast mimo provoz, můžete zdrojový server stále geograficky obnovit do geograficky spárované oblasti zakázáním možnosti geografické redundance v prostředí portálu pro obnovení a obnovením jako místně redundantního serveru, abyste zajistili provozní kontinuitu.

Provádění úloh po obnovení

Po obnovení z nejnovějšího bodu obnovení nebo z vlastního mechanismu obnovení bodu obnovení byste měli provést následující úlohy, abyste mohli uživatele a aplikace zálohovat a spustit:

  • Pokud má nový server nahradit původní server, přesměrujte klienty a klientské aplikace na nový server.
  • Ujistěte se, že jsou pro připojení uživatelů zavedená příslušná pravidla brány firewall a virtuální sítě na úrovni serveru.
  • Ujistěte se, že jsou zavedená příslušná přihlášení a oprávnění na úrovni databáze.
  • Podle potřeby nakonfigurujte upozornění.

Dlouhodobé uchovávání (Preview)

Flexibilní serverové služby Azure Backup a Azure Database for MySQL vytvořily podnikové řešení dlouhodobého zálohování pro instance flexibilních serverů Azure Database for MySQL, které uchovávají zálohy po dobu až 10 let. Dlouhodobé uchovávání můžete používat nezávisle nebo kromě automatizovaného řešení zálohování nabízeného flexibilním serverem Azure Database for MySQL, které nabízí uchovávání až 35 dnů. Automatizované zálohy jsou zálohy snímků vhodné pro provozní obnovení, zejména pokud chcete provést obnovení z nejnovějších záloh. Dlouhodobé zálohy vám pomůžou s vašimi potřebami dodržování předpisů a potřebami auditování. Kromě dlouhodobého uchovávání nabízí řešení následující schopnosti:

  • Plánované zálohování řízené zákazníkem a zálohování na vyžádání
  • Spravujte a monitorujte všechny operace a úlohy související se zálohováním napříč servery, skupinami prostředků, umístěními, předplatnými a tenanty z jednoho podokna skla označovaného jako Centrum zálohování.
  • Zálohy se ukládají v samostatné doméně zabezpečení a selhání. Pokud dojde k ohrožení zabezpečení zdrojového serveru nebo předplatného, zálohy zůstanou v trezoru služby Backup (ve spravovaných účtech úložiště Azure Backup) v bezpečí.

Omezení a důležité informace

  • Ve verzi Preview je obnovení LTR aktuálně k dispozici jako RestoreasFiles pro účty úložiště. Funkce RestoreasServer bude přidána v budoucnu.

  • Zálohování LTR se v současné době nepodporuje pro servery s podporou vysoké dostupnosti. Tato funkce bude přidána v budoucnu.

  • Podpora vytváření a správy LTR prostřednictvím Azure CLI se v současné době nepodporuje.

Další informace o provádění dlouhodobého zálohování najdete v příručce s postupy.

Zálohování a export na vyžádání (Preview)

Flexibilní server Azure Database for MySQL teď nabízí možnost aktivovat fyzické zálohování serveru na vyžádání a exportovat ho do účtu úložiště Azure (Azure Blob Storage). Po exportu je možné tyto zálohy použít k obnovení dat, migraci a redundanci. Tyto exportované fyzické záložní soubory je možné použít k obnovení zpět na místní server MySQL, který pomáhá splnit požadavky organizace na auditování, dodržování předpisů a archivaci. Tato funkce je aktuálně ve verzi Public Preview a je dostupná jenom v oblastech veřejného cloudu.

Další informace o zálohování exportu najdete v průvodci postupy.

Nejčastější dotazy (FAQ)

  • Návody zálohování serveru?

    Flexibilní server Azure Database for MySQL ve výchozím nastavení umožňuje automatizované zálohování celého serveru (zahrnující všechny vytvořené databáze) s výchozím 7denním obdobím uchovávání. Ruční zálohování můžete aktivovat také pomocí funkce zálohování na vyžádání. Dalším způsobem ručního zálohování je použití komunitních nástrojů, jako je mysqldump, jak je zdokumentované zde nebo mydumper, jak je uvedeno zde. Pokud chcete zálohovat instanci flexibilního serveru Azure Database for MySQL do úložiště objektů blob, projděte si náš blogový blog technické komunity o zálohování flexibilního serveru Azure Database for MySQL do služby Blob Storage.

  • Můžu nakonfigurovat automatické zálohování, které se mají uchovávat dlouhodobě?

    Ne, v současné době podporujeme pouze maximálně 35 dnů automatického uchovávání záloh. Můžete provést ruční zálohování a použít je pro dlouhodobý požadavek na uchovávání.

  • Jaká jsou okna zálohování pro můj server? Můžu si ho přizpůsobit?

    První záloha snímků je naplánována okamžitě po vytvoření serveru. Zálohy snímků se pořizuje jednou denně. Zálohování transakčních protokolů probíhá každých pět minut. Okna zálohování jsou ze své podstaty spravovaná v Azure a není možné je přizpůsobit.

  • Jsou zálohy šifrované?

    Všechna data, zálohy a dočasné soubory flexibilního serveru Azure Database for MySQL vytvořená během provádění dotazů se šifrují pomocí 256bitového šifrování AES. Šifrování úložiště je vždy zapnuté a není možné ho zakázat.

  • Můžu obnovit jednu nebo několik databází?

    Obnovení jedné nebo několika databází nebo tabulek se nepodporuje. V případě, že chcete obnovit konkrétní databáze, proveďte obnovení k určitému bodu v čase a pak extrahujte potřebné tabulky nebo databáze.

  • Je můj server během okna zálohování dostupný?

    Ano. Zálohy jsou online operace a jsou založené na snímcích. Operace vytvoření snímku trvá jenom několik sekund a nezasahuje do produkčních úloh a zajišťuje vysokou dostupnost serveru.

  • Při nastavování časového období údržby pro server musíme počítat s časovým obdobím zálohování?

    Ne, zálohy se aktivují interně jako součást spravované služby a nemají žádný vliv na časové období spravované údržby.

  • Kde jsou moje automatizované zálohy uložené a jak se spravují jejich uchovávání?

    Flexibilní server Azure Database for MySQL automaticky vytváří zálohy serverů a ukládá je v nakonfigurovaných uživatelem, místně redundantním úložišti nebo v geograficky redundantním úložišti. Tyto záložní soubory není možné exportovat. Výchozí doba uchovávání záloh je sedm dnů. Volitelně můžete nakonfigurovat zálohování databáze od 1 do 35 dnů.

  • Jak můžu ověřit zálohy?

    Nejlepším způsobem, jak ověřit dostupnost úspěšně dokončených záloh, je zobrazit úplné automatizované zálohy provedené v období uchovávání v okně Zálohování a obnovení. Pokud zálohování selže, není uvedené v seznamu dostupných záloh a služba zálohování se pokusí provést zálohování každých 20 minut, dokud se neprovede úspěšné zálohování. Tato selhání zálohování jsou způsobená velkým transakčním provozním zatížením na serveru.

  • Kde se zobrazuje využití zálohování?

    Na webu Azure Portal na kartě Monitorování – Metriky najdete metriku Využité úložiště zálohování, která vám může pomoct monitorovat celkové využití zálohování.

  • Co se stane se zálohami, když odstraním server?

    Pokud odstraníte server, všechny zálohy patřící k tomuto serveru se také odstraní a nebude možné je obnovit. K ochraně prostředků serveru po nasazení před náhodným odstraněním nebo neočekávanými změnami můžou správci používat zámky správy.

  • Co se stane se zálohami při obnovení serveru?

    Pokud server obnovíte, bude výsledkem vždy vytvoření net nového serveru, který byl obnoven pomocí záloh původního serveru. Původní záloha z původního serveru se nezkopíruje na nově obnovený server a zůstane s původním serverem. U nově vytvořeného serveru se ale první zálohování snímků naplánuje okamžitě po vytvoření serveru a služba zajistí, aby se denní automatizované zálohy pořídily a uložily podle nakonfigurované doby uchovávání serveru.

  • Jak se mi účtují a účtují poplatky za využití záloh?

    Flexibilní server Azure Database for MySQL poskytuje až 100 % zřízeného úložiště serveru jako úložiště záloh bez poplatků. Veškeré využité úložiště zálohování se účtuje v GB za měsíc podle cenového modelu. Fakturace úložiště zálohování se také řídí vybranou možností uchovávání záloh a zvolenou možností redundance zálohování kromě transakční aktivity na serveru, která má vliv na celkové využité úložiště zálohování přímo.

  • Jak se zálohy uchovávají pro zastavené servery?

    Pro zastavené servery se neprovádí žádné nové zálohy. Všechny starší zálohy (v rámci okna uchovávání informací) se v době zastavení serveru zachovají, dokud se server nerestartuje, po kterém se uchovávání záloh pro aktivní server řídí jeho oknem uchovávání záloh.

  • Jak se budou účtovat zálohy zastaveného serveru?

    Během zastavení instance serveru se vám účtuje zřízené úložiště (včetně zřízeného IOPS) a úložiště záloh (záloh uložených v zadaném okně uchovávání informací). Bezplatné úložiště zálohování je omezené na velikost zřízené databáze a vztahuje se pouze na aktivní servery.

  • Jak jsou moje zálohovaná data chráněná?

    Flexibilní server Azure Database for MySQL chrání vaše zálohovaná data tím, že blokuje všechny operace, které by mohly vést ke ztrátě bodů obnovení po dobu nakonfigurované doby uchovávání. Zálohy pořízené během doby uchovávání je možné číst pouze pro účely obnovení a po uplynutí doby uchovávání se odstraní. Všechny zálohy na flexibilním serveru Azure Database for MySQL se navíc šifrují pomocí 256bitového šifrování AES pro neaktivní uložená data.

  • Jak operace obnovení k určitému bodu v čase (PITR) ovlivňuje využití IOPS?

    Během operace PITR na flexibilním serveru Azure Database for MySQL se vytvoří nový server a data se zkopírují z úložiště zdrojového serveru do úložiště nového serveru. Výsledkem tohoto procesu je zvýšené využití vstupně-výstupních operací za sekundu na zdrojovém serveru. Toto zvýšení využití vstupně-výstupních operací za sekundu je normálním výskytem a nezoznačuje žádné problémy se zdrojovým serverem ani operací PITR. Po dokončení operace obnovení k určitému bodu v čase se využití IOPS na zdrojovém serveru vrátí na obvyklé úrovně.

  • Návody obnovit můj server? Azure Portal podporuje obnovení k určitému bodu v čase pro všechny servery, což uživatelům umožňuje obnovit nejnovější nebo vlastní body obnovení. Pokud chcete ručně obnovit server ze záloh provedených nástrojem mysqldump/myDumper, přečtěte si téma Obnovení databáze pomocí nástroje myLoader.

  • Proč obnovení trvá tolik času?

    Odhadovaný čas obnovení serveru závisí na několika faktorech:

    • Velikost databází. V rámci procesu obnovení musí být databáze hydratovaná z poslední fyzické zálohy, a proto doba potřebná k obnovení bude úměrná velikosti databáze.
    • Aktivní část aktivity transakce, kterou je potřeba přehrát k obnovení. Obnovení může trvat déle v závislosti na přidané aktivitě transakce z posledního úspěšného kontrolního bodu.
    • Šířka pásma sítě, pokud se obnovení provádí do jiné oblasti
    • Počet souběžně zpracovávaných žádostí o obnovení v cílové oblasti
    • Přítomnost primárních klíčů v tabulkách v databázi. Pro rychlejší obnovení zvažte přidání primárních klíčů pro všechny tabulky v databázi.

  • Ovlivní úpravy databázových proměnných na úrovni relace obnovení?

    Úprava proměnných na úrovni relace a spouštění příkazů DML v relaci klienta MySQL může mít vliv na operaci obnovení k určitému bodu v čase, protože tyto úpravy se nezaznamenávají v binárním protokolu, který se používá pro operaci zálohování a obnovení. Například foreign_key_checks jsou jednou z takových proměnných na úrovni relace, která je zakázaná pro spuštění příkazu DML, který porušuje omezení cizího klíče, vede k selhání obnovení k určitému bodu v čase. Jediným alternativním řešením v takovém scénáři by bylo vybrat čas obnovení k určitému bodu v čase, kdy foreign_key_checks byly zakázány. Naším doporučením je neměnit žádné proměnné relace pro úspěšnou operaci pitR.

Další kroky