Biztonsági mentés és visszaállítás az Azure Database for MySQL-ben – rugalmas kiszolgáló
A következőkre vonatkozik:
Azure Database for MySQL – rugalmas kiszolgáló
A rugalmas Azure Database for MySQL-kiszolgáló automatikusan létrehozza a kiszolgáló biztonsági mentéseit, és biztonságosan tárolja őket a régió helyi redundáns tárolójában. 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.
A biztonsági mentés áttekintése
A rugalmas Azure Database for MySQL-kiszolgáló kétféle biztonsági mentést támogat, hogy nagyobb rugalmasságot biztosítson az üzletileg kritikus fontosságú adatok biztonsági mentéseinek fenntartása érdekében.
Automatikus biztonsági mentés
A rugalmas Azure Database for MySQL-kiszolgáló pillanatképeket készít az adatfájlokról, és egy helyi redundáns tárolóban tárolja őket. A kiszolgáló emellett végrehajtja a tranzakciónaplók biztonsági mentését, és helyi redundáns tárolóban tárolja őket. 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 1 és 35 nap között konfigurálhatja az adatbázis biztonsági mentését. A nem használt adatok minden biztonsági másolata 256 bites AES használatával van titkosítva.
Igény szerinti biztonsági mentés
A rugalmas Azure Database for MySQL-kiszolgáló lehetővé teszi az éles számítási feladatok igény szerinti biztonsági mentésének elindítását a szolgáltatás által készített automatikus biztonsági mentések mellett, és a kiszolgáló biztonsági mentési megőrzési szabályzatával összhangban tárolja. Ezeket a biztonsági másolatokat a leggyorsabb visszaállítási pontként használhatja az időponthoz kötött visszaállítás végrehajtásához, hogy akár 90%-kal csökkentse a visszaállítási időt. Az alapértelmezett biztonsági mentési megőrzési időszak hét nap. Igény szerint 1 és 35 nap között konfigurálhatja az adatbázis biztonsági mentését. Összesen 50 igény szerinti biztonsági mentést indíthat el a portálról. A nem használt adatok minden biztonsági másolata 256 bites AES használatával van titkosítva.
Ezek a biztonsági mentési fájlok nem exportálhatók. A biztonsági másolatok csak rugalmas Azure Database for MySQL-kiszolgálón végzett visszaállítási műveletekhez használhatók. MySQL-ügyfélből származó mysqldump használatával is másolhat adatbázist.
Biztonsági mentés gyakorisága
A rugalmas kiszolgálók biztonsági mentése pillanatkép-alapú. 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. Ha egy ütemezett biztonsági mentés sikertelen, a biztonsági mentési szolgáltatásunk 20 percenként megpróbál biztonsági mentést készíteni a sikeres mentésig. Ezek a biztonsági mentési hibák a kiszolgálópéldány nagy tranzakciós éles terhelése miatt fordulhatnak elő.
Biztonsági mentési redundancia beállításai
A rugalmas Azure Database for MySQL-kiszolgáló több másolatot tárol a biztonsági másolatokról, hogy az adatok védve legyen a tervezett és nem tervezett eseményektől, beleértve az átmeneti hardverhibákat, a hálózati vagy áramkimaradásokat és a súlyos természeti katasztrófákat. A rugalmas Azure Database for MySQL-kiszolgáló rugalmasságot biztosít a helyileg redundáns, zónaredundáns vagy georedundáns biztonsági mentési tárolók között alapszintű, általános célú és üzletileg kritikus szinteken. Alapértelmezés szerint a rugalmas Azure Database for MySQL-kiszolgáló biztonsági mentési tárolója helyileg redundáns az azonos zónájú magas rendelkezésre állású (HA) vagy magas rendelkezésre állású konfigurációval nem rendelkező kiszolgálók, valamint zónaredundáns HA-konfigurációval rendelkező kiszolgálók esetében.
A biztonsági mentési redundancia biztosítja, hogy az adatbázis a hibák ellenére is megfeleljen a rendelkezésre állási és tartóssági céloknak, a rugalmas Azure Database for MySQL-kiszolgáló pedig három lehetőséget nyújt a felhasználók számára –
Helyileg redundáns biztonsági mentési tároló : Ha a biztonsági másolatok helyileg redundáns biztonsági mentési tárolóban vannak tárolva, a biztonsági másolatok több példányát is ugyanabban az adatközpontban tárolja a rendszer. Ez a beállítás védi az adatokat a kiszolgáló állvány- és meghajtóhibáitól. Emellett ez legalább 99,9999999999999%-os (11 9-es) tartósságot biztosít a biztonsági másolatok objektumainak egy adott évben. Alapértelmezés szerint az azonos zónájú magas rendelkezésre állású (HA) vagy magas rendelkezésre állású kiszolgálók biztonsági mentése helyileg redundánsra van állítva.
Zónaredundáns biztonsági mentési tároló : Ha a biztonsági másolatok zónaredundáns biztonsági mentési tárolóban vannak tárolva, a rendszer nem csak abban a rendelkezésre állási zónában tárolja a másolatokat, amelyben a kiszolgáló üzemel, hanem egy másik rendelkezésre állási zónába is replikálódik ugyanabban a régióban. Ez a lehetőség olyan forgatókönyvek esetén használható, amelyek magas rendelkezésre állást igényelnek, vagy az adatok országon/régión belüli replikációjának korlátozására az adattárolási követelményeknek való megfelelés érdekében. Ez legalább 99,99999999999999999%-os (12 9-es) tartósságot biztosít a Backups objektumoknak egy adott évben. A zónaredundáns magas rendelkezésre állás lehetőség kiválasztásával biztosítható a zónaredundáns biztonsági mentési tároló. A kiszolgáló magas rendelkezésre állása a létrehozás után letiltható, de a biztonsági mentési tárterület zónaredundáns marad.
Georedundáns biztonsági mentési tároló : Ha a biztonsági másolatok georedundáns biztonsági mentési tárolóban vannak tárolva, a rendszer nem csak abban a régióban tárolja a másolatokat, ahol a kiszolgáló üzemel, hanem a rendszer a földrajzilag párosított régióba is replikálja őket. 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. Ez legalább 99.9999999999999999999999999999%-os (16 9-es) tartósságot biztosít a biztonsági mentési objektumoknak egy adott évben. A georedundáns tárolás biztosításához engedélyezheti a georedundáns beállításokat a kiszolgáló létrehozásakor. Emellett a helyileg redundáns tárolásról a kiszolgáló létrehozása utáni georedundáns tárolásra is áttérhet. A georedundancia bármelyik Azure-beli párosított régióban tárolt kiszolgálón támogatott.
Feljegyzés
A zónaredundáns magas rendelkezésre állás a zónaredundancia támogatásához csak létrehozási idő műveletként jelenik meg. A zónaredundáns magas rendelkezésre állású kiszolgálók georedundáns használata jelenleg csak a kiszolgáló létrehozásakor engedélyezhető/tiltható le.
Váltás más biztonsági mentési tárolási lehetőségekről georedundáns biztonsági mentési tárolóra
A meglévő biztonsági másolatok tárolóját a következő javasolt módszerekkel helyezheti át georedundáns tárolóba:
Váltás helyileg redundánsról georedundáns biztonsági mentési tárolóra – A helyileg redundáns tárolóról a georedundáns tárolóra való áthelyezéshez módosíthatja a Compute + Storage kiszolgáló konfigurációját az Azure Portalról, hogy engedélyezze a georedundáns tárolást a helyileg redundáns forráskiszolgálóhoz. Ugyanezek a zónaredundáns HA-kiszolgálók georedundáns kiszolgálóként is visszaállíthatók hasonló módon, mint a mögöttes biztonsági mentési tárolók helyileg redundánsak ugyanahhoz.
Zónaredundánsról georedundáns biztonsági mentési tárolóra váltás – A rugalmas Azure Database for MySQL-kiszolgáló nem támogatja a zónaredundáns tárolást georedundáns tárolásra való konvertálásra a Compute + Storage beállításainak módosítása után a kiszolgáló kiépítése után. A biztonsági mentési tároló zónaredundáns tárolóról georedundáns tárolóra való áthelyezéséhez két lehetőség közül választhat: a) A PITR (időponthoz kötött visszaállítás) használatával állítsa vissza a kiszolgálót a kívánt konfigurációval. b) Hozzon létre egy új kiszolgálót a kívánt konfigurációval, és migrálja az adatokat a memóriakép és a visszaállítás használatával.
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. 1–35 napos megőrzési időtartamot választhat, ha az alapértelmezett megőrzési idő hét nap. A megőrzési időtartamot a kiszolgáló létrehozásakor vagy később is beállíthatja, ha frissíti a biztonsági mentési konfigurációt az Azure Portalon.
A biztonsági mentések megőrzési ideje határozza meg, hogy az adott időponthoz képest mennyi idő alatt végezhető el egy időponthoz kötött visszaállítási művelet, mivel az a rendelkezésre álló biztonsági másolatokon 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 hét napos biztonsági mentési időszakkal az adatbázis-pillanatképek és a tranzakciónaplók biztonsági mentései az elmúlt nyolc napra (az ablak előtti 1 napra) vannak tárolva.
A biztonsági mentési tár költségei
A rugalmas Azure Database for MySQL-kiszolgáló a kiépített kiszolgáló tárhelyé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 kiépített egy kiszolgálót 250 GB tárterülettel, akkor a kiszolgáló biztonsági mentéséhez 250 GB tárterület áll rendelkezésre, díjmentesen. Ha a napi biztonsági mentési használat 25 GB, akkor akár 10 nap ingyenes biztonsági mentési tárterület is rendelkezésre áll. 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 Portalon elérhető Azure Monitorban használt Backup Storage-metrikával figyelheti a kiszolgáló által felhasznált biztonsági mentési tárterületet. A használt Biztonsági mentési tár metrika a kiszolgálóhoz beállított biztonsági mentési időtartam alapján megtartott összes adatbázis-biztonsági mentés és napló biztonsági mentése által felhasznált tárterület összegét jelöli. 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. A georedundáns kiszolgálókhoz használt biztonsági mentési tárterület kétszer akkora, mint egy helyileg redundáns kiszolgáló esetében.
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. 1 és 35 nap közötti megőrzési időtartamot választhat.
Fontos
A zónaredundáns magas rendelkezésre állású konfigurációban konfigurált adatbázis-kiszolgáló biztonsági mentései az elsődleges adatbázis-kiszolgálóról történnek, mivel a többletterhelés minimális a pillanatképek biztonsági mentésével.
Elérhető teljes biztonsági másolatok megtekintése
Az Azure Portal Biztonsági mentés és visszaállítás panelje az Adott időpontban elérhető teljes biztonsági másolatok teljes listáját tartalmazza. Ez magában foglalja az automatikus biztonsági mentéseket és az igény szerinti biztonsági mentéseket is. Ezen a panelen megtekintheti a kiszolgáló megőrzési időszakán belüli összes rendelkezésre álló teljes biztonsági mentés befejezési időbélyegeit, és visszaállítási műveleteket hajthat végre ezekkel a teljes biztonsági másolatokkal. Az elérhető biztonsági másolatok listája tartalmazza a megőrzési időszakon belüli összes biztonsági mentést, a sikeres befejezést megjelenítő időbélyeget, a biztonsági mentések megőrzésének időtartamát jelző időbélyeget és a visszaállítási műveletet.
Visszaállítás
A rugalmas Azure Database for MySQL-kiszolgálón a visszaállítás végrehajtása új kiszolgálót hoz létre az eredeti kiszolgáló biztonsági másolataiból. Kétféle visszaállítás érhető el:
- Időponthoz kötött visszaállítás: biztonsági mentési redundancia beállítással érhető el, és egy új kiszolgálót hoz létre az eredeti kiszolgálóval azonos régióban.
- 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ó georedundáns vagy más Azure-támogatás régióba való visszaállítását, ahol rugalmas kiszolgáló érhető el.
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.
Feljegyzés
A magas rendelkezésre állású kiszolgálók a visszaállítást követően nem HA (magas rendelkezésre állás letiltva) lesznek az időponthoz kötött és a georedukciós visszaállításhoz.
Adott időpontnak megfelelő helyreállítás
A rugalmas Azure Database for MySQL-kiszolgálón az időponthoz kötött visszaállítás végrehajtása új kiszolgálót hoz létre a rugalmas kiszolgáló biztonsági másolataiból a forráskiszolgálóval azonos régióban. Ez az eredeti kiszolgáló konfigurációjával jön létre a számítási szinthez, a virtuális magok számához, a tárterület méretéhez, a biztonsági mentési megőrzési időszakhoz és a biztonsági mentés redundancia beállításához. Emellett a forráskiszolgálótól öröklik a címkéket és a beállításokat, például a virtuális hálózatot és a tűzfalat. A visszaállított kiszolgáló számítási és tárolási szintje, konfigurációja és biztonsági beállításai a visszaállítás befejezése után módosíthatók.
Feljegyzé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 – Ennek az ALAPÉRTELMEZETT értéke SYSTEM
- event_scheduler – Az event_scheduler értéke a visszaállított kiszolgálón OFF
Az időponthoz kötött visszaállítás több esetben is hasznos. A gyakori használati esetek némelyike a következők:
- Amikor egy felhasználó véletlenül töröl adatokat az adatbázisban
- A felhasználó elvet egy fontos táblát vagy adatbázist
- A felhasználói alkalmazás véletlenül felülírja a jó adatokat az alkalmazás hibája miatt rossz adatokkal.
Választhat a legújabb visszaállítási pont, az egyéni visszaállítási pont és a leggyorsabb visszaállítási pont (teljes biztonsági mentéssel történő visszaállítás) között az Azure Portalon.
- Legújabb visszaállítási pont: A legújabb visszaállítási pont beállítással visszaállíthatja a kiszolgálót az időbélyegre a visszaállítási művelet aktiválásakor. Ez a beállítás akkor hasznos, ha gyorsan visszaállítja a kiszolgálót a legújabb állapotra.
- Egyéni visszaállítási pont: Ez a beállítás lehetővé teszi a kiszolgáló számára meghatározott megőrzési időn belül bármely időpont kiválasztását. Ez a beállítás akkor hasznos, ha a kiszolgálót a pontos időpontban állítja vissza a felhasználói hiba utáni helyreállításhoz.
- Leggyorsabb visszaállítási pont: Ez a beállítás lehetővé teszi, hogy a felhasználók a kiszolgálóhoz megadott megőrzési időn belül a lehető leggyorsabb időpontban visszaállítsák a kiszolgálót. A leggyorsabb visszaállítás a visszaállítási pont kiválasztásával lehetséges, amikor a teljes biztonsági mentés befejeződik. Ez a visszaállítási művelet egyszerűen visszaállítja a teljes pillanatkép biztonsági mentését, és nem garantálja a naplók visszaállítását vagy helyreállítását, ami gyorssá teszi. Javasoljuk, hogy válasszon egy teljes biztonsági mentési időbélyeget, amely nagyobb, mint a legkorábbi visszaállítási időpont a sikeres visszaállítási művelethez.
A helyreállítás becsült ideje számos tényezőtől függ, többek között az adatbázis méretétől, a tranzakciónapló biztonsági mentési méretétől, az termékváltozat számítási méretétől és a visszaállítás időpontjától is. A tranzakciónapló helyreállítása a visszaállítási folyamat leginkább időigényes része. Ha a visszaállítási idő közelebb van a pillanatkép biztonsági mentési ütemezéséhez, a visszaállítási műveletek gyorsabbak, mivel a tranzakciónapló-alkalmazás minimális. A kiszolgáló pontos helyreállítási idejének becsléséhez javasoljuk, hogy tesztelje azt a környezetben, mivel túl sok környezetspecifikus változóval rendelkezik.
Fontos
Ha egy rugalmas Azure Database for MySQL-kiszolgálópéldányt állít vissza zónaredundáns magas rendelkezésre állással, a visszaállított kiszolgáló ugyanabban a régióban és zónában van konfigurálva, mint az elsődleges kiszolgáló, és egyetlen kiszolgálóként van üzembe helyezve nem HA módban. Tekintse meg a rugalmas kiszolgáló zónaredundáns magas rendelkezésre állását .
Fontos
A törölt Azure Database for MySQL-kiszolgálói erőforrást a kiszolgáló törlésétől számított 5 napon belül helyreállíthatja. A törölt kiszolgálók visszaállításának részletes útmutatóját a dokumentált lépésekben találja. Az üzembe helyezés utáni kiszolgálói erőforrások véletlen törléssel vagy váratlan módosításokkal szembeni védelméhez a rendszergazdák felügyeleti zárolásokat használhatnak.
Georedundáns visszaállítás
A kiszolgálót visszaállíthatja a földrajzilag párosított régióba, ahol a szolgáltatás elérhető, ha georedundáns biztonsági mentésekhez konfigurálta a kiszolgálót, vagy bármely más Azure-támogatás régiót, ahol rugalmas Azure Database for MySQL-kiszolgáló érhető el. Bármely nem párosított Azure-támogatás régióba való visszaállítás lehetősége (kivéveBrazil South, USGov Virginia és West US 3) az úgynevezett "Univerzális georedundáns visszaállítás".
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.
A georedukció az Azure CLI-t használó leállított kiszolgálón is elvégezhető. Az Azure Database for MySQL rugalmas kiszolgálójának visszaállítása az Azure CLI-vel című cikkben további információt olvashat a kiszolgálók Azure CLI-vel történő georedukciójáról.
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.
Feljegyzés
Ha egy rugalmas Azure Database for MySQL-kiszolgálópéldány georedundáns magas rendelkezésre állással van konfigurálva, a visszaállított kiszolgáló a földrajzilag párosított régióban és az elsődleges kiszolgálóéval megegyező zónában van konfigurálva, és egyetlen Rugalmas Azure Database for MySQL-kiszolgálópéldányként van üzembe helyezve, nem HA módban. Tekintse meg a rugalmas Azure Database for MySQL-kiszolgáló zónaredundáns magas rendelkezésre állását .
Fontos
Ha az elsődleges régió le van állítva, nem hozhat létre georedundáns kiszolgálókat a megfelelő georedundáns régióban, mert a tároló nem építhető ki az elsődleges régióban. Meg kell várnia, amíg az elsődleges régió georedundáns kiszolgálókat épít ki a földrajzilag párosított régióban. Ha az elsődleges régió le van állítva, a forráskiszolgálót továbbra is georedundánsan visszaállíthatja a georedundáns régióba, ha letiltja a Georedundancia beállítást a Compute + Storage Konfigurálja a kiszolgálóbeállításokat a visszaállítási portálon, és helyileg redundáns kiszolgálóként állítja vissza a visszaállítást az üzletmenet folytonosságának biztosítása érdekében.
Visszaállítás utáni feladatok végrehajtása
A legújabb visszaállítási pontból vagy egyéni visszaállítási pont helyreállítási mechanizmusból történő visszaállítás 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ó lecseréli az eredeti kiszolgálót, irányítsa át az ügyfeleket és az ügyfélalkalmazásokat az új kiszolgálóra.
- Győződjön meg arról, hogy megfelelő kiszolgálószintű tűzfal és virtuális hálózati szabályok vannak érvényben a felhasználók számára a csatlakozáshoz.
- 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.
Hosszú távú megőrzés (előzetes verzió)
Az Azure Backup és a rugalmas Azure Database for MySQL-kiszolgálószolgáltatások nagyvállalati szintű, hosszú távú biztonsági mentési megoldást építettek ki rugalmas Azure Database for MySQL-kiszolgálópéldányokhoz, amelyek akár 10 évig is megőrzik a biztonsági mentéseket. A rugalmas Azure Database for MySQL-kiszolgáló által kínált automatikus biztonsági mentési megoldáson kívül akár 35 napig is használhat hosszú távú megőrzést. Az automatikus biztonsági mentések a működési helyreállításokhoz megfelelő pillanatkép-biztonsági másolatok, különösen akkor, ha a legújabb biztonsági másolatokból szeretne visszaállítást végezni. A hosszú távú biztonsági mentések segítenek a megfelelőségi és naplózási igények kielégítésében. A hosszú távú megőrzés mellett a megoldás a következő képességeket kínálja:
- Ügyfél által felügyelt ütemezett és igény szerinti biztonsági mentések
- A biztonsági mentéssel kapcsolatos összes művelet és feladat kezelése és monitorozása kiszolgálók, erőforráscsoportok, helyek, előfizetések és bérlők között egyetlen panelről, a Backup Centerből.
- Különálló biztonsági és tartalék tartományban tárolt biztonsági másolatok. Ha a forráskiszolgáló vagy az előfizetés biztonsága sérül, a biztonsági másolatok biztonságban maradnak a Backup-tárolóban (az Azure Backup felügyelt tárfiókjaiban).
Korlátozások és szempontok
- Előzetes verzióban az LTR-visszaállítás jelenleg RestoreasFilesként érhető el a tárfiókok számára. A RestoreasServer funkció a jövőben bővülni fog.
- Az LTR Azure CLI-vel történő létrehozásának és felügyeletének támogatása jelenleg nem támogatott.
A hosszú távú biztonsági mentés végrehajtásával kapcsolatos további információkért tekintse meg az útmutatót
Igény szerinti biztonsági mentés és exportálás (előzetes verzió)
A rugalmas Azure Database for MySQL-kiszolgáló mostantól lehetővé teszi a kiszolgáló igény szerinti fizikai biztonsági mentésének aktiválását és exportálását egy Azure Storage-fiókba (Azure Blob Storage). Az exportálás után ezek a biztonsági másolatok felhasználhatók az adat-helyreállításhoz, a migráláshoz és a redundanciához. Ezek az exportált fizikai biztonsági mentési fájlok segítségével visszaállíthatók a helyszíni MySQL-kiszolgálóra, hogy megfeleljenek a szervezet naplózási/megfelelőségi/archiválási igényeinek. A funkció jelenleg nyilvános előzetes verzióban érhető el, és csak nyilvános felhőrégiókban érhető el.
Az exportálás biztonsági mentésével kapcsolatos további információkért tekintse meg az útmutatót
Gyakori kérdések (GYIK)
Biztonsági mentéssel kapcsolatos kérdések
Hogyan biztonsági másolatot készíteni a kiszolgálóról?
Alapértelmezés szerint a rugalmas Azure Database for MySQL-kiszolgáló lehetővé teszi a teljes kiszolgáló automatikus biztonsági mentését (beleértve az összes létrehozott adatbázist) az alapértelmezett 7 napos megőrzési időtartammal. A manuális biztonsági mentést igény szerinti biztonsági mentési funkcióval is aktiválhatja. A biztonsági mentés manuális készítésének másik módja az olyan közösségi eszközök használata, mint például az itt dokumentált mysqldump vagy az itt dokumentált mydumper. Ha egy rugalmas Azure Database for MySQL-kiszolgálópéldányról szeretne biztonsági másolatot készíteni egy Blob Storage-ra, tekintse meg a rugalmas Azure Database for MySQL-kiszolgáló biztonsági mentését a Rugalmas Azure Database for MySQL-kiszolgálóról egy Blob Storage-ra című tech-közösség blogján.
Konfigurálhatom az automatikus biztonsági másolatok hosszú távú megőrzését?
Nem, jelenleg legfeljebb 35 napos automatikus biztonsági mentés-megőrzést támogatunk. Manuális biztonsági mentéseket készíthet, és ezt használhatja a hosszú távú megőrzési követelményekhez.
Mik a kiszolgáló biztonsági mentési ablakai? Testre szabhatom?
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 megtörténik. A tranzakciós naplók biztonsági mentése öt percenként történik. A biztonsági mentési ablakokat az Azure kezeli, és nem szabható testre.
Titkosítva vannak a biztonsági másolatok?
A lekérdezés végrehajtása során létrehozott rugalmas Azure Database for MySQL-kiszolgálói adatok, biztonsági másolatok és ideiglenes fájlok AES 256 bites titkosítással vannak titkosítva. A tárolótitkosítás mindig be van kapcsolva, és nem tiltható le.
Visszaállíthatok egy/néhány adatbázist?
Egyetlen/néhány adatbázis vagy tábla visszaállítása nem támogatott. Ha adott adatbázisokat szeretne visszaállítani, végezzen el egy időponthoz kötött visszaállítást, majd bontsa ki a szükséges táblá(ka)t vagy adatbázis(ok)t.
Elérhető a kiszolgáló a biztonsági mentési időszak alatt?
Igen. A biztonsági mentések online műveletek, és pillanatkép-alapúak. A pillanatkép-művelet csak néhány másodpercet vesz igénybe, és nem zavarja az éles számítási feladatokat, biztosítva a kiszolgáló magas rendelkezésre állását.
A kiszolgáló karbantartási időszakának beállításakor figyelembe kell venni a biztonsági mentési ablakot?
Nem, a biztonsági mentések belsőleg aktiválódnak a felügyelt szolgáltatás részeként, és nincs hatással a felügyelt karbantartási időszakra.
Hol vannak tárolva az automatikus biztonsági másolatok, és hogyan kezelhetem a megőrzésüket?
A rugalmas Azure Database for MySQL-kiszolgáló automatikusan létrehoz kiszolgálói biztonsági mentéseket, és tárolja őket felhasználó által konfigurált, helyileg redundáns tárolóban vagy georedundáns tárolóban. Ezek a biztonságimentés-fájlok nem exportálhatók. Az alapértelmezett biztonsági mentési megőrzési időszak hét nap. Igény szerint 1 és 35 nap között konfigurálhatja az adatbázis biztonsági mentését.
Hogyan érvényesíthetem a biztonsági másolatokat?
A sikeresen befejezett biztonsági másolatok rendelkezésre állásának ellenőrzéséhez a legjobb módszer a Biztonsági mentés és visszaállítás panelen a megőrzési időszakon belül készített teljes automatikus biztonsági másolatok megtekintése. Ha egy biztonsági mentés sikertelen, az nem szerepel a rendelkezésre álló biztonsági másolatok listájában, és a biztonsági mentési szolgáltatás 20 percenként megpróbál biztonsági másolatot készíteni, amíg a biztonsági mentés sikeres nem lesz. Ezek a biztonsági mentési hibák a kiszolgáló nagy tranzakciós éles terhelésének köszönhetők.
Hol látom a biztonsági mentés használatát?
Az Azure Portal Monitorozás lap – Metrikák szakaszában megtalálhatja a Használt biztonsági mentési tár metrikát, amely segíthet a teljes biztonsági mentési használat monitorozásában.
Mi történik a biztonsági másolataimmal, ha törlöm a kiszolgálót?
Ha törli a kiszolgálót, a kiszolgálóhoz tartozó összes biztonsági másolatot is törli, és nem állíthatók vissza. Az üzembe helyezés utáni kiszolgálói erőforrások véletlen törléssel vagy váratlan módosításokkal szembeni védelme érdekében a rendszergazdák felügyeleti zárolásokat használhatnak.
Mi történik a biztonsági másolatokkal a kiszolgáló visszaállításakor?
Ha visszaállít egy kiszolgálót, az mindig egy új nettó kiszolgáló létrehozását eredményezi, amelyet az eredeti kiszolgáló biztonsági másolatai alapján állítottak vissza. Az eredeti kiszolgálóról származó régi biztonsági másolat nem lesz átmásolva az újonnan visszaállított kiszolgálóra, és az eredeti kiszolgálón marad. Az újonnan létrehozott kiszolgáló esetében azonban az első pillanatkép biztonsági mentése közvetlenül a kiszolgáló létrehozása után lesz ütemezve, és a szolgáltatás biztosítja, hogy a rendszer a konfigurált kiszolgálómegőrzési időszaknak megfelelően készítsen és tárolja a napi automatikus biztonsági mentéseket.
Hogyan számítok fel és számlázok a biztonsági másolatok használatáért?
A rugalmas Azure Database for MySQL-kiszolgáló a kiépített kiszolgáló tárhelyének akár 100%-át is biztosítja biztonsági mentési tárolóként, hozzáadott költség nélkül. Minden további felhasznált biztonsági mentési tárterületet gb-ban kell fizetni havonta, a díjszabási modell szerint. A biztonsági mentési tár számlázását a kiválasztott biztonsági mentési megőrzési időszak és a választott biztonsági mentési redundancia is szabályozza, a kiszolgálón végzett tranzakciós tevékenységen kívül, amely hatással van a közvetlenül használt teljes biztonsági mentési tárterületre.
Hogyan őrzik meg a biztonsági másolatokat a leállított kiszolgálókhoz?
A leállított kiszolgálókhoz nem történik új biztonsági mentés. A kiszolgáló leállításakor (az adatmegőrzési időszakon belül) az összes régebbi biztonsági mentés megmarad a kiszolgáló újraindításáig, és azt jelzi, hogy az aktív kiszolgáló biztonsági mentési megőrzési időszaka melyik biztonsági mentésre vonatkozik.
Hogyan kell kiszámláznom a leállított kiszolgáló biztonsági mentéseit?
Amíg a kiszolgálópéldány le van állítva, a kiépített tárterületért (beleértve a kiépített IOPS-t) és a biztonsági mentési tárolóért (a megadott megőrzési időszakon belül tárolt biztonsági másolatokért) kell fizetnie. Az ingyenes biztonsági mentési tárterület a kiépített adatbázis méretére korlátozódik, és csak az aktív kiszolgálókra vonatkozik.
Hogyan védik a biztonsági mentési adataimat?
A rugalmas Azure Database for MySQL-kiszolgáló úgy védi a biztonsági mentési adatokat, hogy blokkolja azokat a műveleteket, amelyek a konfigurált megőrzési időszak alatt helyreállítási pontok elvesztéséhez vezethetnek. A megőrzési időszak alatt készített biztonsági másolatok csak a helyreállítás céljából olvashatók, és a megőrzési időszak után törlődnek. Emellett a rugalmas Azure Database for MySQL-kiszolgálón lévő biztonsági másolatok AES 256 bites titkosítással vannak titkosítva az inaktív adatokhoz.
Hogyan befolyásolja egy időponthoz kötött visszaállítási (PITR) művelet az IOPS használatát?
A rugalmas Azure Database for MySQL-kiszolgálón végzett PITR-művelet során létrejön egy új kiszolgáló, és az adatok át lesznek másolva a forráskiszolgáló tárolójából az új kiszolgáló tárhelyére. Ez a folyamat nagyobb IOPS-használatot eredményez a forráskiszolgálón. Az IOPS-használat növekedése normális jelenség, és nem jelez problémát a forráskiszolgálóval vagy a PITR-művelettel kapcsolatban. A PITR-művelet befejeződése után a forráskiszolgáló IOPS-használata visszatér a szokásos szintre.
Visszaállítással kapcsolatos kérdések
Hogyan visszaállítani a kiszolgálót? Az Azure Portal minden kiszolgáló esetében támogatja a pont-idő visszaállítást, így a felhasználók visszaállíthatják a legújabb vagy egyéni visszaállítási pontokat. Ha manuálisan szeretné visszaállítani a kiszolgálót a mysqldump/myDumper által készített biztonsági másolatokból, olvassa el az adatbázis visszaállítása a myLoader használatával című témakört.
Miért tart ennyi időt a visszaállítás?
A kiszolgáló helyreállításának becsült ideje több tényezőtől függ:
- Az adatbázisok mérete. A helyreállítási folyamat részeként az adatbázist az utolsó fizikai biztonsági mentésből kell hidratálni, így a helyreállításhoz szükséges idő arányos lesz az adatbázis méretével.
- A tranzakciós tevékenység aktív része, amelyet vissza kell játszani a helyreállításhoz. A helyreállítás az utolsó sikeres ellenőrzőponthoz hozzáadott tranzakciós tevékenységtől függően hosszabb időt is igénybe vehet.
- 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 feldolgozás alatt álló, egyidejű visszaállítási kérések száma.
- Az elsődleges kulcsok jelenléte az adatbázisban lévő táblákban. A gyorsabb helyreállítás érdekében fontolja meg az elsődleges kulcsok hozzáadását az adatbázis összes táblájához.
Hatással lesz a munkamenetszintű adatbázis változóinak módosítása a visszaállításra?
A munkamenetszintű változók módosítása és a DML-utasítások MySQL-ügyfél munkamenetben való futtatása hatással lehet a PITR (időponthoz kötött visszaállítás) műveletre, mivel ezek a módosítások nem lesznek rögzítve a biztonsági mentési és visszaállítási művelethez használt bináris naplóban. Például foreign_key_checks egy ilyen munkamenetszintű változó, amely ha le van tiltva egy olyan DML-utasítás futtatásához, amely megsérti az idegenkulcs-korlátozást, pitr (időponthoz kötött visszaállítás) hibát eredményez. Az ilyen forgatókönyvek egyetlen kerülő megoldása az lenne, ha a foreign_key_checks letiltásának időpontjánál korábbi PITR-időpontot választanánk ki. Azt javasoljuk, hogy NE módosítsa a munkamenet változóit a sikeres PITR-művelethez.