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
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:
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