Megosztás a következőn keresztül:

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

A rugalmas Azure Database for MySQL-kiszolgáló lehetővé teszi a magas rendelkezésre állás automatikus feladatátvétellel történő konfigurálását. Ez a megoldás biztosítja, hogy a hibák soha ne okozzanak véglegesített adatok elvesztését, és hogy az adatbázis ne legyen egyetlen meghibásodási pont a szoftverarchitektúrában. A magas rendelkezésre állás konfigurálásakor a rugalmas kiszolgáló automatikusan kiépít és kezel egy készenléti replikát. Az elsődleges és a másodlagos replikákért is fizetnie kell a kiosztott számításért és tárolásért. Két magas rendelkezésre állású architektúramodell érhető el:

  • Zónaredundáns magas rendelkezésre állás. Ez a lehetőség az infrastruktúra teljes elkülönítését és redundanciát biztosít több rendelkezésre állási zónában. A legmagasabb szintű rendelkezésre állást biztosítja, de az alkalmazás redundanciának a zónák közötti konfigurálását igényli. Akkor válassza a zónaredundáns HA-t, ha védelmet szeretne nyújtani a rendelkezésre állási zónában fellépő infrastruktúra-hibák ellen, és ha a rendelkezésre állási zónán belüli késés elfogadható. A zónaredundáns HA csak a kiszolgáló létrehozásakor engedélyezhető. A zónaredundáns HA az Azure-régiók egy részhalmazában érhető el, ahol a régió több rendelkezésre állási zónát támogat, és a zónaredundáns Prémium fájlmegosztások elérhetők.

  • Helyi redundáns magas rendelkezésre állás. Ez a beállítás alacsonyabb hálózati késésű infrastruktúra-redundanciát biztosít, mivel az elsődleges és a készenléti kiszolgálók ugyanabban a rendelkezésre állási zónában vannak. Magas rendelkezésre állást biztosít anélkül, hogy konfigurálnia kellene az alkalmazás redundanciát a zónák között. Válassza a helyire redundáns HA lehetőséget, ha egyetlen rendelkezésre állási zónán belül szeretné elérni a legmagasabb rendelkezésre állási szintet a legalacsonyabb hálózati késéssel. A helyi redundáns HA minden Olyan Azure-régióban elérhető, ahol rugalmas Azure Database for MySQL-kiszolgálót használhat.

Zónaredundáns magas rendelkezésre állású (HA) architektúra

Ha zónaredundáns magas rendelkezésre állású kiszolgálót helyez üzembe, az Azure két kiszolgálót hoz létre:

  • Egy elsődleges kiszolgáló egy rendelkezésre állási zónában.
  • Egy készenléti replikakiszolgáló ugyanazon Azure-régió egy másik rendelkezésre állási zónájában. A készenléti replikakiszolgáló konfigurációja megegyezik az elsődleges kiszolgáló konfigurációval, beleértve a számítási szintet, a számítási méretet, a tárterület méretét és a hálózati konfigurációt.

A rendelkezésre állási zónát az elsődleges kiszolgálóhoz és a készenléti replikához is kiválaszthatja. A készenléti adatbázis-kiszolgálók és a készenléti alkalmazások ugyanabban a zónában való elhelyezése csökkenti a késést. Emellett segít felkészülni a vészhelyreállítási helyzetekre és a "zónaleállítási" forgatókönyvekre.

Diagram a zónaredundáns magas rendelkezésre állás architektúrájáról.

Az adatok és naplófájlok zónaredundáns tárolóban (ZRS) vannak tárolva. A készenléti kiszolgáló folyamatosan olvassa és visszajátssza a naplófájlokat az elsődleges kiszolgáló tárfiókjából, amelyet a társzintű replikáció véd.

Feladatátvétel esetén:

  • A készenléti replika aktiválódik.
  • Az elsődleges kiszolgáló bináris naplófájljai továbbra is érvényesek a készenléti kiszolgálóra, hogy online állapotba hozzák az elsődleges kiszolgálón az utolsó véglegesített tranzakcióhoz.

A ZRS-ben lévő naplók akkor is elérhetők, ha az elsődleges kiszolgáló nem érhető el. Ez a rendelkezésre állás segít biztosítani, hogy ne legyen adatvesztés. A készenléti replika aktiválása és a bináris naplók alkalmazása után az aktuális készenléti replikakiszolgáló átveszi az elsődleges kiszolgáló szerepét. A DNS úgy frissül, hogy az ügyfélkapcsolatok közvetlenek legyenek az új elsődlegeshez az ügyfél újracsatlakozásakor. A feladatátvétel teljesen átlátható az ügyfélalkalmazásból, és nem igényel semmilyen műveletet Öntől. A HA-megoldás ezután lehetőség szerint visszahozza a régi elsődleges kiszolgálót, és készenléti állapotba helyezi.

Az adatbázis-kiszolgáló nevével csatlakoztathatja az alkalmazásokat az elsődleges kiszolgálóhoz. A megoldás nem teszi elérhetővé a készenléti replika adatait a közvetlen hozzáféréshez. A véglegesítések és írások akkor lesznek nyugtázva, ha a naplófájlok ki vannak ürítve az elsődleges kiszolgáló ZRS-ében. A ZRS-tárolóban használt szinkronizálási replikációs technológia miatt 5–10 százalékos késés várható az alkalmazásírások és -véglegesítések esetében.

Az automatikus biztonsági mentések, mind a pillanatképek, mind a naplók biztonsági mentése az elsődleges adatbázis-kiszolgáló zónaredundáns tárolóján történik.

Helyi redundáns magas rendelkezésre állású (HA) architektúra

Ha helyi redundáns HA-val helyez üzembe egy kiszolgálót, két kiszolgálót hoz létre ugyanabban a zónában:

  • Elsődleges kiszolgáló
  • Olyan készenléti replikakiszolgáló, amely az elsődleges kiszolgálóval azonos konfigurációval rendelkezik (számítási szint, számítási méret, tárterület mérete és hálózati konfiguráció)

A készenléti kiszolgáló egy külön virtuális géppel (számítással) biztosítja az infrastruktúra redundanciát. Ez a redundancia csökkenti a feladatátvételi időt és az alkalmazás és az adatbázis-kiszolgáló közötti hálózati késést a megosztottság miatt.

Diagram a helyi redundáns magas rendelkezésre állás architektúrájáról.

Az adatok és naplófájlok helyileg redundáns tárolóban (LRS) vannak tárolva. A készenléti kiszolgáló folyamatosan olvassa és visszajátssza a naplófájlokat az elsődleges kiszolgáló tárfiókjából, amelyet társzintű replikáció véd.

Feladatátvétel esetén:

  • A készenléti replika aktiválódik.
  • Az elsődleges kiszolgáló bináris naplófájljai továbbra is érvényesek a készenléti kiszolgálóra, hogy online állapotba hozzák az elsődleges kiszolgálón az utolsó véglegesített tranzakcióhoz.

Az LRS-ben lévő naplók akkor is elérhetők, ha az elsődleges kiszolgáló nem érhető el. Ez a rendelkezésre állás segít biztosítani, hogy ne legyen adatvesztés. A készenléti replika aktiválása és a bináris naplók alkalmazása után az aktuális készenléti replika átveszi az elsődleges kiszolgáló szerepét. A DNS frissül, hogy átirányítsa a kapcsolatokat az új elsődlegesre az ügyfél újracsatlakozásakor. A feladatátvétel teljesen átlátható az ügyfélalkalmazásból, és nem igényel semmilyen műveletet Öntől. A HA-megoldás ezután lehetőség szerint visszahozza a régi elsődleges kiszolgálót, és készenléti állapotba helyezi.

Az adatbázis-kiszolgáló neve összekapcsolja az alkalmazásokat az elsődleges kiszolgálóval. A készenléti replika adatai nem érhetők el közvetlen hozzáférés céljából. A véglegesítések és írások akkor lesznek nyugtázva, ha a naplófájlok ki vannak ürítve az elsődleges kiszolgáló LRS-ében. Mivel az elsődleges és a készenléti replika ugyanabban a zónában található, kevesebb replikációs késés és kisebb késés van az alkalmazáskiszolgáló és az adatbázis-kiszolgáló között. A helyi redundáns beállítás nem biztosít magas rendelkezésre állást, ha a függő infrastruktúrák leállnak az adott rendelkezésre állási zónához. Van állásidő, amíg az összes függő szolgáltatás újra online állapotba nem kerül az adott rendelkezésre állási zónához.

Az automatikus biztonsági mentések, mind a pillanatképek, mind a naplók biztonsági mentése helyileg redundáns tárolón történik az elsődleges adatbázis-kiszolgálóról.

Feljegyzés

Zónaredundáns és helyi redundáns HA esetén is:

  • Ha hiba történik, a készenléti replika számára az elsődleges szerepkör átvételéhez szükséges idő attól függ, hogy mennyi ideig tart a bináris napló visszajátszása az elsődleges tárfiókból a készenléti állapotba. A feladatátvételi idő csökkentéséhez használja az elsődleges kulcsokat az összes táblában. A feladatátvételi idő általában 60 és 120 másodperc között tart.
  • A készenléti kiszolgáló nem érhető el olvasási vagy írási műveletekhez. Passzív készenléti állapot, amely lehetővé teszi a gyors feladatátvételt.
  • Mindig használjon teljes tartománynevet (FQDN) az elsődleges kiszolgálóhoz való csatlakozáshoz. Ne használjon IP-címet a csatlakozáshoz. Ha feladatátvétel történik, az elsődleges és a készenléti kiszolgálói szerepkörök váltása után megváltozhat egy DNS A rekord. Ez a módosítás megakadályozza, hogy az alkalmazás csatlakozzon az új elsődleges kiszolgálóhoz, ha a kapcsolati sztringben IP-címet használ.

Feladatátvételi folyamat

Az Azure Database for MySQL feladatátvételi folyamata során a rendszer automatikusan átvált az elsődleges kiszolgálóról a készenléti replikára. Ez a kapcsoló biztosítja a folytonosságot, és minimalizálja az állásidőt. Ha a rendszer hibát észlel, előlépteti a készenléti replikát az új elsődleges kiszolgálóvá. A rendszer az eredeti elsődleges kiszolgáló bináris naplófájljait alkalmazza a készenléti replikára. Ez a folyamat szinkronizálja a készenléti replikát az utolsó véglegesített tranzakcióval, és nem okoz adatvesztést. Ez a zökkenőmentes átmenet segít fenntartani az adatbázis-szolgáltatás magas rendelkezésre állását és megbízhatóságát.

Feljegyzés

A DNS-gyorsítótárazással kapcsolatos feladatátvételi idő függőségének csökkentése érdekében 2025 októberétől minden nyilvános hozzáféréssel vagy privát kapcsolattal létrehozott új HA-kiszolgáló bevezeti az új architektúrát, amely minden HA-kiszolgálóhoz dedikált SLB-t tartalmaz. A MySQL adatforgalmi útvonalának kezelésével az SLB kiküszöböli a DNS-módosítások szükségességét a feladatátvétel során, és jelentősen javítja a feladatátvételi teljesítményt. A forgalmat a feladatátvétel során az aktuális elsődleges példányhoz irányítja át terheléselosztási szabályokkal. A meglévő, nyilvános hozzáféréssel vagy privát kapcsolattal rendelkező kiszolgálók fokozatosan migrálva lesznek a hatás minimalizálása érdekében. A korai migrálást előnyben részesítő ügyfelek letilthatják és újra engedélyezhetik a HA-t. Ez a funkció nem támogatott a virtuális hálózatok integrációjával privát hozzáférést használó kiszolgálók esetében.

Tervezett: kényszerített feladatátvétel

A rugalmas Azure Database for MySQL-kiszolgáló kényszerített feladatátvétele lehetővé teszi, hogy manuálisan kényszerítse ki a feladatátvételt. Ez a funkció lehetővé teszi a funkciók tesztelését az alkalmazásforgatókönyvekkel, és segít felkészülni a kimaradásokra.

A kényszerített feladatátvétel elindít egy feladatátvételt, amely aktiválja a készenléti replikát, hogy a DNS-rekord frissítésével az adatbázis-kiszolgáló nevével azonos nevű elsődleges kiszolgálóvá váljon. Az eredeti elsődleges kiszolgáló újraindul, és átvált a készenléti replikára. Az ügyfélkapcsolatok megszakadnak, és újra kell csatlakozniuk a műveletek folytatásához.

A teljes feladatátvételi idő az aktuális számítási feladattól és az utolsó ellenőrzőponttól függ. Általában 60–120 másodpercet vesz igénybe.

Feljegyzés

Egy Azure Resource Health-esemény egy tervezett feladatátvétel során jön létre. Az esemény azt a feladatátvételi időt jelöli, amely alatt a kiszolgáló nem érhető el. A bal oldali panelen a Resource Health elemen kiválasztva láthatók az aktivált események. Az állapot a felhasználó által kezdeményezett vagy manuális feladatátvételt "Nem érhető el" értékként jelöli, és "Tervezett" címkével van megjelölve. Példa : "A feladatátvételi műveletet egy jogosult felhasználó aktiválta (tervezett)". Ha az erőforrás hosszabb ideig ebben az állapotban marad, nyisson meg egy támogatási jegyet , és segítünk Önnek.

Nem tervezett: automatikus feladatátvétel

A szolgáltatás nem tervezett leállása szoftverhibák vagy infrastruktúrahibák, például számítási, hálózati vagy tárolási hibák miatt fordulhat elő. Az áramkimaradások az adatbázis rendelkezésre állását is befolyásolhatják. Ha az adatbázis elérhetetlenné válik, a készenléti replikára történő replikáció leáll, és a készenléti replika lesz az elsődleges adatbázis. DNS-frissítések történnek, és az ügyfelek újra csatlakoznak az adatbázis-kiszolgálóhoz, és folytatják a műveleteket.

A feladatátvétel teljes időtartama általában 60 és 120 másodperc között van. Az elsődleges adatbázis-kiszolgáló feladatátvételkor végzett tevékenységétől (például nagy tranzakcióktól és helyreállítási időtől) függően azonban a feladatátvétel hosszabb időt vehet igénybe.

Feljegyzés

Az Azure Resource Health-esemény nem tervezett feladatátvétel során jön létre. Az esemény azt a feladatátvételi időt jelöli, amikor a kiszolgáló nem érhető el. Az aktivált események akkor láthatók, ha a bal oldali panelen a Resource Health lehetőséget választja. Az automatikus feladatátvétel "Nem érhető el" állapotot jelenít meg, és a címkéje "Nem tervezett".

Például nem érhető el: A feladatátvételi művelet automatikusan aktiválódott (nem tervezett). Ha az erőforrás hosszú ideig ebben az állapotban marad, nyisson meg egy támogatási jegyet , és segítünk Önnek.

Az automatikus feladatátvétel-észlelés működése HA-kompatibilis kiszolgálókon

Az elsődleges kiszolgáló és a másodlagos kiszolgáló két hálózati végpontot tartalmaz:

  • Ügyfélvégpont: Az ügyfelek ezzel a végponttal csatlakoznak és futtatnak lekérdezéseket a példányon.
  • Felügyeleti végpont: Belsőleg használják a felügyeleti összetevőkkel folytatott szolgáltatáskommunikációhoz és a háttértárhoz való csatlakozáshoz.

Az állapotfigyelő összetevő folyamatosan elvégzi a következő ellenőrzéseket:

  • A figyelő pingeli a csomópont felügyeleti hálózati végpontját. Ha ez az ellenőrzés egymás után kétszer meghiúsul, automatikus feladatátvételi műveletet indít el. Ez az állapot-ellenőrzés olyan forgatókönyveket kezel, mint a csomópontok elérhetetlensége vagy az operációs rendszer hibáiból eredő nem válaszolás, a felügyeleti összetevők és csomópontok közötti hálózatkezelési problémák és hasonló problémák.
  • A figyelő egy egyszerű lekérdezést futtat a példányon. Ha a lekérdezések nem futnak, automatikus feladatátvételi eseményindítók indulnak el. Ez az állapot-ellenőrzés olyan forgatókönyveket kezel, mint a MySQL-démon összeomlása, leállása vagy lefagyása, valamint a háttérbeli tárolási problémák és hasonló problémák.

Feljegyzés

Az állapotellenőrzés nem figyeli az alkalmazás és az ügyfél hálózati végpontja közötti hálózati problémákat (privát/nyilvános hozzáférés). Ezek a problémák a hálózati útvonalon, a végponton vagy az ügyféloldali DNS-problémákban fordulhatnak elő. Ha privát hozzáférést használ, győződjön meg arról, hogy a virtuális hálózat NSG-szabályai nem blokkolják a 3306-os porton lévő ügyfélhálózati végpont felé irányuló kommunikációt. Nyilvános hozzáférés esetén győződjön meg arról, hogy a tűzfalszabályok be vannak állítva, és a hálózati forgalom engedélyezve van a 3306-os porton (ha a hálózati útvonalon más tűzfalak is találhatók). Az ügyfélalkalmazás oldaláról is gondoskodnia kell a DNS-feloldásról.

Magas rendelkezésre állás figyelése

A kiszolgáló magas rendelkezésre állású konfigurációs állapotának ellenőrzéséhez használja a magas rendelkezésre állási állapotot a kiszolgáló magas rendelkezésre állású paneljén a portálon.

Állapot Leírás
NotEnabled a magas rendelkezésre állás nincs engedélyezve.
Adatreplikálás A készenléti kiszolgáló szinkronizálja az elsődleges kiszolgálót a magas rendelkezésre állású kiszolgáló kiépítésekor vagy a magas rendelkezésre állás engedélyezésekor.
Feladatátvétel Az adatbázis-kiszolgáló az elsődlegesről a készenléti állapotba kerül.
Egészséges A magas rendelkezésre állás lehetőség engedélyezve van.
AStandby eltávolítása A törlési folyamat folyamatban van, amikor letiltja a magas rendelkezésre állású beállítást.

A magas rendelkezésre állású kiszolgáló állapotának figyeléséhez használja az alábbi metrikákat.

Metrika megjelenítendő neve Metrika Unit (Egység) Leírás
HA IO állapota ha_io_running Állapot A HA IO állapota a HA-replikáció állapotát mutatja. A metrika értéke 1, ha az I/O-szál fut, és 0, ha nem.
HA SQL-állapot ha_sql_running Állapot A HA SQL állapota a HA-replikáció állapotát mutatja. A metrika értéke 1, ha az SQL-szál fut, és 0, ha nem.
HA replikációs késés replikációs késleltetés Másodperc A replikáció késése az a másodpercek száma, amikor a készenléti állapot hátra van az elsődleges kiszolgálón fogadott tranzakciók ismétlése során.

Korlátozások

A magas rendelkezésre állás használatakor tartsa szem előtt az alábbi szempontokat:

  • A zónaredundáns magas rendelkezésre állást csak a kiszolgáló létrehozásakor konfigurálhatja.

  • A kipukkasztható számítási szint nem támogatja a magas rendelkezésre állást.

  • Az elsődleges adatbázis-kiszolgáló újraindítása statikus paramétermódosítások alkalmazásához szintén újraindítja a készenléti replikát.

  • A megoldás bekapcsolja a GTID módot, mert GTID-t használ. Ellenőrizze, hogy a számítási feladat rendelkezik-e korlátozásokkal vagy korlátozásokkal a GTID-kkel való replikációra.

Feljegyzés

A tárolási automatikus kapacitás alapértelmezés szerint engedélyezve van egy magas rendelkezésre állású konfigurált kiszolgálón, és nem tiltható le.

Állapotellenőrzések

Ha magas rendelkezésre állást (HA) konfigurál az Azure Database for MySQL-hez, az állapot-ellenőrzések kulcsfontosságú szerepet játszanak az adatbázis megbízhatóságának és teljesítményének fenntartásában. Ezek az ellenőrzések folyamatosan figyelik az elsődleges és a készenléti replikák állapotát és állapotát, biztosítva, hogy a problémákat azonnal észleljék. A különböző metrikák, például a kiszolgáló válaszkészségének, a replikáció késésének és az erőforrás-kihasználtságnak a nyomon követésével az állapot-ellenőrzések segítenek a feladatátvételi folyamatok zökkenőmentes végrehajtásában, az állásidő minimalizálásában és az adatvesztés megelőzésében. A megfelelően konfigurált állapotellenőrzések elengedhetetlenek a kívánt rendelkezésre állási és rugalmassági szint eléréséhez az adatbázis-beállításban.

Állapot monitorozása

A HA-beállítás állapotát az Azure Portalon követheti nyomon. A megfigyelendő főbb metrikák a következők:

  • Kiszolgáló válaszképessége: Azt jelzi, hogy az elsődleges kiszolgáló elérhető-e.
  • Replikáció késése: Méri az elsődleges és a készenléti replikák közötti késést, biztosítva az adatkonzisztenciát.
  • Erőforrás kihasználtsága: Figyeli a processzor- és memóriahasználatot, valamint a tárolóhasználatot a szűk keresztmetszetek elkerülése érdekében.

Kapcsolódó tartalom

  • Last updated on