Biztonsági mentés és visszaállítás az Azure Database for MySQL-ben

  • Cikk

A következőkre vonatkozik: Azure Database for MySQL – Önálló kiszolgáló

Fontos

Az önálló Azure Database for MySQL-kiszolgáló a kivonási útvonalon van. Határozottan javasoljuk, hogy frissítsen rugalmas Azure Database for MySQL-kiszolgálóra. További információ a rugalmas Azure Database for MySQL-kiszolgálóra való migrálásról: Mi történik az önálló Azure Database for MySQL-kiszolgálóval?

Az Azure Database for MySQL automatikusan létrehozza a kiszolgáló biztonsági másolatait, és a felhasználó által konfigurált helyileg redundáns vagy georedundáns tárolókban tárolja őket. A biztonsági másolatokkal a kiszolgáló adott időpontnak megfelelő állapotra állítható vissza. A biztonsági mentés és helyreállítás minden üzletmenet-folytonossági stratégia elengedhetetlen része, hiszen ez védi meg az adatokat a véletlen sérülésektől és törléstől.

Biztonsági másolatok

Az Azure Database for MySQL automatikusan biztonsági másolatokat készít az adatfájlokról és a tranzakciónaplóról. Ezek a biztonsági másolatok lehetővé teszik a kiszolgáló visszaállítását a konfigurált biztonsági mentési megőrzési időszakon belül bármely időpontra. Az alapértelmezett biztonsági mentési megőrzési időszak hét nap. Igény szerint akár 35 napig is konfigurálhatja. Minden biztonsági mentés AES 256 bites titkosítással van titkosítva.

Ezek a biztonságimentés-fájlok nem láthatók a felhasználók számára, és nem exportálhatók. Ezek a biztonsági másolatok csak az Azure Database for MySQL visszaállítási műveleteihez használhatók. A mysqldump használatával adatbázist másolhat.

A biztonsági mentés típusa és gyakorisága a kiszolgálók háttértárolójától függ.

Biztonsági mentés típusa és gyakorisága

Alapszintű tárolókiszolgálók

Az Alapszintű tároló az alapszintű kiszolgálókat támogató háttértár. Az alapszintű tárolókiszolgálók biztonsági mentései pillanatképalapúak. A teljes adatbázis-pillanatkép naponta történik. Az alapszintű tárolókiszolgálókon nincsenek különbségi biztonsági mentések, és az összes pillanatkép-biztonsági mentés csak teljes adatbázis-biztonsági mentés.

A tranzakciós naplók biztonsági mentése öt percenként történik.

Általános célú tároló v1-kiszolgálók (legfeljebb 4 TB-os tárolást támogat)

Az általános célú tárolás az általános célú és memóriaoptimalizált rétegkiszolgálót támogató háttértár. Az általános célú, legfeljebb 4 TB-os tárterülettel rendelkező kiszolgálók esetében a teljes biztonsági mentés hetente egyszer történik. A különbségi biztonsági mentések naponta kétszer történnek. A tranzakciós naplók biztonsági mentése öt percenként történik. Az általános célú, legfeljebb 4 TB-os tárolók biztonsági mentései nem pillanatképalapúak, és a biztonsági mentéskor I/O-sávszélességet használnak fel. A 4 TB-os tárterületen lévő nagyméretű adatbázisok (> 1 TB) esetében javasoljuk, hogy fontolja meg a

  • További IP-címek kiépítése a biztonsági mentési I/O-k vagy
  • Másik lehetőségként migráljon olyan általános célú tárolóba, amely akár 16 TB-os tárterületet is támogat, ha az alapul szolgáló tárolási infrastruktúra elérhető az ön által előnyben részesített Azure-régiókban. Az általános célú tárolás esetében nincs további költség, amely legfeljebb 16 TB-os tárolást támogat. Ha segítségre van szüksége a 16 TB-os tárterületre való migráláshoz, nyisson meg egy támogatási jegyet az Azure Portalról.

Általános célú tároló v2-kiszolgálók (legfeljebb 16 TB-os tárolást támogat)

Az Azure-régiók egy részhalmazában az összes újonnan kiépített kiszolgáló akár 16 TB-os általános célú tárolást is támogathat. Más szóval a legfeljebb 16 TB tárterület az alapértelmezett általános célú tárolás az összes olyan régióban , ahol támogatott. A 16 TB-os tárolókiszolgálók biztonsági mentései pillanatképalapúak. Az első pillanatkép biztonsági mentése a kiszolgáló létrehozása után azonnal van ütemezve van. A pillanatképek biztonsági mentése naponta egyszer történik. A tranzakciós naplók biztonsági mentése öt percenként történik.

Az alapszintű és az általános célú tárolással kapcsolatos további információkért tekintse meg a tárolási dokumentációt.

Biztonsági mentés megőrzése

A biztonsági másolatok a kiszolgálón beállított biztonsági mentési megőrzési idő alapján maradnak meg. 7–35 napos megőrzési időtartamot választhat. Az alapértelmezett megőrzési idő 7 nap. A megőrzési időtartamot a kiszolgáló létrehozásakor vagy később is beállíthatja az Azure Portal vagy az Azure CLI használatával végzett biztonsági mentési konfiguráció frissítésével.

A biztonsági mentések megőrzési ideje határozza meg, hogy az időponthoz kötött visszaállítás mennyi idő alatt kérhető le, mivel az elérhető biztonsági mentéseken alapul. A biztonsági mentés megőrzési időszaka helyreállítási időszakként is kezelhető visszaállítási szempontból. A biztonsági mentési megőrzési időszakon belüli időponthoz kötött visszaállításhoz szükséges biztonsági másolatok a biztonsági mentési tárban maradnak. Ha például a biztonsági mentés megőrzési ideje 7 napra van beállítva, a helyreállítási időszak az utolsó 7 napnak számít. Ebben a forgatókönyvben a kiszolgáló elmúlt 7 napban történő visszaállításához szükséges biztonsági másolatok megmaradnak. A biztonsági mentés megőrzési ideje hét nap:

  • Az általános célú 1. szintű tárolókiszolgálók (amelyek legfeljebb 4 TB tárhelyet támogatnak) legfeljebb 2 teljes adatbázis-biztonsági mentést, az összes különbségi biztonsági mentést és tranzakciónapló-biztonsági mentést a legkorábbi teljes adatbázis-biztonsági mentés óta hajtanak végre.
  • Az általános célú (legfeljebb 16 TB tárterületet támogató) tároló v2-kiszolgálók az elmúlt 8 napban megőrzik a teljes adatbázis-pillanatképeket és a tranzakciónaplók biztonsági mentéseit.

Hosszú távú megőrzés

A szolgáltatás jelenleg nem támogatja natív módon a 35 napnál hosszabb biztonsági mentések hosszú távú megőrzését. Lehetősége van arra, hogy a mysqldump használatával készítsen biztonsági másolatot, és tárolja őket hosszú távú megőrzés céljából. Támogatási csapatunk lépésről lépésre blobolta a cikket , hogy megossza, hogyan érheti el.

Biztonsági mentési redundancia beállításai

Az Azure Database for MySQL rugalmasságot biztosít a helyileg redundáns vagy georedundáns biztonsági mentési tárolók között az általános célú és a memóriaoptimalizált szinteken. Ha a biztonsági másolatok georedundáns biztonsági mentési tárolóban vannak tárolva, azok nem csak abban a régióban vannak tárolva, amelyben a kiszolgáló üzemel, hanem egy párosított adatközpontba is replikálódnak. Ez a georedundancia jobb védelmet és képességet biztosít a kiszolgáló helyreállításához egy másik régióban katasztrófa esetén. Az alapszintű szint csak helyileg redundáns biztonsági mentési tárhelyet kínál.

Megjegyzés:

A következő régiók esetében : Közép-India, Közép-Franciaország, Egyesült Arab Emírségek északi régiója, Észak-Afrika déli régiója; Az általános célú tároló v2-tároló nyilvános előzetes verzióban érhető el. Ha a fent említett régiókban általános célú tároló v2-ben hoz létre forráskiszolgálót (legfeljebb 16 TB tárterületet támogat), akkor a georedundáns biztonsági mentés engedélyezése nem támogatott.

Váltás helyileg redundánsról georedundáns biztonsági mentési tárolóra

A helyileg redundáns vagy georedundáns biztonsági mentési tárolás konfigurálása csak a kiszolgáló létrehozása közben engedélyezett. A biztonsági mentési tároló redundanciára vonatkozó beállításait a kiszolgáló üzembe helyezése után már nem lehet módosítani. A helyileg redundáns tárolóról a georedundáns tárolóra való áthelyezéshez az egyetlen támogatott lehetőség egy új kiszolgáló létrehozása és az adatok áttelepítése memóriakép és visszaállítás használatával.

A biztonsági mentési tár költségei

Az Azure Database for MySQL által biztosított biztonsági tárhelyet a teljes kiszolgálótárhely 100%-áig lehet igénybe venni többletköltség nélkül. A felhasznált további biztonsági mentési tárterületeket havonta GB-ban számítjuk fel. Ha például 250 GB tárterülettel rendelkező kiszolgálót létesített, akkor a kiszolgáló biztonsági mentéséhez további 250 GB tárterület áll rendelkezésre díjmentesen. A 250 GB-nál nagyobb biztonsági mentésekhez felhasznált tárterület a díjszabási modell szerint kerül felszámításra.

Az Azure Monitorban az Azure Portalon elérhető Backup Storage metrikával figyelheti a kiszolgáló által felhasznált biztonsági mentési tárterületet. A használt Backup Storage metrika a kiszolgálóhoz beállított biztonsági mentési időtartam alapján megtartott összes adatbázis-biztonsági mentés, különbségi biztonsági mentés és napló biztonsági mentés által felhasznált tárterület összegét jelöli. A biztonsági mentések gyakoriságát a szolgáltatás kezeli és ismerteti korábban. A kiszolgáló magas szintű tranzakciós tevékenysége miatt a biztonsági másolatok tárolási kihasználtsága a teljes adatbázis méretétől függetlenül növekedhet. Georedundáns tárolás esetén a biztonsági mentési tárhasználat a helyileg redundáns tárterület kétszerese.

A biztonsági mentés tárolási költségeinek szabályozásának elsődleges módja a megfelelő biztonsági mentési megőrzési időszak beállítása és a megfelelő biztonsági mentési redundancia beállításainak kiválasztása a kívánt helyreállítási célok eléréséhez. Megőrzési időtartamot 7 és 35 nap között választhat. Az általános célú és memóriaoptimalizált kiszolgálók dönthetnek úgy, hogy georedundáns tárolóval rendelkeznek a biztonsági mentésekhez.

Restore

Az Azure Database for MySQL-ben a visszaállítás végrehajtása új kiszolgálót hoz létre az eredeti kiszolgáló biztonsági másolataiból, és visszaállítja a kiszolgálón található összes adatbázist. A visszaállítás jelenleg nem támogatott, ha az eredeti kiszolgáló leállt állapotban van.

Kétféle visszaállítás érhető el:

  • Az időponthoz kötött visszaállítás a biztonsági mentés redundancia lehetőségével érhető el, és az eredeti kiszolgálóval azonos régióban hoz létre egy új kiszolgálót a teljes és a tranzakciónapló-biztonsági mentések kombinációjával.
  • A georedundáns visszaállítás csak akkor érhető el, ha a kiszolgálót georedundáns tárolásra konfigurálta, és lehetővé teszi a kiszolgáló egy másik régióba való visszaállítását a legutóbbi biztonsági mentés használatával.

A kiszolgáló helyreállításának becsült ideje több tényezőtől függ:

  • Az adatbázisok mérete
  • Az érintett tranzakciónaplók száma
  • A visszaállítási pontra való helyreállításhoz újrajátszandó tevékenység mennyisége
  • A hálózati sávszélesség, ha a visszaállítás egy másik régióba történik
  • A célrégióban feldolgozott egyidejű visszaállítási kérelmek száma
  • Az elsődleges kulcs jelenléte az adatbázis tábláiban. A gyorsabb helyreállítás érdekében fontolja meg az elsődleges kulcs hozzáadását az adatbázis összes táblájához. Annak ellenőrzéséhez, hogy a táblák rendelkeznek-e elsődleges kulccsal, használja a következő lekérdezést:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Nagy méretű vagy nagyon aktív adatbázisok esetén a visszaállítás több órát is igénybe vehet. Ha a régióban elhúzódó leállás következik be, előfordulhat, hogy a vészhelyreállítási folyamat túl sok georedundáns visszaállítási kérést ad ki. Ha túl sok a kérés, az egyes adatbázisok helyreállítási ideje megnőhet. A legtöbb adatbázis-visszaállítás 12 óránál rövidebb idő alatt befejeződik.

Fontos

A törölt kiszolgálók csak a törlést követő öt napon belül állíthatók vissza, amely után a biztonsági másolatok törlődnek. Az adatbázis biztonsági mentése csak a kiszolgálót üzemeltető Azure-előfizetésből érhető el és állítható vissza. Az elvetett kiszolgáló visszaállításához tekintse meg a dokumentált lépéseket. A kiszolgáló erőforrásainak védelme érdekében, az üzembe helyezés után, a véletlen törlés vagy a váratlan módosítások ellen a rendszergazdák felügyeleti zárolásokat használhatnak.

Point-in-time restore

A biztonsági mentési redundancia beállításától függetlenül bármikor visszaállíthatja a biztonsági mentés megőrzési időszakán belül. A rendszer egy új kiszolgálót hoz létre ugyanabban az Azure-régióban, mint az eredeti kiszolgáló. A rendszer az eredeti kiszolgáló konfigurációjával jön létre a tarifacsomaghoz, a számítási generációhoz, a virtuális magok számához, a tárterület méretéhez, a biztonsági mentés megőrzési időszakához és a biztonsági mentés redundanciájával.

Megjegyzés:

Két kiszolgálóparaméter van, amelyek a visszaállítási művelet után alaphelyzetbe állnak az alapértelmezett értékekre (és nem másolódnak át az elsődleges kiszolgálóról).

  • time_zone – Ez az érték a SYSTEM alapértelmezett értékre van állítva
  • event_scheduler – A event_scheduler ki van kapcsolva a visszaállított kiszolgálón

Ezeket a kiszolgálóparamétereket a kiszolgálóparaméter újrakonfigurálásával kell beállítania

Az időponthoz kötött visszaállítás több esetben is hasznos. Ha például egy felhasználó véletlenül töröl adatokat, elvet egy fontos táblát vagy adatbázist, vagy ha egy alkalmazás véletlenül felülírja a rossz adatokat egy alkalmazáshiba miatt.

Előfordulhat, hogy meg kell várnia a következő tranzakciónapló biztonsági mentését, mielőtt az utolsó öt percen belül visszaállhat egy időpontra.

Geo-restore

Visszaállíthat egy kiszolgálót egy másik Azure-régióba, ahol a szolgáltatás elérhető, ha georedundáns biztonsági mentésekhez konfigurálta a kiszolgálót.

  • Az általános célú (legfeljebb 4 TB tárterületet támogató) 1. szintű tárolókiszolgálók visszaállíthatók a földrajzilag párosított régióba, vagy bármely olyan Azure-régióba, amely támogatja az Azure Database for MySQL - egykiszolgálós szolgáltatást.
  • Az általános célú tároló v2-kiszolgálók (amelyek legfeljebb 16 TB-os tárolót támogatnak) csak olyan Azure-régiókba állíthatók vissza, amelyek támogatják az általános célú tároló v2 kiszolgálók infrastruktúráját. A támogatott régiók listájáért tekintse Azure Database for MySQL tarifacsomagjainak listáját.

A georedundáns visszaállítás az alapértelmezett helyreállítási lehetőség, ha a kiszolgáló nem érhető el a kiszolgálót futtató régióban történt incidens miatt. Ha egy régióban egy nagy méretű incidens az adatbázis-alkalmazás elérhetetlenségét eredményezi, a georedundáns biztonsági másolatokból bármely más régióban lévő kiszolgálóra visszaállíthatja a kiszolgálót. A georedukció a kiszolgáló legutóbbi biztonsági mentését használja. A biztonsági mentés készítése és a másik régióba történő replikálása között késés van. Ez a késés akár egy óra is lehet, így katasztrófa esetén akár egy óra adatvesztés is előfordulhat.

Fontos

Ha georedukciós visszaállítást végeznek egy újonnan létrehozott kiszolgálón, a kezdeti biztonsági mentés szinkronizálása az adatmérettől függően több mint 24 órát is igénybe vehet, mivel a kezdeti teljes pillanatkép-biztonsági mentési másolási idő sokkal magasabb. A későbbi pillanatkép-biztonsági másolatok növekményes másolatok, így a visszaállítások gyorsabbak lesznek 24 órányi kiszolgálólétrehozás után. Ha georedukciókat értékel ki az RTO meghatározásához, javasoljuk, hogy a jobb becslések érdekében csak 24 órányi kiszolgálólétrehozás után várja meg és értékelje ki a georedukciót.

A georedundáns visszaállítás során módosítható kiszolgálókonfigurációk közé tartozik a számítási generáció, a virtuális magok, a biztonsági másolatok megőrzési időtartama és a biztonsági másolatok redundancia-beállításai. A tarifacsomag (alapszintű, általános célú vagy memóriaoptimalált) vagy a tárterület méretének módosítása a geovisszaállítás során nem támogatott.

A helyreállítás becsült ideje több tényezőtől is függ, például az adatbázis méretétől, a tranzakciónapló méretétől, a hálózati sávszélességtől, valamint attól, hogy ugyanabban a régióban egyidejűleg összesen hány adatbázis helyreállítása folyik. A helyreállítási idő általában kevesebb mint 12 óra.

Visszaállítás utáni feladatok végrehajtása

A helyreállítási mechanizmus visszaállítása után a következő feladatokat kell elvégeznie a felhasználók és alkalmazások biztonsági mentéséhez és futtatásához:

  • Ha az új kiszolgáló az eredeti kiszolgálót szeretné lecserélni, átirányítsa az ügyfeleket és az ügyfélalkalmazásokat az új kiszolgálóra
  • Győződjön meg arról, hogy a megfelelő virtuális hálózati szabályok érvényben vannak a felhasználók számára a csatlakozáshoz. Ezek a szabályok nem lesznek átmásolva az eredeti kiszolgálóról.
  • Győződjön meg arról, hogy megfelelő bejelentkezések és adatbázisszintű engedélyek vannak érvényben
  • Konfigurálja a riasztásokat, ha szükséges.

További lépések