A rugalmas Azure Database for MySQL-kiszolgáló üzletmenet-folytonosságának áttekintése
A következőkre vonatkozik: 
Azure Database for MySQL – rugalmas kiszolgáló
A rugalmas Azure Database for MySQL-kiszolgáló olyan üzletmenet-folytonossági képességeket tesz lehetővé, amelyek tervezett és nem tervezett leállás esetén védik az adatbázisokat. Az olyan funkciók, mint az automatizált biztonsági mentések és a magas rendelkezésre állás különböző hibavédelmi szinteket kezelnek különböző helyreállítási idővel és adatveszteség-kitettségekkel. A hibák elleni védelem érdekében az alkalmazás kialakításakor figyelembe kell vennie az egyes alkalmazások helyreállítási időkorlátját (RTO) és helyreállításipont-célkitűzését (RPO). Az RTO az állásidő-tűrés, az RPO pedig az adatveszteség-tűrés az adatbázis-szolgáltatás megszakadása után.
Az alábbi táblázat az Azure Database for MySQL rugalmas kiszolgáló által kínált funkciókat mutatja be.
| Szolgáltatás | Leírás | Korlátozások |
|---|---|---|
| Biztonsági mentés és helyreállítás | A szolgáltatás automatikusan elvégzi az adatbázisfájlok napi biztonsági mentését, és folyamatosan biztonsági másolatot készít a tranzakciónaplókról. A biztonsági másolatok 1 és 35 nap közötti időszakban is megőrizhetők. Az adatbázis-kiszolgálót bármikor visszaállíthatja a biztonsági mentés megőrzési időszakán belül. A helyreállítási idő a visszaállítandó adatok méretétől és a napló helyreállításának időpontjától függ. További részletekért tekintse meg a Fogalmak – Biztonsági mentés és visszaállítás című témakört. | A biztonsági mentési adatok a régión belül maradnak |
| Helyi redundáns biztonsági mentés | A szolgáltatás biztonsági mentései automatikusan és biztonságosan tárolódnak egy régión belüli helyi redundáns tárolóban és ugyanabban a rendelkezésre állási zónában. A helyileg redundáns biztonsági másolatok háromszor replikálják a kiszolgáló biztonsági mentési adatfájljait egyetlen fizikai helyen az elsődleges régióban. A helyileg redundáns biztonsági mentési tár legalább 99,99999999999%-os (11 kilences) tartósságot biztosít az objektumoknak egy adott évben. További részletekért tekintse meg a Fogalmak – Biztonsági mentés és visszaállítás című témakört. | Minden régióban alkalmazható |
| Zónaredundáns biztonsági mentés | 2024. december közepétől a szolgáltatás biztonsági másolatai zónaredundánsként konfigurálhatók a létrehozáskor. A zónaredundancia engedélyezése szinkron módon replikálja a tárfiókot az elsődleges régió három Azure rendelkezésre állási zónájában. Minden rendelkezésreállási zóna egy fizikailag elkülönített, független áramforrással, hűtéssel és hálózatkezelési megoldással rendelkező hely. A ZRS egy adott évben legalább 99,99999999999999%-os (12 9s) tárolási erőforrások tartósságát biztosítja. Ez a konfiguráció lehetővé teszi a közvetlen helyreállítást a zónakimaradások során. | 2024. december közepéig csak az üzleti szempontból kritikus számítási szinten támogatott. Csak olyan régiókban érhető el, ahol több zóna is elérhető |
| Georedundáns biztonsági mentés | A szolgáltatás biztonsági másolatai a létrehozáskor georedundánsként konfigurálhatók. A Georedundancia engedélyezése replikálja a kiszolgáló biztonsági mentési adatfájljait az elsődleges régió ™párosított régiójában, hogy regionális rugalmasságot biztosítson. A georedundáns biztonsági mentési tároló legalább 99,9999999999999999%-os (16 kilences) tartósságot biztosít az objektumoknak egy adott évben. További részletekért tekintse meg a Fogalmak – Biztonsági mentés és visszaállítás című témakört. | Minden Párosított Azure-régióban elérhető |
| Zónaredundáns magas rendelkezésre állás | A szolgáltatás magas rendelkezésre állású módban helyezhető üzembe, amely az elsődleges és a készenléti kiszolgálókat két különböző rendelkezésre állási zónában helyezi üzembe egy régión belül. A zónaredundáns magas rendelkezésre állás védelmet nyújt a zónaszintű hibák ellen, és segít csökkenteni az alkalmazás állásidejét a tervezett és nem tervezett leállási események során. Az elsődleges kiszolgáló adatait a rendszer szinkron módban replikálja a készenléti replikába. A leállási események során az adatbázis-kiszolgáló automatikusan feladatátvételt végez a készenléti replikára. További részletekért tekintse meg a Fogalmak – Magas rendelkezésre állás című témakört. | Általános célú és üzletileg kritikus számítási szintek támogatottak. Csak olyan régiókban érhető el, ahol több zóna is elérhető. |
| Prémium szintű fájlmegosztások | Az adatbázisfájlok rendkívül tartós és megbízható Prémium Szintű Azure-fájlmegosztásokban vannak tárolva, amelyek adatredundanciát biztosítanak a rendelkezésre állási zónában tárolt három replikával, automatikus adat-helyreállítási képességekkel. További részletekért tekintse meg a Premium-fájlmegosztásokat . | Rendelkezésre állási zónában tárolt adatok |
Tervezett állásidő-csökkentés
Az alábbiakban néhány tervezett karbantartási forgatókönyvet talál, amelyek állásidőt vonnak maga után:
| Forgatókönyv | Folyamat |
|---|---|
| Számítási skálázás (felhasználó) | Számítási skálázási művelet végrehajtásakor a rendszer egy új rugalmas kiszolgálót épít ki a skálázott számítási konfigurációval. A meglévő adatbázis-kiszolgálón engedélyezve van az aktív ellenőrzőpontok végrehajtása, az ügyfélkapcsolatok kiürítése, a nem véglegesített tranzakciók megszakítása, majd a leállítás. A tároló ezután az új kiszolgálóhoz lesz csatolva, és elindul az adatbázis, amely szükség esetén helyreállítást végez az ügyfélkapcsolatok elfogadása előtt. |
| Új szoftvertelepítés (Azure) | Az új szolgáltatások bevezetése vagy hibajavításai automatikusan a szolgáltatás tervezett karbantartása részeként történnek, és ütemezheti, hogy mikor történjenek ezek a tevékenységek. További információkért tekintse meg a dokumentációt, és tekintse meg a portált is |
| Alverziófrissítések (Azure) | A rugalmas Azure Database for MySQL-kiszolgáló automatikusan az Azure által meghatározott alverzióra javítja az adatbázis-kiszolgálókat. Ez a szolgáltatás tervezett karbantartásának részeként történik. Ez másodpercekben rövid állásidőt von maga után, és az adatbázis-kiszolgáló automatikusan újraindul az új alverzióval. További információkért tekintse meg a dokumentációt, és tekintse meg a portált is. |
Ha a rugalmas kiszolgáló zónaredundáns magas rendelkezésre állással van konfigurálva, a rugalmas kiszolgáló először a készenléti kiszolgálón, majd az elsődleges kiszolgálón végez műveleteket feladatátvétel nélkül. További részletekért tekintse meg a Fogalmak – Magas rendelkezésre állás című témakört.
Nem tervezett leállás kezelése
A nem tervezett állásidők előre nem látható hibák, például a mögöttes hardverhibák, a hálózatkezelési problémák és a szoftverhibák miatt fordulhatnak elő. Ha az adatbázis-kiszolgáló váratlanul leáll, ha magas rendelkezésre állással van konfigurálva [HA], akkor a készenléti replika aktiválódik. Ha nem, akkor a rendszer automatikusan kiépített egy új adatbázis-kiszolgálót. Bár a nem tervezett állásidőt nem lehet elkerülni, a rugalmas kiszolgáló úgy csökkenti az állásidőt, hogy automatikusan végrehajtja a helyreállítási műveleteket mind az adatbázis-kiszolgálón, mind a tárolási rétegeken emberi beavatkozás nélkül.
Nem tervezett állásidő: hibaforgatókönyvek és szolgáltatás-helyreállítás
Íme néhány nem tervezett hibaforgatókönyv és a helyreállítási folyamat:
| Forgatókönyv | Helyreállítási folyamat [nem HA] | Helyreállítási folyamat [HA] |
|---|---|---|
| Adatbázis-kiszolgáló hibája | Ha az adatbázis-kiszolgáló valamilyen mögöttes hardverhiba miatt leáll, a rendszer megszakítja az aktív kapcsolatokat, és megszakítja az esetleges gyenge műveletet. Az Azure megpróbálja újraindítani az adatbázis-kiszolgálót. Ha ez sikeres, akkor az adatbázis helyreállítása történik. Ha az újraindítás sikertelen, az adatbázis-kiszolgáló újraindítását megkísérli egy másik fizikai csomóponton. A helyreállítási idő (RTO) különböző tényezőktől függ, beleértve a hiba idején végzett tevékenységet, például a nagy tranzakciót és az adatbázis-kiszolgáló indítási folyamata során végrehajtandó helyreállítás mennyiségét. Az RPO nulla, mivel a véglegesített tranzakciók esetében nem várható adatvesztés. A MySQL-adatbázisokat használó alkalmazásokat úgy kell létrehozni, hogy észleljék és újrapróbálkozzák az elvetett kapcsolatokat és a sikertelen tranzakciókat. Amikor az alkalmazás újrapróbálkozza, a rendszer átirányítja a kapcsolatokat az újonnan létrehozott adatbázis-kiszolgálóra. A biztonsági mentésből más elérhető lehetőségek is visszaállíthatók. A PITR és a Geo visszaállítást is használhatja a párosított régióból. PITR : RTO: Változók, RPO=0sec Geo-visszaállítás: RTO: Változó RPO <1 óra. Az olvasási replikát dr. megoldásként is használhatja. Leállíthatja a replikációt, amely írásvédetté teszi az olvasási replikát (önállóan, majd átirányítja az alkalmazás forgalmát ebbe az adatbázisba). Az RTO a legtöbb esetben néhány perc, az RPO < pedig 1 óra. Az RTO és az RPO bizonyos esetekben sokkal magasabb lehet a különböző tényezőktől függően, például a helyek közötti késéstől, a továbbítandó adatok mennyiségétől és elsősorban az elsődleges adatbázis írási számítási feladatától függően. |
Ha az adatbázis-kiszolgáló meghibásodása vagy nem helyreállítható hibák észlelhetők, a készenléti adatbázis-kiszolgáló aktiválva lesz, ezáltal csökkentve az állásidőt. További részletekért tekintse meg a HA fogalmait ismertető oldalt. Az RTO várhatóan 60–120 s, az RPO=0 értékkel. Megjegyzés: A helyreállítási folyamat [nem HA] beállításai itt is érvényesek. |
| Tárolási hiba | Az alkalmazások nem látnak semmilyen hatást a tárolással kapcsolatos problémákra, például a lemezhiba vagy a fizikai blokk sérülésére. Mivel az adatokat három példányban tárolják, az adatok másolatát a túlélő tár szolgáltatja. A blokksérülések automatikusan ki lesznek javítva. Ha az adatok egy példánya elveszik, a rendszer automatikusan létrehozza az adatok új példányát. Ritka vagy legrosszabb esetben, ha minden másolat sérült, használhatjuk a georedundáns visszaállítást (párosított régió). Az RPO 1 óra lenne < , az RTO pedig eltérő lenne. Az olvasási replikát dr. megoldásként is használhatja a fentiekben leírtak szerint. |
Ebben a forgatókönyvben a beállítások megegyeznek a helyreállítási folyamat [nem HA] beállításaival. |
| Logikai/felhasználói hibák | A felhasználói hibák, például a véletlenül elvetett táblák vagy helytelenül frissített adatok helyreállítása egy időponthoz kötött helyreállítást (PITR) igényel, az adatok visszaállításával és helyreállításával egészen a hiba bekövetkezése előtti időpontig. A törölt rugalmas kiszolgálói erőforrást a kiszolgáló törlésétől számított öt napon belül helyreállíthatja. A törölt kiszolgálók visszaállításának részletes útmutatója: [lásd a dokumentált lépéseket] (.). /flexible-server/how-to-restore-dropped-server.md). 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. |
Ezek a felhasználói hibák nem védettek magas rendelkezésre állással, mivel minden felhasználói művelet replikálva van a készenléti állapotba is. Ebben a forgatókönyvben a lehetőségek ugyanazok, mint a helyreállítási folyamat [nem HA] esetében |
| Rendelkezésreállási zóna meghibásodása | Bár ez egy ritka esemény, ha zónaszintű hiba miatt szeretne helyreállni, georedundáns visszaállítást végezhet egy párosított régióból. Az RPO 1 óra lenne <, az RTO pedig eltérő lenne. Az olvasási replikát dr. megoldásként is használhatja, ha replikát hoz létre más rendelkezésre állási zónában. Az RTO\RPO a fent részletezetthez hasonló. |
Ha engedélyezte a zónaredundáns HA-t, a rugalmas kiszolgáló automatikus feladatátvételt hajt végre a készenléti helyre. További részletekért tekintse meg a HA-fogalmakat . Az RTO várhatóan 60–120 s, az RPO=0 értékkel. A biztonsági mentésből más elérhető lehetőségek is visszaállíthatók. A PITR és a Geo visszaállítást is használhatja a párosított régióból. PITR: RTO: Változók, RPO=0 mp Geo-visszaállítás: RTO: Változók, RPO <1 h Megjegyzés: Ha engedélyezve van az azonos zónás HA, a beállítások megegyeznek a helyreállítási folyamat [nem HA] beállításaival. |
| Régióhiba | Bár ez egy ritka esemény, ha régiószintű hiba miatt szeretne helyreállni, az adatbázis-helyreállítást úgy végezheti el, hogy létrehoz egy új kiszolgálót az ugyanazon előfizetés alatt elérhető legújabb georedundáns biztonsági mentéssel a legújabb adatok eléréséhez. A rendszer egy új rugalmas kiszolgálót helyez üzembe a kijelölt régióban. A visszaállítás időtartama az előző biztonsági mentéstől és a helyreállítandó tranzakciónaplók számától függ. Az RPO a legtöbb esetben 1 óra lenne <, és az RTO eltérő lenne. | Ebben a forgatókönyvben a beállítások megegyeznek a helyreállítási folyamat [nem HA] beállításaival. |
Követelmények és korlátozások
Régió adattárolása
Alapértelmezés szerint a rugalmas Azure Database for MySQL-kiszolgáló nem helyezi át vagy tárolja az ügyféladatokat a telepített régióból. Az ügyfelek azonban dönthetnek úgy, hogy engedélyezik a georedundáns biztonsági mentéseket, vagy régiók közötti replikációt is beállítanak az adatok egy másik régióban való tárolásához.