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

Fontos

Az Azure Database for MariaDB a nyugdíjazási útvonalon van. Határozottan javasoljuk, hogy migráljon az Azure Database for MySQL-be. További információ az Azure Database for MySQL-be való migrálásról: Mi történik az Azure Database for MariaDB-vel?

Az Azure Database for MariaDB automatikusan létrehozza a kiszolgáló biztonsági mentéseit, és a felhasználó által konfigurált helyileg redundáns vagy georedundáns tárolóban 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 MariaDB biztonsági másolatot 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ági mentési fájlok nincsenek felhasználók számára elérhetővé téve, és nem exportálhatók. Ezek a biztonsági másolatok csak az Azure Database for MariaDB 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óitó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ókiszolgálók legfeljebb 4 TB tárolóval

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. A legfeljebb 4 TB-os általános célú 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 akár 16 TB-os tárolást támogató általános célú tárolásnak nincs további költsége. Ha segítségre van szüksége a 16 TB-os tárolóba való migráláshoz, nyisson meg egy támogatási jegyet az Azure Portalról.

Általános célú tárolókiszolgálók legfeljebb 16 TB tárterülettel

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-os 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ő teljes pillanatkép biztonsági mentése a kiszolgáló létrehozása után azonnal ütemezve van. Az első teljes pillanatkép biztonsági mentése megmarad a kiszolgáló alapszintű biztonsági mentéseként. A pillanatképek későbbi biztonsági mentései csak különbségi biztonsági mentések lesznek.

A különbségi biztonsági mentések legalább naponta egyszer végbemennek. A különbségi pillanatképek biztonsági mentése nem rögzített ütemezés szerint történik. A különbségi pillanatképek biztonsági mentése 24 óránként történik, kivéve, ha a tranzakciónapló (binlog a MariaDB-ben) nem haladja meg az 50 GB-ot az utolsó különbségi biztonsági mentés óta. Egy adott napon legfeljebb hat különbségi pillanatkép készítése engedélyezett.

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

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őszak hét 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 hét napra van beállítva, a helyreállítási időszak az utolsó hét napnak számít. Ebben a forgatókönyvben a kiszolgáló elmúlt hét napban történő visszaállításához szükséges összes biztonsági mentés megmarad. A biztonsági mentés megőrzési ideje hét nap:

  • A legfeljebb 4 TB tárterülettel rendelkező kiszolgálók legfeljebb két teljes adatbázis-biztonsági mentést, az összes különbségi biztonsági mentést és a tranzakciónaplók biztonsági mentését őrzik meg a legkorábbi teljes adatbázis-biztonsági mentés óta.
  • A legfeljebb 16 TB tárterülettel rendelkező kiszolgálók megőrzik az adatbázis teljes pillanatképét, a különbségi pillanatképeket és a tranzakciónaplók biztonsági mentését az elmúlt nyolc napban.

Biztonsági másolatok hosszú távú megőrzése

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 a mysqldump használatával biztonsági mentéseket készíteni, és hosszú távú megőrzés céljából tárolni őket. 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 MariaDB 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 jobb védelmet és lehetőséget biztosít a kiszolgáló másik régióban történő visszaállítására katasztrófa esetén. Az alapszintű szint csak helyileg redundáns biztonsági mentési tárhelyet kínál.

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ár 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 MariaDB a kiépített kiszolgáló tárterületének akár 100%-át is biztosítja biztonsági mentési tárolóként további költségek 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 MariaDB-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.

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 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ő kevesebb, mint 12 óra.

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ó. Ez 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 redundancia beállításához.

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. A legfeljebb 4 TB tárterületet támogató kiszolgálók visszaállíthatók a földrajzilag párosított régióba vagy bármely olyan régióba, amely legfeljebb 16 TB tárhelyet támogat. Legfeljebb 16 TB tárterületet támogató kiszolgálók esetén a georedundáns biztonsági másolatok bármely olyan régióban visszaállíthatók, amelyek 16 TB-os kiszolgálókat is támogatnak. Tekintse át az Azure Database for MariaDB tarifacsomagjait a támogatott régiók listájához.

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 különböző régiókba történő replikálása között késés tapasztalható. 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óriaoptimalizált) vagy a tárhely méretének módosítása a georeduktúra-visszaá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ő 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