Az Azure Database for MySQL megbízhatósága

Azure Database for MySQL egy teljes körűen felügyelt adatbázis-szolgáltatás, amely részletes vezérlést és rugalmasságot biztosít az adatbázis-kezelési funkciók és a konfigurációs beállítások felett. A szolgáltatás magas rendelkezésre állási (HA) és vészhelyreállítási (DR) képességeket biztosít a követelményeknek megfelelően.

Azure használatakor a megbízhatóság közös felelősség. Microsoft számos képességet biztosít a rugalmasság és a helyreállítás támogatására. Ön a felelős azért, hogy megértse, hogyan működnek ezek a képességek az összes használt szolgáltatáson belül, és válassza ki azokat a képességeket, amelyekre szüksége van az üzleti célok és az üzemidő céljainak eléréséhez.

Ez a cikk bemutatja, hogyan lehet Azure Database for MySQL rugalmassá tenni a különböző lehetséges kimaradásokkal és problémákkal szemben, beleértve az átmeneti hibákat, a rendelkezésre állási zónák kimaradásait, a régiókimaradásokat és a szolgáltatáskarbantartást. Azt is ismerteti, hogyan használható biztonsági másolatok más típusú problémákból való helyreállításra, és kiemeli a Azure Database for MySQL szolgáltatásiszint-szerződéssel (SLA) kapcsolatos legfontosabb információkat.

Termelési üzembe helyezési javaslatok

Az Azure Well-Architected-keretrendszer megbízhatósági, biztonsági, költség-, üzemeltetési és teljesítménybeli javaslatokat kínál. Annak megértéséhez, hogy ezek a területek hogyan befolyásolják egymást, és hogyan járulnak hozzá egy megbízható Azure Database for MySQL megoldáshoz, tekintse meg az architektúrával kapcsolatos ajánlott eljárásokat Azure Database for MySQL.

A megbízhatósági architektúra áttekintése

Ez a szakasz a szolgáltatás megbízhatóság szempontjából leginkább releváns működésének néhány fontos aspektusát ismerteti. A szakasz bemutatja a logikai architektúrát, amely tartalmazza a telepített és használt erőforrásokat és funkciókat. Emellett a fizikai architektúrát is ismerteti, amely részletesen bemutatja, hogyan működik a szolgáltatás a borítók alatt.

Logikai architektúra

A Azure Database for MySQL használatakor üzembe helyez egy kiszolgálót, amely az adatbázis-kiszolgáló támogatásához szükséges számítási és tárolási erőforrásokat jelöli. Egy vagy több adatbázist helyez üzembe a kiszolgálón.

Kiszolgálókat üzembe helyezhet a burstable, az általános célú és a memóriaoptimalizált számítási szinteken. Minden számítási szint különböző számítási feladatokhoz van optimalizálva.

Az általános szolgáltatásarchitektúráról és az üzembehelyezési modellekről további információt Azure Database for MySQL áttekintésében talál.

Fizikai architektúra

• Számítási és tárolási elkülönítés: Azure Database for MySQL számítási és tárolási elkülönítési architektúrát használ a HA támogatásához. Az adatbázismotor virtuális gépen (VM) fut. Az adatfájlok Azure Storage vannak tárolva, amely szinkron módon három másolatot tart fenn az adatokról a tárolási hardverhibák elleni védelem érdekében. A kiszolgáló HA-konfigurációjától függően az adatfájlok zónaredundáns tárolóban (ZRS) vagy helyi redundáns tárolóban (LRS) tárolhatók.

• HA: Igény szerint engedélyezheti a HA-konfigurációt a kiszolgálón. Ha engedélyezi a HA-konfigurációt, a szolgáltatás egy meleg készenléti replikakiszolgálót helyez üzembe és tart fenn. Az elsődleges kiszolgálón végzett adatváltozások szinkron módon replikálódnak a készenléti replikakiszolgálóra, hogy az elsődleges kiszolgáló meghibásodása során ne legyen adatvesztés.

  Az architektúra elválasztja a számítási réteget a tárolási rétegtől, ami lehetővé teszi a szolgáltatás számára a különböző típusú hibák megfelelő kezelését. A nagyobb rugalmasság érdekében eloszthatja a kiszolgálókat a rendelkezésre állási zónák között.

  A készenléti replikakiszolgáló ugyanabban a virtuálisgép-konfigurációban van üzembe helyezve, mint az elsődleges kiszolgáló, beleértve a virtuális magokat, a tárterületet és a hálózati beállításokat.

  Feladatátvétel végrehajtásával válthat a kiszolgálók között. Ha az elsődleges kiszolgáló meghibásodik, használjon nem tervezett feladatátvételeket , és a tervezett feladatátvételeket akkor használja, ha a feladatátvétel során minimalizálnia kell az alkalmazások állásidejét.

  További információ: HA a Azure Database for MySQL.

• Backups: Azure Database for MySQL automatikusan létrehoz kiszolgálói biztonsági mentéseket. További információ: Biztonsági mentés és visszaállítás.

Rugalmasság átmeneti hibákhoz

Az átmeneti hibák rövid, időszakos meghibásodások a komponensekben. Gyakran előfordulnak elosztott környezetben, például a felhőben, és ezek a műveletek szokásos részei. Az átmeneti hibák rövid idő elteltével kijavítják magukat. Fontos, hogy az alkalmazások kezelni tudják az átmeneti hibákat, általában az érintett kérések újrapróbálásával.

Minden felhőalapú alkalmazásnak követnie kell az Azure átmeneti hibakezelési útmutatást, amikor a felhőben üzemeltetett API-kkal, adatbázisokkal és más összetevőkkel kommunikálnak. További információ: Átmeneti hibák kezelésére vonatkozó javaslatok.

Az alkalmazásoknak kezelnie kell az átmeneti csatlakozási hibákat, amelyek karbantartás, skálázási műveletek vagy hálózatkimaradások során fordulhatnak elő. Kövesse az alábbi javaslatokat:

• Ha az alkalmazás átmeneti hibákba ütközik, exponenciális visszakapcsolással próbálkozzon újra a művelettel. Növelje az újrapróbálkozások közötti késést, és korlátozza a kísérletek számát. Ha a művelet az újrapróbálkozások maximális száma után is sikertelen marad, kezelje hibaként.

• Ha lehetséges, használjon olyan ügyfélkódtárakat , amelyek automatikusan kezelik az újrapróbálkozásokat.

• Az írási műveletek során előforduló átmeneti hibák gondos megfontolást igényelnek. Fontolja meg az írási műveletek idempotenssé tételét, hogy többször is futtathassa őket.

Rugalmasság a rendelkezésre állási zóna hibáival szemben

A rendelkezésre állási zónák fizikailag különálló adatközpont-csoportok egy Azure régión belül. Ha egy zóna meghibásodik, a szolgáltatások a fennmaradó zónák egyikére is át tudnak adni feladatokat.

Válassza ki a rendelkezésre állási zóna támogatási típusát a HA-konfiguráción keresztül. Ha engedélyezi a HA-t, Azure Database for MySQL üzembe helyez egy készenléti replikakiszolgálót az elsődleges kiszolgáló mellett. Ez a HA-modell segít biztosítani, hogy a véglegesített adatok soha ne vesszenek el a hibák során. Bármelyik HA-alapú üzemi modellt is választja, a szolgáltatás szinkron módon véglegesíti az adatokat az elsődleges és a készenléti replikakiszolgálón is. Ha az elsődleges kiszolgáló megszakad, a kiszolgáló automatikusan átesik a készenléti replikakiszolgálóra.

A szolgáltatás Azure Files prémium szintű tárolóban tárolja az adatokat. A kiszolgáló HA-konfigurációjától függően ZRS-t vagy LRS-t használ, amely három adatmásolatot tárol a rendelkezésre állási zónákon belül vagy a rendelkezésre állási zónák között.

Azure Database for MySQL két rendelkezésreállási zónakonfigurációs típust támogat a HA használatakor:

• Zónaredundáns HA: A zónaredundancia a zóna rugalmasságának legmagasabb szintjét biztosítja, ha egy elsődleges kiszolgálót helyez üzembe egy rendelkezésre állási zónában, egy készenléti replikakiszolgálót pedig egy másik rendelkezésre állási zónában. A készenléti replikakiszolgáló az elsődleges kiszolgálóhoz hasonló számítási, tárolási és hálózati konfigurációt használ. A zónaredundáns konfiguráció biztosítja a teljes verem fizikai elkülönítését az elsődleges és a készenléti kiszolgálók között.

  Kiválaszthatja az elsődleges és a készenléti kiszolgálók rendelkezésre állási zónáit.

  Használjon zónaredundáns üzembe helyezéseket éles kiszolgálókhoz.

  

  A diagram három szakaszból áll. Az első szakasz az olyan ügyfélalkalmazásokat sorolja fel, mint Azure virtuális gépek, Azure Kubernetes Service (AKS) és Azure App Service. A következő szakasz az 1. rendelkezésre állási zóna címkével van ellátva. Az elsődleges kiszolgálót és két alszakaszt, a számítást és a tárolást tartalmazza, pontozott vonallal elválasztva. A harmadik szakasz a 2. rendelkezésre állási zóna címkével van ellátva. Az 1. rendelkezésre állási zónát tükrözi, de tartalmazza a készenléti kiszolgálót. A nyilak az ügyfélalkalmazásokból egy standard terheléselosztóra mutatnak. Egy nyíl a terheléselosztóról egy virtuális gépre mutat az elsődleges kiszolgálón az 1. rendelkezésre állási zónában. A kétirányú nyilak összekapcsolják a virtuális gépet és a prémium szintű fájlmegosztást, valamint az SSD-t. Egy másik nyílpont a prémium fájlmegosztástól a biztonsági mentési blobtárolóig. Egy nyíl, amely a tárolási alapú aszinkron replikációs pontokra mutat az 1. rendelkezésre állási zónától a 2. rendelkezésre állási zónáig.

  Az írási műveletek kis mértékben növelhetik a véglegesítés késését, mivel a szolgáltatás szinkron módon replikálja az adatokat a készenléti kiszolgálóra. Átlagosan 5% és 10% nagyobb késés várható az alkalmazásírások és -véglegesítések esetében. A hatás a számítási feladatok, a kiválasztott termékváltozat és a régió szerint változik.

• Helyi redundáns HA: Az elsődleges és a készenléti kiszolgálók ugyanazt a rendelkezésre állási zónát használják. Ha megszakad az elsődleges kiszolgáló, de a zóna továbbra is kifogástalan állapotban van, a kiszolgáló automatikusan átesik a készenléti kiszolgálóra.

  A helyi redundáns üzembe helyezés egyetlen rendelkezésre állási zónán belül biztosítja a HA-t. Védelmet nyújt a csomópontszintű hibák ellen, és segít csökkenteni az alkalmazások állásidejét a tervezett és nem tervezett leállási események során. Ez azonban nem véd az adott zónában történő kimaradás ellen. A rendelkezésre állási zónákkal rendelkező régiókban ezt a konfigurációt zonális vagy egyzónásnak is nevezik.

  

  A diagram három szakaszból áll. Az első szakasz az olyan ügyfélalkalmazásokat sorolja fel, mint a Azure virtuális gépek, az AKS és az App Service. A következő szakasz az 1. rendelkezésre állási zóna címkével van ellátva. Két külön szakaszt tartalmaz az elsődleges kiszolgálóhoz és a készenléti kiszolgálóhoz. A pontozott vonal az egyes kiszolgálók szakaszát két alszakaszra osztja, a számításra és a tárolásra. A nyilak az ügyfélalkalmazásokból egy standard terheléselosztóra mutatnak. Egy nyíl a terheléselosztóról egy virtuális gépre mutat az elsődleges kiszolgálón az 1. rendelkezésre állási zónában. A kétirányú nyilak összekapcsolják a virtuális gépet és a prémium szintű fájlmegosztást, valamint az SSD-t. Egy másik nyílpont a prémium fájlmegosztástól a biztonsági mentési blobtárolóig. Egy nyíl, amely tárolóalapú aszinkron replikációs pontokat jelöl az elsődleges kiszolgálóról a készenléti kiszolgálóra. A harmadik, 2. rendelkezésre állási zóna címkével ellátott szakasz üres.

  Helyi redundáns HA használata csak a következő esetekben:

  • Ha szokatlanul késésre érzékeny alkalmazásokkal rendelkezik, ellenőrzi, hogy szükség van-e az elsődleges és a másodlagos replika közötti késés minimalizálására, és más architekturális megközelítések használatával tervezi a zónarugalmasság kialakítását.

  • Ha olyan régióba telepít, amely nem támogatja a rendelkezésre állási zónákat. Ebben a forgatókönyvben a régió egyetlen zónaként működik, így a helyi redundáns HA az egyetlen lehetőség.

  A kiszolgálók ugyanabban a zónában találhatók, ami csökkentheti az írási késést az adott zónában üzembe helyezendő alkalmazások esetében.

Ha HA nélkül konfigurálja a kiszolgálót, az egyetlen kiszolgálón fut. Ha a kiszolgáló vagy a zóna meghibásodik, a kiszolgáló nem érhető el.

Követelmények

• Régiótámogatás: Azure Database for MySQL a Azure régiótól függően különböző rendelkezésreállási zónákonfigurációkat támogat. A régiók teljes listáját, beleértve a rendelkezésre állási zónák támogatásának típusait és az egyes régiókra vonatkozó konkrét szempontokat, tekintse meg Azure régiókat.

• Szolgáltatási szint: A HA általános célú vagy memóriaoptimalizált rétegeket igényel. A kipukkasztható szint nem támogatja a HA -t (zónaredundáns vagy helyi redundáns).

Cost

Ha engedélyezi a HA-t, a készenléti kiszolgálót az elsődleges kiszolgálóéval megegyező mértékben hozza létre és fizeti ki. A rendelkezésre állási zóna konfigurációja nem befolyásolja a költségeket. Az adatreplikálás nem jár költségekkel a rendelkezésre állási zónákon belül vagy között. A biztonsági mentési tárterület mennyiségétől függően előfordulhat, hogy a biztonsági mentési tárterületért is fizetnie kell. Részletes díjszabási információkért lásd: Azure Database for MySQL díjszabás.

Megfontolások

• Elsődleges kulcsok: Használjon elsődleges kulcsokat az összes táblában, mert ez a módszer csökkenti a replikáció és a feladatátvétel idejét.

• Korlátozások és ismert problémák: Tekintse át a korlátozások és az ismert problémák listáját.

A rendelkezésre állási zóna támogatásának konfigurálása

A rendelkezésre állási zónák kiszolgálói támogatásának konfigurálásához konfigurálja a HA beállításait.

Megjegyzés:

Amikor kiválasztja a használni kívánt rendelkezésre állási zónákat, valójában a logikai rendelkezésre állási zónát választja ki. Ha más számítási feladatok összetevőit egy másik Azure-előfizetésben helyezi üzembe, előfordulhat, hogy egy másik logikai rendelkezésre állási zónaszámmal férnek hozzá ugyanahhoz a fizikai rendelkezésre állási zónához. További információ: Fizikai és logikai rendelkezésre állási zónák.

• Hozzon létre egy zónaredundáns kiszolgálót. Ha tudni szeretné, hogyan hozhat létre kiszolgálót ha- és zónaredundanciával, tekintse meg az alábbi cikkeket:

  • Azure Portal: Az Azure Database for MySQL zónaredundáns magas rendelkezésre állásának kezelése az Azure Portal használatával.

  • Azure CLI: Zónaredundáns HA kezelése az Azure Database for MySQL-ben az Azure CLI használatával.

• Hozzon létre egy helyi redundáns kiszolgálót. Ha helyi redundáns HA-val rendelkező kiszolgálót szeretne létrehozni egyetlen rendelkezésre állási zónában, a Azure CLI vagy más programozott üzembe helyezési módszert kell használnia. A Azure CLI útmutatásért lásd: A HA engedélyezése a kiszolgáló létrehozása során.

• Meglévő kiszolgálók rendelkezésreállási zónájának konfigurációjának módosítása. Ha már rendelkezik kiszolgálóval, a rendelkezésre állási zónák támogatásának engedélyezéséhez követett megközelítés a kiszolgáló kezdeti konfigurációjától függ.

  • Ha egy meglévő kiszolgálót zónaredundáns HA-ra szeretne módosítani, át kell telepítenie egy új kiszolgálóra. További információ: Migrálás meglévő kiszolgálóról zónaredundáns kiszolgálóra.

  • Meglévő kiszolgáló helyi redundáns HA-ra váltása:

    1. Ha engedélyezve van, tiltsa le a HA-t.

    2. A helyi redundanciájú HA engedélyezése. A Azure CLI vagy más programozott üzembe helyezési módszert kell használnia. Azure CLI útmutatásért lásd: Zónaredundáns HA kezelése Azure Database for MySQL a Azure CLI használatával.

• Tiltsa le a HA-t. A HA letiltása eltávolítja a készenléti replikakiszolgálót, így a kiszolgáló nem rugalmas a zónaszintű kimaradásokkal szemben. Ha azonban a georedundáns biztonsági mentések engedélyezve vannak, akkor is helyreállíthatja a kiszolgálót egy másik régióban a biztonsági másolatok használatával. További információt a HA letiltása című témakörben talál.

Viselkedés, ha minden zóna kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgálókat HA-val és a rendelkezésre állási zónák támogatásával konfigurálja, és az összes rendelkezésre állási zóna működőképes.

• Zónák közötti művelet: A MySQL-ügyfélalkalmazások az adatbázis-kiszolgáló teljes tartománynevével (FQDN) csatlakoznak az elsődleges kiszolgálóhoz. Kerülje az elsődleges kiszolgáló IP-címének használatát, mert az IP-cím változhat, beleértve a feladatátvételek során is.

  Azure Database for MySQL aktív-passzív konfigurációt használ, amelyben az elsődleges kiszolgáló kezeli az elsődleges rendelkezésre állási zónában lévő összes adatbázis-kapcsolatot és lekérdezést. A készenléti replikakiszolgáló nem szolgálja ki az ügyfélforgalmat a normál műveletek során.

• Zónaközi adatreplikáció: Az írási műveletek véglegesítése az elsődleges kiszolgálón történik, és a rendszer a ZRS használatával szinkron módon írja az adatokat a készenléti kiszolgáló naplóiba. Az elsődleges kiszolgáló nem várja meg, hogy a készenléti kiszolgáló alkalmazza a naplókat, de mivel a naplók ZRS-ben találhatók, akkor is elérhetők, ha replika vagy zónahiba történik.

  A replikáció hatása a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függően eltérő:

  • Zónaredundáns: Mivel a kiszolgálók külön zónákban vannak, ez a megközelítés nulla adatvesztést biztosít zónahiba esetén. Ezt a helyzetet úgy is ismerték, hogy a zónahibák esetében nulla helyreállításipont-célkitűzést (RPO) érünk el.

    A zónák közötti replikáció azonban kis mértékű extra késést eredményezhet. Átlagosan 5% és 10% nagyobb késés várható az alkalmazásírások és -véglegesítések esetében, de a hatás a számítási feladatok, a kiválasztott termékváltozat és régió szerint változik.

  • Helyi redundáns: A rendszer nem replikálja a forgalmat a zónák között.

  Megjegyzés:

  A rendszer valós időben replikálja az összes módosítást a készenléti replikakiszolgálóra, beleértve a nem szándékos felhasználói hibákat, például egy tábla véletlen elvetése vagy helytelen adatfrissítések. Az azonnali replikáció miatt nem használhatja a készenléti replikát a helyreállításhoz. A felhasználói hibákból való helyreállításhoz időponthoz kötött visszaállítást kell végrehajtania egy biztonsági másolatból. További információ: Biztonsági mentés és visszaállítás.

Viselkedés zónahiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgálókat HA-val és a rendelkezésre állási zónák támogatásával konfigurálja, és a rendelkezésre állási zóna kimarad.

• Észlelés és válasz: Az Azure rendszeres időközönként ellenőrzi az elsődleges és a készenléti kiszolgálók állapotát. Ha több pingelés után az állapotfigyelés azt észleli, hogy az elsődleges kiszolgáló nem érhető el, a szolgáltatás automatikus feladatátvételt kezdeményez a készenléti kiszolgálóra. Az állapotmonitorozási algoritmus több adatpontot használ a hamis pozitív helyzetek elkerülése érdekében.

  Zónahiba esetén a viselkedés a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függően eltérő:

  • Zone-redundáns: Azure Database for MySQL automatikusan észleli a rendelkezésre állási zónák hibáit több kiszolgálóvégpont folyamatos figyelésével. További információért lásd: Az automatikus feladatátvétel-észlelés működése a HA-val rendelkező kiszolgálókon.

    A lehetséges HA-állapottípusok megtekintéséhez tekintse meg a HA figyelése című témakört. Ha egy zóna meghibásodik, Azure nem tervezett feladatátvételt kezdeményez a készenléti kiszolgálóra anélkül, hogy beavatkozást kellene végrehajtania.

  • Helyi redundáns: Az elsődleges és a készenléti kiszolgáló sem érhető el, ha a helyi redundáns kiszolgálót üzemeltető rendelkezésre állási zóna elérhetetlenné válik. Ebben a forgatókönyvben a szolgáltatás nem biztosít automatikus feladatátvételt. Ön a felelős a zónakimaradás észleléséért és helyreállítási műveletek végrehajtásáért, például a zónaredundáns biztonsági másolatok egy másik rendelkezésre állási zónában vagy régióban lévő különálló kiszolgálóra történő visszaállításáért.

• Értesítés: Microsoft nem értesíti automatikusan, ha egy zóna nem működik. A Azure Resource Health használatával azonban figyelheti az egyes erőforrások állapotát, és beállíthat Resource Health riasztásokat a problémákról való értesítéshez. A Azure Service Health használatával is megismerheti a szolgáltatás általános állapotát, beleértve a zónahibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

  Azure Database for MySQL nem tervezett feladatátvétel esetén Azure Resource Health eseményt hoz létre.

• Aktív kérések: Ha egy rendelkezésre állási zóna elérhetetlenné válik, az érintett zónában lévő kiszolgálókra irányuló folyamatban lévő kérelmek leállhatnak. Az alkalmazásoknak újra meg kell próbálkoznia ezeket a kéréseket. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

• Várható adatvesztés: Az adatvesztés mértéke a kiszolgáló rendelkezésre állási zónájának konfigurációjától függ.

  • Zónaredundáns: A zóna feladatátvétele során nulla adatvesztés várható a különböző zónákban lévő elsődleges és készenléti kiszolgálók közötti szinkron replikáció következtében.

  • Helyi redundáns: Az érintett zónában lévő kiszolgálókon lévő adatok nem érhetők el, amíg a zóna helyre nem áll.

• Várható állásidő: Az állásidő mértéke a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

  • Zónaredundáns: A hiba miatti átállás jellemzően 60–120 másodperc alatt fejeződik be. Ha az ügyfelek rövid idő elteltével újrapróbálkozással megfelelően kezelik az átmeneti hibákat , általában elkerülik a jelentős hatást.

  • Helyi redundáns: Az érintett zónában lévő kiszolgálók mindaddig nem érhetők el, amíg a rendelkezésre állási zóna helyre nem áll.

• Újraelosztás: A forgalom átirányítási viselkedése a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

  • Zónaszinten redundáns: A hibaátvétel után a készenléti kiszolgáló lesz az új elsődleges kiszolgáló, és megkezdi az új kapcsolatok fogadását. Azure helyreállítás után automatikusan létrehoz egy készenléti kiszolgálót az eredeti elsődleges zónában. További információ: Nem tervezett feladatátvétel.

  • Helyi redundáns: Ha egy zóna nem érhető el, a kiszolgáló nem érhető el. Ha rendelkezik egy különálló kiszolgálóval, amelyet egy másik rendelkezésre állási zónában vagy régióban hozott létre, Ön felelős a forgalomnak az adott kiszolgálóra történő átirányításáért.

Zóna helyreállítása

A zóna helyreállítási viselkedése a kiszolgáló által használt rendelkezésre állási zóna konfigurációjától függ.

• Zónaredundáns: Amikor a rendelkezésre állási zóna helyreáll, Azure Database for MySQL automatikusan újraépíti a készenléti kiszolgálót a helyreállított zónában, és szinkronizálja azt az aktuális elsődleges kiszolgálóval. A helyreállított zóna ezután készenléti helyként szolgál. A szolgáltatás nem helyezi vissza automatikusan az elsődleges szerepkört az eredeti zónába a szükségtelen fennakadások elkerülése érdekében. Ha vissza szeretné adni az elsődlegest az eredeti zónába, manuálisan kezdeményezheti a tervezett feladatátvételt.

• Helyi redundáns: Miután a zóna kifogástalan állapotban van, a zónában lévő kiszolgálók ismét elérhetők. Ön felel a számítási feladatokhoz szükséges zóna-helyreállítási eljárásokért és adatszinkronizálásért.

Zónahibák tesztelése

A zónahibák tesztelésének lehetőségei a példány által használt rendelkezésre állási zóna konfigurációjától függenek.

• Zónaredundáns: Egy tervezett feladatátvétel kezdeményezésével tesztelheti az alkalmazás feladatátvételi rugalmasságát. Használjon tervezett feladatátvételt egy nem tervezett kiesés szimulálására, miközben a számítási feladat fut, és figyelje meg az alkalmazás leállási idejét. Szimulációk futtatása nem gyártási környezetekben vagy csendes időben. További információ: Tervezett feladatátvétel.

• Helyi redundáns: Nem szimulálhat teljes zónakimaradást, de szimulálhatja, hogy a kiszolgáló nem érhető el, hasonlóan ahhoz, ami a zónakimaradás során történik. További információkért lásd a következő cikkeket:

  • Azure portál: Állítsa le és indítsa el a Azure Database for MySQL rugalmas kiszolgálópéldányt.

  • Azure CLI: Indítsa újra, állítsa le és indítsa el a Azure Database for MySQL rugalmas kiszolgálópéldányt.

Rugalmasság régiószintű hibákhoz

Azure Database for MySQL támogatja a régiók közötti olvasási replikákat, amelyekkel az adatbázis szinkronizált másolatát egy másik régióban tarthatja fenn a gyorsabb helyreállítás érdekében.

A támogatott régiókban georedundáns biztonsági másolatokat is használhat a régiók közötti helyreállításhoz. A biztonsági mentések azonban általában több állásidőt és adatvesztést foglalnak magukban, mint a replikáció. További információ: Biztonsági mentés és visszaállítás.

Régiók közötti olvasási replikák

Olvasási replikák üzembe helyezése az adatbázisok régiószintű hibák elleni védelméhez. Minden olvasási replika külön Azure Database for MySQL kiszolgáló. Amikor egy olvasási replikát egy második Azure régióban helyez el, az adatbázis-kiszolgáló képes rugalmasságot biztosítani egy régiószintű probléma esetén. Legfeljebb 10 olvasási replikát helyezhet üzembe, amelyek opcionálisan különböző Azure régiókban is lehetnek.

A MySQL fizikai replikációs technológiája aszinkron módon frissíti az olvasási replikákat az elsődleges régió forráskiszolgálójáról, ami azt jelenti, hogy a replikák lemaradhatnak a forrástól. A régiók közötti olvasási replikák opcionálisan csak olvasható számítási feladatokat is kiszolgálhatnak a globálisan elosztott alkalmazások késésének csökkentése vagy a forráskiszolgálóról származó olvasási forgalom kiszervezése érdekében. Az olvasási replikák funkcióival és a kapcsolódó szempontokkal kapcsolatos további információkért lásd: Olvasási replikák.

A diagram egy elsődleges régióból, egy másodlagos régióból és egy ikoncímkével ellátott alkalmazásból áll. Egy folytonos nyíl az alkalmazás ikonjáról az elsődleges kiszolgálóra mutat az elsődleges régióban. Az „aszinkron replikáció” feliratú pontozott nyíl az elsődleges kiszolgálóról a másodlagos régióban lévő olvasási replikára mutat.

Ha az elsődleges régió meghibásodik, manuálisan is végrehajthatja a feladatátvételt, így a másodlagos replika lesz az elsődleges kiszolgáló. A manuális feladatátvételhez le kell állítania a replikációs folyamatot, amely előlépteti az olvasási replikát egy olvasási-írási kiszolgálóra. Az aszinkron replikáció miatt az átállás adatvesztést okozhat. Az alkalmazásnak csatlakoznia kell az új elsődleges kiszolgálóhoz, és Ön felel az alkalmazás újrakonfigurálásáért.

A diagram egy elsődleges régióból, egy másodlagos régióból és egy ikoncímkével ellátott alkalmazásból áll. Az elsődleges régió elsődleges kiszolgálója fölötti körön belüli x érték ebben a régióban előforduló hibát jelöl. Egy folytonos nyíl az alkalmazás ikonjától a másodlagos régióban lévő, feladatátvétel utáni elsődleges kiszolgálóra mutat.

Megjegyzés:

Ez a szakasz összefoglal néhány fontos információt arról, hogy az olvasási replikák hogyan támogathatják a régiószintű hibákra való rugalmasságot. A teljesítmény javításához, valamint a nagyméretű, földrajzilag elosztott felhasználói bázisok kiszolgálásához olvasási replikákat is használhat.

Követelmények

• Region support: A régiók közötti olvasási replikákat bármely olyan régióban létrehozhatja, amely támogatja a Azure Database for MySQL. Nem korlátozódik Azure párosított régiókra.

• Számítási szintek: Az általános célú és memóriaoptimalizált számítási szintek támogatják az olvasási replikákat. A Burstable szintje nem támogatja az olvasási replikákat.

Megfontolások

• Konfigurációs különbségek: Replika létrehozásakor több beállítást örököl a forráskiszolgálótól, beleértve a számítási generációt, a virtuális magokat és a tárterületet. Ezeket az értékeket a létrehozás után testre szabhatja az olvasási replikán, de a legjobb, ha egyenlő vagy nagyobb értékeket használ, hogy a replika lépést tudjon tartani a forrás változásaival.

• Replikációs késés figyelése: Az aszinkron replikációs folyamat replikációs késést igényel, amely több tényezőtől függően változhat. Ha a replikáció késése nagyon magas, a kiszolgáló problémákat tapasztalhat. Fontos a replikáció késésének monitorozása, hogy azok eszkalálása előtt enyhíthesse a problémákat. További információkért lásd: Replikáció figyelése.

• HA: Az olvasási replikákon nem engedélyezhető a HA, és amikor feladatátvétellel elsődleges kiszolgálóvá válnak, akkor sem rendelkeznek HA-val. Ön felelős a HA konfigurálásáért, miután feladatátvétel történt egy replikára.

Cost

Az olvasási replikák számítási és tárolási költségeket, valamint régiók közötti adatátviteli díjakat vonnak maga után a replikációhoz. Részletes árképzési információkért lásd: Azure Database for MySQL árképzés és Szélessávú adatátvitel árképzése.

Többrégiós támogatás konfigurálása

• Olvasási replika létrehozása: Az olvasási replika létrehozásának módjáról az alábbi cikkekben olvashat:

  • Azure portál: Olvasási replikák létrehozása és kezelése Azure Database for MySQL rugalmas kiszolgálón a Azure portál használatával

  • Azure CLI: Olvasási replikák létrehozása és kezelése az Azure Database for MySQL rugalmas kiszolgálóban az Azure CLI használatával

  A replikákat a forráskiszolgáló létrehozása után csak akkor konfigurálhatja, ha a forráskiszolgáló fut és elérhető.

• Replikáció leállítása: A replikáció leállításáról további információt a replikakiszolgálóra történő replikáció leállítása című témakörben talál.

• Olvasási replika törlése: Az olvasási replika törléséről a Replikakiszolgáló törlése című témakörben olvashat.

Viselkedés, ha minden régió kifogástalan

Ez a szakasz azt ismerteti, hogy mire számíthat, ha egy másik régióban olvasási replikával konfigurálja a kiszolgálót, és minden régió működőképes:

• Forgalomirányítás régiók között: Normál műveletek során az alkalmazásnak olvasási-írási forgalmat kell irányítania az elsődleges régió forráskiszolgálójához. Igény szerint az olvasási kérelmeket az olvasási replikához is irányíthatja.

• Régiók közötti adatreplikálás: A régiók közötti olvasási replikák aszinkron replikációt használnak a forráskiszolgáló teljesítményére gyakorolt hatás minimalizálása érdekében. A replikáció késésének mértéke számos tényezőtől függ, beleértve az írási terhelést, valamint a forráskiszolgáló és a replikák közötti késést. A replikáció késése általában legalább néhány perc, de sokkal hosszabb is lehet. További információ: Monitor replikáció, és részletes útmutatásért lásd a Monitor replikációt a Azure portálon.

Viselkedés régióhiba esetén

Ez a szakasz azt ismerteti, hogy mire számíthat, ha a kiszolgálót régióközi olvasási replika-támogatásra konfigurálja, és az elsődleges régióban kimaradás történik.

• Észlelés és reagálás: Ön felelős azért, hogy észlelje az elsődleges régióban bekövetkező kiesést, és manuálisan aktiválja a feladatátvételt. Ez a művelet a nem duplikált adatok elvesztését eredményezheti.

  Fontos

  Az Ön feladata a feladatátvétel elindítása. Az Azure még regionális hiba esetén sem vált át automatikusan az olvasási replikákra.

  A hiba esetén történő átváltáshoz a következő lépéseket kell elvégeznie:

  1. Replikáció leállítása. Ez az eljárás visszavonhatatlan, és a kiszolgáló nem készíthető újra replikává. A folyamat adatvesztést eredményez. A művelet következményeiről további információt a replikáció leállítása című témakörben talál.

  2. Konfigurálja újra az alkalmazást az új elsődleges kiszolgáló használatára.

  További információért lásd: Hibatűrés.

• Értesítés: A Microsoft nem értesíti Önt automatikusan, ha egy régió nem működik. A Azure Service Health használatával azonban megismerheti a szolgáltatás általános állapotát, beleértve a régióhibákat is, és beállíthat Service Health-riasztásokat a problémákról való értesítéshez.

• Aktív kérések: Ha a forráskiszolgáló nem érhető el, a forrásrégió összes aktív kapcsolata megszakad. A feladatátvételi folyamat befejeződése után az alkalmazásoknak újra meg kell próbálkoznia az új elsődleges kiszolgálóval való kapcsolatok létesítésére.

• Várható adatvesztés: Régiókimaradás esetén olyan feladatátvételt kell végrehajtania, amely leállítja a replikációt. Ez a folyamat a nem duplikált adatok végleges elvesztését eredményezi.

  Az adatvesztés mértéke a replikáció késésétől függ a kimaradás időpontjában. A replikáció késése általában legalább néhány perc, de sokkal hosszabb is lehet. További információkért lásd: Replikáció figyelése.

• Várható állásidő: A replikáció leállítása általában a művelet aktiválása után két percen belül fejeződik be. Önnek kell újrakonfigurálnia az alkalmazásokat az új elsődleges kiszolgálóhoz való csatlakozáshoz. Az újrakonfigurálás végrehajtásához szükséges idő is hozzájárul az általános állásidőhöz.

• Forgalom átirányítása: Önnek kell újrakonfigurálnia az alkalmazásokat az új elsődleges kiszolgálóhoz való csatlakozáshoz.

  Megjegyzés:

  Miután feladatátvételt végzett az olvasási replika elsődleges kiszolgálóvá alakításához, a kiszolgáló nem engedélyezte a HA-t. Manuálisan kell engedélyeznie a HA-t, vagy bele kell foglalnia az automatizálásba.

Régió helyreállítása

Amikor a régió helyreáll, Ön felel a failback műveletekért, hogy az elsődleges régióban újraindulhasson a működés. Microsoft nem helyezi át automatikusan az elsődleges kiszolgálót. Létrehozhat egy új olvasási replikát az elsődleges régióban, majd egy másik feladatátvételi folyamatot hajthat végre az elsődleges régió műveleteinek visszaállításához. Fontolja meg az alábbi módszerek egyikét attól függően, hogy az alkalmazás képes-e elviselni az állásidőt vagy az adatvesztést:

• Vegye offline állapotba az alkalmazást, és várja meg, amíg a replikáció felzárkózik az összes módosításhoz. Ehhez a megközelítéshez olyan alkalmazás-állásidőre van szükség, amely nagyjából megegyezik a replikáció késésével.

• Végezze el a feladatátvételt, és fogadja el a nem duplikált adatok elvesztését.

Ne feledje, hogy az alkalmazások szükség szerint újrakonfigurálásával is csatlakozhat az új elsődleges kiszolgálóhoz.

Régióhibák tesztelése

Az olvasási replika feladatátvételi eljárásainak rendszeres tesztelése annak biztosítása érdekében, hogy a folyamatok érvényesek legyenek, és hogy a képességek megfeleljenek a helyreállítási időkorlátra (RTO) és az RPO-ra vonatkozó követelményeknek.

A read Replica bármikor átveheti az elsődleges kiszolgáló szerepét, még akkor is, ha minden régió kifogástalan állapotban van. Javasoljuk, hogy ezeket a teszteket nem gyártási környezetben végezze el, mert az adatvesztést okozhat, és manuális feladat-visszavételt igényel.

A DR-stratégia részeként rendszeresen végezzen teljes körű helyreállítási gyakorlatokat. Ezek a gyakorlatok magukban foglalják az adatérvényesítést, az alkalmazásfunkciók tesztelését és a dokumentált visszaállítási eljárásokat.

Biztonsági mentés és visszaállítás

Azure Database for MySQL automatikusan biztonsági másolatot készít az adatokról, így a biztonsági mentés megőrzési időszakán belül bármikor visszaállíthatja azokat. Ez a védelem segít elkerülni az adatok véletlen sérülését és törlését. Microsoft teljes mértékben felügyeli a biztonsági másolatokat a kiszolgáló rendelkezésre állásának megszakítása nélkül. A biztonsági másolatok a teljes biztonsági mentést és a tranzakciónapló biztonsági mentését is tartalmazzák.

• Biztonsági mentési tár: Ha zónaredundáns HA-val konfigurálja a kiszolgálót, a rendszer A ZRS-ben tárolja a biztonsági mentéseket. HA nélkül vagy helyi redundáns HA-val konfigurált kiszolgálók esetében a rendszer LRS-ben tárolja a biztonsági mentéseket.

  A párokkal rendelkező Azure régiókban a kiszolgáló létrehozásakor georedundáns tárolást (GRS) konfigurálhat a biztonsági mentésekhez. Ez a módszer replikálja a biztonsági másolatokat a Azure párosított régióba a régióhibák elleni további védelem érdekében. A rendszer aszinkron módon replikálja a biztonsági mentéseket.

  Az alapértelmezett biztonsági mentési megőrzési idő 7 nap, de a megőrzést 35 napra is meghosszabbíthatja. Minden biztonsági mentés titkosítva van.

• Visszaad: Az időponthoz kötött visszaállítás (PITR) lehetővé teszi az adatbázis visszaállítását a biztonsági mentés megőrzési időszakának bármely pillanatára. A visszaállítási folyamat új adatbázis-kiszolgálót hoz létre egy új, felhasználó által megadott kiszolgálónévvel. Használhatja az új kiszolgálót as-is, vagy adatokat másolhat belőle.

  Georedundáns biztonsági mentés visszaállításakor új kiszolgálót hoz létre a párosított régióban. Egyes régiókban az Univerzális Geo-Restore használatával visszaállíthatja a georedundáns biztonsági mentést olyan régióba, amely nem az elsődleges régió párosított régiója.

  Ezzel a képességgel helyreállíthatja a véletlen adatmódosításokat, alkalmazáshibákat vagy tesztelési forgatókönyveket.

A legtöbb megoldás esetében nem szabad kizárólag biztonsági másolatokra támaszkodnia. Ehelyett használja az útmutatóban ismertetett egyéb képességeket a rugalmassági követelmények támogatására. A biztonsági másolatok azonban védelmet nyújtanak bizonyos kockázatok ellen, amelyeket más megközelítések nem. További információ: Mi a redundancia, a replikáció és a biztonsági mentés?

További információ: Biztonsági mentés és visszaállítás az Azure Database for MySQL-ban.

A szolgáltatás karbantartásával szembeni rugalmasság

Azure Database for MySQL automatikusan kezeli a kritikus karbantartási feladatokat, beleértve a mögöttes hardver, az operációs rendszer és az adatbázismotor javítását. A szolgáltatás biztonsági frissítéseket, szoftverfrissítéseket és alverziófrissítéseket tartalmaz a tervezett karbantartás részeként. További információ: Ütemezett karbantartás Azure Database for MySQL.

Annak érdekében, hogy a kiszolgáló elérhető maradjon a karbantartási időszakokban, kövesse az alábbi javaslatokat:

• A karbantartási időszakok során kerülje a felügyeleti műveleteket. Ne végezzen kiszolgálófelügyeleti műveleteket, amíg a karbantartás folyamatban van, mert ezek a műveletek befolyásolhatják a kiszolgáló megbízhatóságát.

• Alkalmazzon közel nulla leállással járó karbantartást. Ha a kiszolgálón engedélyezve van a HA, és megfelel az egyéb jogosultsági feltételeknek, a karbantartási műveletek általában 10–30 másodpercen belül befejeződnek. Ha engedélyezi a HA-t, a karbantartási műveletek általában gördülő frissítéseket használnak az állásidő minimalizálása érdekében. Az időszakos karbantartási tevékenységek, például az alverziófrissítések először a készenléti replikán történnek. Az állásidő csökkentése érdekében a készenléti kiszolgáló előléptethető elsődlegesre, így a számítási feladatok továbbra is futtathatók, miközben a karbantartási feladatok a fennmaradó csomóponton lesznek alkalmazva. Ez a szekvenálás arra vonatkozik, hogy a kiszolgáló zónaredundáns vagy helyi redundáns HA-t használ-e. További információ: Közel nulla állásidő-karbantartás.

• Egyéni karbantartási időszakok konfigurálása. Konfigurálhatja a karbantartási ütemezést rendszerszintű felügyeletre, vagy egyéni karbantartási időszakot is meghatározhat, hogy minimálisra csökkentse az üzleti műveletekre gyakorolt hatást. A tervezett karbantartási műveleteket is átütemezheti. Ütemezze a karbantartást alacsony tevékenységű időszakokban az üzleti hatás minimalizálása érdekében. További információ: A Azure Database for MySQL.

• Újrapróbálkozási logika implementálása. Győződjön meg arról, hogy az alkalmazások képesek kezelni a karbantartás újraindítása során esetlegesen előforduló rövid kapcsolati megszakításokat. Ha az alkalmazásokat rugalmassá szeretné tenni az ilyen típusú problémákhoz, tekintse meg az átmeneti hibák rugalmasságát.

• Virtuális Kanári-karbantartás engedélyezése fejlesztési és tesztelési kiszolgálókon. A Virtual Canary karbantartása korai hozzáférést biztosít a frissítésekhez. A fejlesztési és tesztelési kiszolgálókon való engedélyezésével ellenőrizheti, hogy a közelgő frissítések nem érintik-e a számítási feladatokat, mielőtt elérnék az éles kiszolgálókat. További információért lásd: Virtuális kanári-karbantartás.

Szolgáltatásiszint-szerződés

A Azure szolgáltatások szolgáltatásiszint-szerződése (SLA) leírja az egyes szolgáltatások várható elérhetőségét, valamint azokat a feltételeket, amelyeket a megoldásnak teljesítenie kell az adott rendelkezésre állási elvárás eléréséhez. További információ: SLAs for online szolgáltatások.

Azure Database for MySQL a kiszolgáló konfigurációja alapján különböző rendelkezésre állási SLA-kat biztosít:

• Zónaredundáns HA-val konfigurált kiszolgálók.
• Helyi redundáns HA-val konfigurált kiszolgálók.
• HA nélkül konfigurált kiszolgálók.

Kapcsolódó tartalom

• Azure megbízhatóság
• Az Azure Database for MySQL ajánlott bevált módszerei
• ÁTtekintés az Azure Database for MySQL üzletmenet-folytonosságáról