Magas rendelkezésre állás az Azure Database for MySQL-ben

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 szolgáltatás garantált magas rendelkezésre állást biztosít a pénzügyileg támogatott szolgáltatásiszint-szerződéssel (SLA) 99,99%-os üzemidővel. Az Azure Database for MySQL magas rendelkezésre állást biztosít a tervezett események, például a felhasználó által kezdeményezett skálázási számítási művelet, valamint olyan váratlan események esetén, mint a mögöttes hardverek, szoftverek vagy hálózati hibák. Az Azure Database for MySQL gyorsan helyre tud állni a legkritikusabb körülmények között, így gyakorlatilag nincs alkalmazás-leállás a szolgáltatás használatakor.

Az Azure Database for MySQL alkalmas olyan kritikus fontosságú adatbázisok futtatására, amelyek magas üzemidőt igényelnek. Az Azure-architektúrára épülő szolgáltatás eredendően magas rendelkezésre állási, redundancia- és rugalmassági képességekkel rendelkezik az adatbázisok tervezett és nem tervezett leállások miatti állásidejének csökkentésére anélkül, hogy további összetevőket kellene konfigurálnia.

Összetevők az Azure Database for MySQL-ben

Komponens	Ismertetés
MySQL-adatbáziskiszolgáló	Az Azure Database for MySQL biztonsági, elkülönítési, erőforrás-védelmi és gyors újraindítási képességet biztosít az adatbázis-kiszolgálók számára. Ezek a képességek megkönnyítik az olyan műveleteket, mint a skálázás és az adatbázis-kiszolgáló helyreállítási művelete az adatbázis tranzakciós tevékenységétől függően 60–120 másodperc alatt leállás után. Az adatbázis-kiszolgáló adatmódosításai általában egy adatbázis-tranzakció kontextusában történnek. Minden adatbázis-módosítás szinkron módon lesz rögzítve írási naplók (ib_log) formájában az Azure Storage-on, amely az adatbázis-kiszolgálóhoz van csatolva. Az adatbázis-ellenőrzőpont-folyamat során az adatbázis-kiszolgáló memóriájából származó adatoldalak is ki lesznek ürítve a tárolóba.
Távoli tárolás	Minden MySQL fizikai adatfájl és naplófájl az Azure Storage-ban van tárolva, amely úgy van tervezve, hogy három adatpéldányt tároljon egy régión belül az adatredundancia, a rendelkezésre állás és a megbízhatóság biztosítása érdekében. A tárolási réteg független az adatbázis-kiszolgálótól is. Leválasztható egy sikertelen adatbázis-kiszolgálóról, és 60 másodpercen belül újracsatlakoztatható egy új adatbázis-kiszolgálóra. Emellett az Azure Storage folyamatosan figyeli a tárolási hibákat. Ha blokksérülést észlel, az automatikusan ki lesz javítva egy új tárpéldány példányosításával.
Átjáró	Az átjáró adatbázis-proxyként működik, és az összes ügyfélkapcsolatot az adatbázis-kiszolgálóhoz irányítja.

Tervezett állásidő-csökkentés

Az Azure Database for MySQL úgy van megtervezve, hogy magas rendelkezésre állást biztosítson a tervezett állásidő-műveletek során.

Íme néhány tervezett karbantartási forgatókönyv:

Forgatókönyv	Ismertetés
Számítási skálázás felfelé/lefelé	Amikor a felhasználó számítási skálázási fel- vagy leskálázási műveletet hajt végre, a rendszer kiépít egy új adatbázis-kiszolgálót a skálázott számítási konfigurációval. A régi 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 le lesz választva a régi adatbázis-kiszolgálóról, és az új adatbázis-kiszolgálóhoz van csatolva. Amikor az ügyfélalkalmazás újrapróbálkozik a kapcsolattal, vagy megpróbál új kapcsolatot létesíteni, az átjáró átirányítja a kapcsolatkérést az új adatbázis-kiszolgálóra.
Tárterület felskálázása	A tárterület vertikális felskálázása online művelet, és nem szakítja meg az adatbázis-kiszolgálót.
Új szoftvertelepítés (Azure)	Az új funkciók bevezetése vagy hibajavításai automatikusan a szolgáltatás tervezett karbantartásának részeként történnek. További információkért tekintse meg a dokumentációt, és ellenőrizze a portált is.
Alverziófrissítések	Az Azure Database for MySQL automatikusan az Azure által meghatározott alverzióra frissíti az adatbázis-kiszolgálókat. Ez a szolgáltatás tervezett karbantartásának részeként történik. A tervezett karbantartás során előfordulhat, hogy az adatbázis-kiszolgáló újraindul vagy feladatátvételt végez, ami az adatbázis-kiszolgálók rövid elérhetetlenségét eredményezheti a végfelhasználók számára. Az Azure Database for MySQL-kiszolgálók tárolókban futnak, így az adatbázis-kiszolgáló újraindítása általában gyors, várhatóan 60–120 másodperc alatt fejeződik be. A mérnöki csapat gondosan figyeli a teljes tervezett karbantartási eseményt, beleértve az egyes kiszolgálók újraindításait is. A kiszolgáló feladatátvételi ideje az adatbázis-helyreállítási időtől függ, ami hosszabb ideig online állapotba kerülhet, ha a feladatátvétel időpontjában nagy tranzakciós tevékenység van a kiszolgálón. A hosszabb újraindítási idő elkerülése érdekében ajánlott elkerülni a hosszú ideig futó tranzakciókat (tömeges terheléseket) a tervezett karbantartási események során. További információkért tekintse meg a dokumentációt, és ellenőrizze a portált is.

Nem tervezett leállás kezelése

A nem tervezett állásidő 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 fordulhat elő. Ha az adatbázis-kiszolgáló váratlanul leáll, a rendszer 60–120 másodperc alatt automatikusan üzembe helyezi az új adatbázis-kiszolgálót. A távoli tároló automatikusan az új adatbázis-kiszolgálóhoz lesz csatolva. A MySQL-motor WAL- és adatbázisfájlok használatával hajtja végre a helyreállítási műveletet, és megnyitja az adatbázis-kiszolgálót, hogy lehetővé tegye az ügyfelek számára a csatlakozást. A nem véglegesített tranzakciók elvesznek, és az alkalmazásnak újra kell próbálkoznia. Bár a nem tervezett állásidőt nem lehet elkerülni, az Azure Database for MySQL úgy csökkenti az állásidőt, hogy automatikusan végrehajtja a helyreállítási műveleteket az adatbázis-kiszolgálón és a tároló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 hibaforgatókönyv, és az Azure Database for MySQL automatikus helyreállítása:

Forgatókönyv	Automatikus helyreállítás
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. A rendszer automatikusan üzembe helyez egy új adatbázis-kiszolgálót, és a távoli adattárat az új adatbázis-kiszolgálóhoz csatolja. Az adatbázis helyreállítása után az ügyfelek az átjárón keresztül csatlakozhatnak az új adatbázis-kiszolgálóhoz. 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. Az alkalmazás újrapróbálkozásakor az átjáró transzparensen átirányítja a kapcsolatot az újonnan létrehozott adatbázis-kiszolgálóra.
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 adatok tárolása 3 példányban történik, 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.

Az alábbiakban néhány olyan hibaforgatókönyvet talál, amelyekhez felhasználói művelet szükséges a helyreállításhoz:

Forgatókönyv	Helyreállítási terv
Régióhiba	A régió meghibásodása ritka esemény. Ha azonban egy régióhiba elleni védelemre van szüksége, konfigurálhat egy vagy több olvasási replikát más régiókban vészhelyreállításra (DR). (A részletekért tekintse meg ezt a cikket az olvasási replikák létrehozásáról és kezeléséről.) Régiószintű hiba esetén manuálisan előléptetheti a másik régióban konfigurált olvasási replikát éles adatbázis-kiszolgálóként.
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. Ha az adatbázis-kiszolgáló összes adatbázisa helyett csak az adatbázisok vagy adott táblák egy részhalmazát szeretné visszaállítani, visszaállíthatja az adatbázis-kiszolgálót egy új példányban, exportálhatja a táblákat a mysqldump használatával, majd a visszaállítással visszaállíthatja ezeket a táblákat az adatbázisba.

Összesítés

Az Azure Database for MySQL gyors újraindítási képességet biztosít az adatbázis-kiszolgálóknak, a redundáns tárolásnak és az átjáróról való hatékony útválasztásnak. További adatvédelem érdekében konfigurálhatja a biztonsági másolatok georeplikálását, és üzembe helyezhet egy vagy több olvasási replikát más régiókban is. Az eredendően magas rendelkezésre állási képességekkel az Azure Database for MySQL védelmet nyújt az adatbázisoknak a leggyakoribb kimaradásokkal szemben, és az üzemidős SLA iparágvezető, finanszírozással támogatott 99,99%-át kínálja. Mindezek a rendelkezésre állási és megbízhatósági képességek lehetővé teszik, hogy az Azure legyen az ideális platform a kritikus fontosságú alkalmazások futtatásához.

További lépések

• További információ az Azure-régiókról
• Tudnivalók az átmeneti csatlakozási hibák kezeléséről
• Megtudhatja, hogyan replikálhatja az adatokat olvasási replikákkal