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

A magas rendelkezésre állás fogalmai rugalmas Azure Database for PostgreSQL-kiszolgáló esetén

  • Cikk

A következőkre vonatkozik: Azure Database for MySQL – rugalmas kiszolgáló

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. A magas rendelkezésreállású megoldás úgy van kialakítva, hogy a véglegesített adatok soha ne vesszenek el hibák miatt, és az adatbázis ne váljon rendszerkritikus meghibásodási ponttá a szoftverarchitektúrában. Ha magas rendelkezésre állás van konfigurálva, a rugalmas kiszolgáló automatikusan kiépít és kezel egy készenléti replikát. A kiosztott számítási és tárolási díjak az elsődleges és a másodlagos replika számára is ki vannak számlázva. Két magas rendelkezésre állású architektúramodell létezik:

  • Zónaredundáns HA. Ez a beállítás előnyben részesíti az infrastruktúra teljes elkülönítését és redundanciát több rendelkezésre állási zónában. Ez biztosítja a legmagasabb szintű rendelkezésre állást, de megköveteli, hogy az alkalmazás redundanciát konfiguráljon a zónák között. A zónaredundáns HA akkor ajánlott, ha a rendelkezésre állási zónában lévő infrastruktúra meghibásodása esetén a legmagasabb rendelkezésre állási szintet szeretné elérni, és ha a rendelkezésre állási zónán belüli késés elfogadható. 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.

  • Azonos zónás HA. Ez a beállítás az alacsonyabb hálózati késéssel rendelkező infrastruktúra-redundancia esetében ajánlott, mert az elsődleges és a készenléti kiszolgálók ugyanabban a rendelkezésre állási zónában lesznek. 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. A legalacsonyabb hálózati késéssel rendelkező egyetlen rendelkezésre állási zónán belül a legmagasabb rendelkezésre állási szintet szeretné elérni. Az azonos zónás HA minden Olyan Azure-régióban elérhető, ahol rugalmas Azure Database for MySQL-kiszolgálót használhat.

Zónaredundáns HA-architektúra

Ha zónaredundáns HA-val rendelkező kiszolgálót helyez üzembe, két kiszolgáló jön létre:

  • Egy elsődleges kiszolgáló egy rendelkezésre állási zónában.
  • Olyan készenléti replikakiszolgáló, amely ugyanazzal a konfigurációval rendelkezik, mint az elsődleges kiszolgáló (számítási szint, számítási méret, tárhelyméret és hálózati konfiguráció) ugyanazon Azure-régió egy másik rendelkezésre állási zónájában.

Kiválaszthatja az elsődleges és a készenléti replika rendelkezésre állási zónát. 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 lehetővé teszi a vészhelyreállítási helyzetek és a "zónaleállítás" forgatókönyvek jobb előkészítését is.

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 játssza vissza 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álva van.
  • 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ődlegesen 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 frissül, így az ügyfélkapcsolatok az ügyfél újracsatlakozásakor az új elsődlegesre lesznek irányítva. 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 az alkalmazások elsődleges kiszolgálóhoz való csatlakoztatására szolgál. 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ó 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.

Azonos zónájú HA-architektúra

Ha egy azonos zónájú HA-val rendelkező kiszolgálót helyez üzembe, a rendszer 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álló virtuális géppel (számítással) kínál 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, amely az azonos zónájú magas rendelkezésre állás architektúrájának ábrázolása.

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 játssza vissza 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álva van.
  • 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ődlegesen 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 az alkalmazások elsődleges kiszolgálóhoz való csatlakoztatására szolgál. 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. Az azonos zónák beállítása nem biztosít magas rendelkezésre állást, ha a függő infrastruktúrák le vannak állítva az adott rendelkezésre állási zónához. Állásidő lesz, 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 azonos zónás 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. Ezért azt javasoljuk, hogy a feladatátvételi idő csökkentése érdekében minden táblában használjon elsődleges kulcsokat. A feladatátvételi idő általában 60 és 120 másodperc között van.
  • 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. Feladatátvétel esetén az elsődleges és a készenléti kiszolgáló szerepköreinek 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 ip-címet használ a kapcsolati sztring.

Feladatátvételi folyamat

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. A rendszer újraindítja az eredeti elsődleges kiszolgálót, és átvált a készenléti replikára. Az ügyfélkapcsolatok megszakadnak, és újra csatlakoztatni kell őket 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. A folyamat általában 60–120 másodpercet vesz igénybe.

Feljegyzés

Az Azure Resource Health-esemény tervezett feladatátvétel esetén jön létre, amely azt a feladatátvételi időt jelöli, amely alatt a kiszolgáló nem volt elérhető. Az aktivált események a bal oldali panel "Resource Health" elemére kattintva láthatók. A felhasználó által kezdeményezett/ manuális feladatátvételt "Nem érhető el" állapot 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 nem tervezett szolgáltatás állásidőt okozhatják szoftverhibák vagy infrastruktúrahibák, például számítási, hálózati vagy tárolási hibák, illetve az adatbázis rendelkezésre állását befolyásoló áramkimaradások. Ha az adatbázis elérhetetlenné válik, a készenléti replikára történő replikálási kapcsolat megszakad, és a készenléti replika elsődleges adatbázisként aktiválódik. A DNS frissül, és az ügyfelek újra csatlakoznak az adatbázis-kiszolgálóhoz, és folytatják a műveleteket.

A teljes feladatátvételi idő várhatóan 60–120 másodperc lesz. Az elsődleges adatbázis-kiszolgáló feladatátvételkor végzett tevékenységétől függően (például nagy tranzakciók és helyreállítási idő) a feladatátvétel hosszabb időt vehet igénybe.

Feljegyzés

Az Azure Resource Health-esemény nem tervezett feladatátvétel esetén jön létre, amely azt a feladatátvételi időt jelöli, amely alatt a kiszolgáló nem volt elérhető. Az aktivált események a bal oldali panel "Resource Health" elemére kattintva láthatók. Az automatikus feladatátvételt "Nem érhető el" állapot jelöli, a címkéje pedig "Nem tervezett". Példa : "Nem érhető el: A feladatátvételi művelet automatikusan aktiválódott (nem tervezett)". Ha az erőforrás hosszabb 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 ügyfél ezzel a végponttal csatlakozik a példányhoz, és lekérdezést futtat.
  • 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 az alábbi ellenőrzéseket

  • A figyelő pingel a csomópontok felügyeleti hálózati végpontja felé. Ha ez az ellenőrzés folyamatosan kétszer meghiúsul, automatikus feladatátvételi műveletet indít el. Az olyan forgatókönyv, mint a csomópont, nem érhető el/nem válaszol az operációs rendszer hibája miatt, a felügyeleti összetevők és csomópontok közötti hálózatkezelési problémát ez az állapot-ellenőrzés fogja megoldani.
  • A figyelő egy egyszerű lekérdezést is futtat a példányon. Ha a lekérdezések nem futnak, az automatikus feladatátvétel aktiválódik. Az állapot-ellenőrzés az olyan forgatókönyveket fogja kezelni, mint például a MySQL-démon összeomlott/ leállt/lefagyott, háttérbeli tárhellyel kapcsolatos probléma stb.

Feljegyzés

Ha az alkalmazás és az ügyfél hálózati végpontja (privát/nyilvános hozzáférés) között hálózati probléma merül fel, akár a hálózati útvonalon, akár a végponton, akár a DNS-problémáknál az ügyféloldalon, az állapotellenőrzés nem figyeli ezt a forgatókönyvet. 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. A nyilvános hozzáféréshez 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 útvonal más tűzfalakat is használ). Az ügyfélalkalmazás oldaláról érkező DNS-feloldást is el kell intézni.

Magas rendelkezésre állás monitorozása

A kiszolgáló Magas rendelkezésre állás paneljén található magas rendelkezésre állási állapot a kiszolgáló HA-konfigurációs állapotának meghatározására használható.

Állapot Leírás
NotEnabled A HA nincs engedélyezve.
ReplicatingData A készenléti kiszolgáló szinkronizálása folyamatban van az elsődleges kiszolgálóval a HA-kiszolgáló kiépítésekor vagy ha a HA-beállítás engedélyezve van.
Feladatátvétel Az adatbázis-kiszolgáló feladatátvétele folyamatban van az elsődlegesről a készenléti állapotba.
Egészséges A HA beállítás engedélyezve van.
AStandby eltávolítása Ha a HA beállítás le van tiltva, és a törlési folyamat folyamatban van.

Az alábbi metrikákat is használhatja a HA-kiszolgáló állapotának figyeléséhez.

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 jelzi. 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 jelzi. A metrika értéke 1, ha az SQL-szál fut, és 0, ha nem.
HA replikációs késés replication_lag 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 az alábbi szempontokat érdemes szem előtt tartani:

  • A zónaredundáns magas rendelkezésre állás csak a rugalmas kiszolgáló létrehozásakor állítható be.
  • A magas rendelkezésre állás nem támogatott a kipukkasztható számítási szinten.
  • Az elsődleges adatbázis újraindítása a statikus paraméterváltozások szinkronizálása érdekében a készenléti replikát is újraindítja.
  • A GTID mód be lesz kapcsolva, mivel a HA-megoldás a GTID-t használja. 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

Ha a kiszolgáló létrehozása után engedélyezi az azonos zónás HA-t, a HA engedélyezése előtt meg kell győződnie arról, hogy a kiszolgáló paraméterei enforce_gtid_consistency" és a "gtid_mode" be van kapcsolva.

Feljegyzés

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

Gyakori kérdések (GYIK)

  • Mik az azonos zónás és a zónaredundáns HA-kompatibilis rugalmas kiszolgáló SLA-i?

    A rugalmas Azure Database for MySQL-kiszolgáló SLA-információi az Azure Database for MySQL-hez készült SLA-ban találhatók.

  • Hogyan kell fizetni a magas rendelkezésre állású (HA) kiszolgálókért? A magas rendelkezésre állású kiszolgálók egy elsődleges és egy másodlagos replikával rendelkeznek. A másodlagos replika lehet ugyanabban a zónában, de lehet zónaredundáns is. A kiosztott számítási és tárolási díjak az elsődleges és a másodlagos replika számára is ki vannak számlázva. Ha például az elsődleges replika 4 virtuális magnyi számítási erőforrással és 512 GB-nyi kiépített tárterülettel rendelkezik, akkor a másodlagos replika is 4 virtuális maggal és 512 GB-nyi kiépített tárterülettel rendelkezik. A zónaredundáns, magas rendelkezésre állású kiszolgálóhoz 8 virtuális mag és 1024 GB-nyi tárterület lesz felszámítva. A biztonsági mentési tár méretétől függően a biztonsági mentési tárterületet is felszámíthatjuk.

  • Használhatom a készenléti replikát olvasási vagy írási műveletekhez?
    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.

  • Adatvesztés lesz a feladatátvétel során?
    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 elsődleges kiszolgáló szerepét veszi át.

  • Szükség van bármilyen műveletre a feladatátvétel után?
    A feladatátvételek teljesen transzparensek az ügyfélalkalmazásból. Nem kell semmilyen műveletet elvégeznie. Az alkalmazásoknak csak az újrapróbálkozási logikát kell használniuk a kapcsolataikhoz.

  • Mi történik, ha nem választok ki egy adott zónát a készenléti replikámhoz? Később módosíthatom a zónát?
    Ha nem jelöl ki zónát, a rendszer véletlenszerűen kiválaszt egyet. Ez lesz az elsődleges kiszolgálóhoz használt. Ha később módosítani szeretné a zónát, állítsa a Magas rendelkezésre állás beállítást letiltottra a Magas rendelkezésre állás panelen, majd állítsa vissza zónaredundánsra, és válasszon egy zónát.

  • Szinkron a replikáció az elsődleges és a készenléti replika között?
    Az elsődleges és a készenléti állapot közötti replikáció hasonló a MySQL félszinkron módjához. A tranzakció véglegesítésekor nem feltétlenül véglegesíti a készenléti állapotot. Ha azonban az elsődleges nem érhető el, a készenléti állapot replikálja az összes adatmódosítást az elsődlegesről, hogy biztosan ne legyen adatvesztés.

  • Van feladatátvétel a készenléti replikára az összes nem tervezett hiba esetén?
    Adatbázis-összeomlás vagy csomóponthiba esetén a rugalmas kiszolgáló virtuális gépe ugyanazon a csomóponton újraindul. Ugyanakkor egy automatikus feladatátvétel is aktiválódik. Ha a rugalmas kiszolgáló virtuális gép újraindítása a feladatátvétel befejezése előtt sikeres, a feladatátvételi művelet megszakad. Annak meghatározása, hogy melyik kiszolgáló legyen elsődleges replikaként használva, az első befejező folyamattól függ.

  • Hatással van a teljesítményre a HA használata?
    Zónaredundáns HA esetén, bár a rendelkezésre állási zónákban az olvasási számítási feladatokra nincs jelentős hatással, akár 40 százalékkal is csökkenhet az írási-lekérdezési késés. Az írási késés növekedése a rendelkezésre állási zónák közötti szinkron replikációnak köszönhető. Az írási késés hatása általában kétszer a zónaredundáns HA-ban az azonos zóna HA-hoz képest. Az azonos zónás HA esetében, mivel az elsődleges és a készenléti replika ugyanabban a zónában van, a replikáció késése és következésképpen a szinkron írási késés alacsonyabb. Összefoglalva, ha az írási késés kritikusabb az Ön számára a rendelkezésre álláshoz képest, érdemes lehet ugyanazt a zóna HA-t választania, de ha az adatok rendelkezésre állása és rugalmassága kritikusabb az Ön számára az írási késés csökkenése rovására, akkor zónaredundáns HA-t kell választania. A ha-beállítás késésének pontos hatásának méréséhez javasoljuk, hogy végezzen teljesítménytesztelést a számítási feladathoz, hogy megalapozott döntést hozzon.

  • Hogyan történik a HA-kiszolgáló karbantartása?
    A tervezett események, például a számítási és alverziófrissítések skálázása először az eredeti készenléti példányon történik, majd egy tervezett feladatátvételi művelet aktiválása, majd az eredeti elsődleges példányon való működés. A rugalmas kiszolgálókhoz hasonlóan beállíthatja a HA-kiszolgálók ütemezett karbantartási időszakát . Az állásidő mértéke megegyezik a rugalmas Azure Database for MySQL-kiszolgálópéldány állásidejével, ha a HA le van tiltva.

  • Végezhetek időponthoz kötött visszaállítást (PITR) a HA-kiszolgálómról?
    HA-kompatibilis rugalmas Azure Database for MySQL-kiszolgálópéldányhoz készíthet PITR-t egy rugalmas Azure Database for MySQL-kiszolgálópéldányhoz, amely letiltotta a HA-t. Ha a forráskiszolgáló zónaredundáns HA-val lett létrehozva, később engedélyezheti a zónaredundáns HA-t vagy az azonos zónájú HA-t a visszaállított kiszolgálón. Ha a forráskiszolgáló azonos zónájú HA-val lett létrehozva, csak az azonos zónájú HA engedélyezhető a visszaállított kiszolgálón.

  • Engedélyezhetem a HA-t egy kiszolgálón a kiszolgáló létrehozása után?
    A zónaredundáns HA-t engedélyezni kell a kiszolgáló létrehozásakor. A kiszolgáló létrehozása után engedélyezheti az azonos zónás HA-t. A zóna HA engedélyezése előtt győződjön meg arról, hogy a kiszolgálóparaméterek enforce_gtid_consistency" és "gtid_mode" be van kapcsolva

  • Letilthatom a HA-t egy kiszolgáló esetében a létrehozás után?
    A létrehozás után letilthatja a HA-t egy kiszolgálón. A számlázás azonnal leáll.

  • Hogyan mérsékelhetem az állásidőt?
    Akkor is csökkentenie kell az alkalmazás állásidejét, ha nem használja a HA-t. A szolgáltatás állásideje( például ütemezett javítások, alverziófrissítések vagy ügyfél által kezdeményezett műveletek, például a számítás skálázása) elvégezhető az ütemezett karbantartási időszakokban. Az Azure által kezdeményezett karbantartási feladatok alkalmazásra gyakorolt hatásának csökkentése érdekében ütemezheti őket a hét egy napján és időpontban, amely minimálisra csökkenti az alkalmazásra gyakorolt hatást.

  • Használhatok olvasási replikát egy HA-kompatibilis kiszolgálóhoz?
    Igen, az olvasási replikák támogatottak a HA-kiszolgálók esetében.

  • Használhatom a data-in replikációt HA-kiszolgálókhoz?
    A magas rendelkezésre állású (HA) kiszolgáló adatreplikációs támogatása csak GTID-alapú replikációval érhető el. A GTID-t használó replikáció tárolt eljárása az összes HA-kompatibilis kiszolgálón elérhető a név mysql.az_replication_with_gtidalapján.

  • Az állásidő csökkentése érdekében feladatátvételt végezhetek a készenléti kiszolgálóra a kiszolgáló újraindítása vagy fel- vagy leskálázás közben?
    A rugalmas Azure Database for MySQL-kiszolgáló jelenleg a tervezett feladatátvételt választotta a HA-műveletek( például a vertikális fel- és leskálázás, valamint a tervezett karbantartás) engedélyezéséhez az állásidő csökkentése érdekében. Az ilyen műveletek indításakor először az eredeti készenléti példányon fog működni, majd elindít egy tervezett feladatátvételi műveletet, majd az eredeti elsődleges példányon fog működni.

  • Módosíthatjuk a kiszolgáló
    rendelkezésre állási módját (zónaredundáns HA/azonos zóna) Ha a kiszolgálót zónaredundáns HA móddal hozza létre, akkor a zónaredundáns HA-ról ugyanarra a zónára válthat, és fordítva. A rendelkezésre állási mód módosításához állítsa a Magas rendelkezésre állás beállítást letiltottra a Magas rendelkezésre állás panelen, majd állítsa vissza zónaredundánsra vagy azonos zónára, és válassza a Magas rendelkezésre állási módot.

Következő lépések

  • További információ az üzletmenet folytonosságáról.
  • Tudnivalók a zónaredundáns magas rendelkezésre állásról.
  • További információ a biztonsági mentésről és a helyreállításról.