Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A magas rendelkezésre állás az Azure Database for MySQL egyik kulcsfontosságú funkciója, amelynek célja az állásidő minimalizálása, és annak biztosítása, hogy az alkalmazások még a tervezett karbantartás vagy váratlan leállások során is elérhetők maradjanak. Ez a cikk a magas rendelkezésre állási (HA) lehetőségekkel, a számlázással, a feladatátvételi folyamatokkal, a teljesítményre gyakorolt hatásokkal és az ajánlott eljárásokkal kapcsolatos gyakori kérdéseket ismerteti, amelyek segítenek megalapozott döntéseket hozni a MySQL-számítási feladatokhoz az Azure-ban.
Mik a helyi redundáns és a zónaredundáns HA-kompatibilis rugalmas kiszolgálók 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 HA-val engedélyezett kiszolgálók elsődleges és másodlagos replikával rendelkeznek. A másodlagos replika lehet ugyanabban a zónában vagy zónaredundáns. 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 egy elsődleges 4 virtuális magnyi számítási és 512 GB kiosztott tárhellyel rendelkezik, a másodlagos replika 4 virtuális maggal és 512 GB kiosztott tárhellyel rendelkezik.
A zónaredundáns HA-kiszolgáló számlázása 8 virtuális magért és 1024 GB tárterületért történik. 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.
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 választ ki zónát, a kiválasztott zóna véletlenszerűen lesz kiválasztva. Ez 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 sikeres a feladatátvétel befejezése előtt, 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%-kal is csökkenhet az írási lekérdezések késése. 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 kétszer a zónaredundáns HA-ban van ugyanahhoz a ha zónához képest. Helyi redundáns HA esetén, mivel az elsődleges és a készenléti replika ugyanabban a zónában van, a replikáció késése, és így 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 helyileg redundáns HA-t választania, de ha az adatok rendelkezésre állása és rugalmassága kritikusabb 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 új 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 a helyi redundáns HA-t a visszaállított kiszolgálón. Ha a forráskiszolgáló helyi redundáns HA-val lett létrehozva, csak a helyi redundáns HA-t engedélyezheti 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ása során. A kiszolgáló létrehozása után engedélyezheti a helyi redundáns HA-t, de a folytatás előtt győződjön meg arról, hogy a kiszolgálóparaméterek enforce_gtid_consistency és gtid_mode vannak beállítva ON .
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 használja a HA-műveletek optimalizálására, beleértve a vertikális fel- és leskálázást és a tervezett karbantartást 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/helyi redundáns) **
Ha zónaredundáns HA móddal hozza létre a kiszolgálót, akkor a zónaredundáns HA-ról helyire 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áns vagy helyi redundáns értékre , és válassza a Magas rendelkezésre állási módot.