Olvasási replikák 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 olvasási replikával adatokat replikálhat egy Azure Database for MySQL-kiszolgálóról egy csak olvasható kiszolgálóra. A forráskiszolgálóról legfeljebb öt replikára másolhatja az adatokat. A replikák aszinkron módon frissülnek a MySQL-motor natív bináris naplójának (binlog) fájlpozíció-alapú replikációs technológiájával. A binlog replikációval kapcsolatos további információkért tekintse meg a MySQL-binlog replikációjának áttekintését.
A replikák olyan új kiszolgálók, amelyeket a szokásos Azure Database for MySQL-kiszolgálókhoz hasonlóan kezel. Minden olvasási replika esetében a kiosztott számításért a virtuális magokért és a tárterületért kell fizetnie GB/hóban.
A MySQL replikációs funkcióival és problémáival kapcsolatos további információkért tekintse meg a MySQL replikációs dokumentációját.
Feljegyzés
Ebben a cikkben szerepel a slave (alárendelt) kifejezés, amelyet a Microsoft már nem használ. Ha a kifejezés el lesz távolítva a szoftverből, eltávolítjuk ebből a cikkből.
Mikor érdemes olvasási replikát használni?
Az olvasási replika funkció javítja az olvasásigényes számítási feladatok teljesítményét és skálázását. Az olvasási számítási feladatok elkülöníthetők a replikákhoz, míg az írási számítási feladatok a forráshoz irányíthatók.
Gyakori forgatókönyv, hogy a BI- és elemzési számítási feladatok az olvasási replikát használják adatforrásként a jelentéskészítéshez.
Mivel a replikák írásvédettek, nem csökkentik közvetlenül a forrás írási kapacitásának terheit. Ez a funkció nem a nagy írási igényű számítási feladatokhoz ideális.
Az olvasási replika funkció MySQL aszinkron replikációt használ. A funkció nem szinkron replikációs forgatókönyvekhez készült. Mérhető késés lesz a forrás és a replika között. A replika adatai végül konzisztenssé válnak a forrás adataival. Ezt a funkciót olyan számítási feladatok esetében érdemes használni, amelyeknél nem jelent problémát a késés.
Régiók közötti replikáció
A forráskiszolgálótól eltérő régióban is létrehozhat olvasási replikát. A régiók közötti replikáció olyan forgatókönyvek esetén lehet hasznos, mint a vészhelyreállítás megtervezése vagy az adatok közelebb hozása a felhasználókhoz.
Bármely Azure Database for MySQL-régióban rendelkezhet forráskiszolgálóval. A forráskiszolgálók rendelkezhetnek replikával a párosított régióban vagy az univerzális replikarégiókban. Az alábbi képen látható, hogy a forrásrégiótól függően mely replikarégiók érhetők el.
Univerzális replikarégiók
Az olvasási replikát a következő régiók bármelyikében létrehozhatja, függetlenül attól, hogy hol található a forráskiszolgáló. A támogatott univerzális replikarégiók a következők:
| Régió | Replika rendelkezésre állása |
|---|---|
| Kelet-Ausztrália | ✔️ |
| Délkelet-Ausztrália | ✔️ |
| Dél-Brazília | ✔️ |
| Közép-Kanada | ✔️ |
| Kelet-Kanada | ✔️ |
| Az USA középső régiója | ✔️ |
| USA keleti régiója | ✔️ |
| USA 2. keleti régiója | ✔️ |
| Kelet-Ázsia | ✔️ |
| Kelet-Japán | ✔️ |
| Nyugat-Japán | ✔️ |
| Dél-Korea középső régiója | ✔️ |
| Dél-Korea déli régiója | ✔️ |
| Észak-Európa | ✔️ |
| USA északi középső régiója | ✔️ |
| USA déli középső régiója | ✔️ |
| Délkelet-Ázsia | ✔️ |
| Észak-Svájc | ✔️ |
| Az Egyesült Királyság déli régiója | ✔️ |
| Az Egyesült Királyság nyugati régiója | ✔️ |
| USA nyugati középső régiója | ✔️ |
| USA nyugati régiója | ✔️ |
| USA 2. nyugati régiója | ✔️ |
| Nyugat-Európa | ✔️ |
| Közép-India* | ✔️ |
| Közép-Franciaország* | ✔️ |
| Egyesült Arab Emírségek északi régiója* | ✔️ |
| Észak-Afrika déli régiója* | ✔️ |
Feljegyzés
*Azok a régiók, ahol az Azure Database for MySQL általános célú tároló v2-vel rendelkezik a nyilvános előzetes verzióban
*Ezekben az Azure-régiókban lehetősége lesz kiszolgálót létrehozni az Általános célú tároló 1-ben és 2-ben is. A nyilvános előzetes verzióban az Általános célú tárolás v2-vel létrehozott kiszolgálók esetében csak az Általános célú tárolás v2-t támogató Azure-régiókban hozhat létre replikakiszolgálót.
Párosított régiók
Az univerzális replikarégiók mellett olvasási replikát is létrehozhat a forráskiszolgáló Azure-párosított régiójában. Ha nem ismeri a régió párját, az Azure Párosított régiók című cikkből tudhat meg többet.
Ha régiók közötti replikákat használ vészhelyreállítás tervezéséhez, javasoljuk, hogy a replikát a párosított régióban hozza létre a többi régió helyett. A párosított régiók elkerülik az egyidejű frissítéseket, és rangsorolják a fizikai elkülönítést és az adattárolást.
Vannak azonban korlátozások, amelyeket figyelembe kell venni:
Regionális rendelkezésre állás: Az Azure Database for MySQL elérhető a Franciaország középső régiójában, az Egyesült Arab Emírségek északi régiójában és a közép-németországi régióban. A párosított régiók azonban nem érhetők el.
Egyirányú párok: Egyes Azure-régiók csak egy irányban vannak párosítva. Ezek közé a régiók közé tartozik Nyugat-India, Dél-Brazília és az USA Gov Virginia. Ez azt jelenti, hogy egy nyugat-indiai forráskiszolgáló létrehozhat egy replikát Dél-Indiában. A dél-indiai forráskiszolgálók azonban nem tudnak replikát létrehozni Nyugat-Indiában. Ennek az az oka, hogy Nyugat-India másodlagos régiója Dél-India, de Dél-India másodlagos régiója nem Nyugat-India.
Replika létrehozása
Fontos
- Az olvasási replika funkció csak az Azure Database for MySQL-kiszolgálókhoz érhető el az Általános célú vagy memóriaoptimalizált tarifacsomagokban. Győződjön meg arról, hogy a forráskiszolgáló ezen tarifacsomagok egyikében található.
- Ha a forráskiszolgáló nem rendelkezik meglévő replikakiszolgálókkal, előfordulhat, hogy a forráskiszolgálónak újra kell indítania a replikáció előkészítését a használt tárolótól függően (v1/v2). Fontolja meg a kiszolgáló újraindítását, és hajtsa végre ezt a műveletet csúcsidőn kívül. További részletekért tekintse meg a forráskiszolgáló újraindítását ismertető cikket.
A replika létrehozása munkafolyamat indításakor létrejön egy üres Azure Database for MySQL-kiszolgáló. Az új kiszolgáló tele van a forráskiszolgálón található adatokkal. A létrehozás időpontja a forrás adatainak mennyiségétől és az utolsó heti teljes biztonsági mentés óta eltelt időtől függ. Ez néhány percet vagy akár több órát is jelenthet. A replikakiszolgáló mindig ugyanabban az erőforráscsoportban és előfizetésben jön létre, mint a forráskiszolgáló. Ha replikakiszolgálót szeretne létrehozni egy másik erőforráscsoportba vagy másik előfizetésbe, a létrehozás után áthelyezheti a replikakiszolgálót .
A tárterület automatikus növeléséhez minden replika engedélyezve van. Az automatikus növekedés funkció lehetővé teszi, hogy a replika lépést tartson a replikált adatokkal, és megakadályozza a tárterületen kívüli hibák által okozott replikáció megszakadását.
További információ az olvasási replikák Azure Portalon történő létrehozásáról.
Csatlakozás a replikához
A létrehozáskor a replika örökli a forráskiszolgáló tűzfalszabályait. Ezután ezek a szabályok függetlenek a forráskiszolgálótól.
A replika örökli a rendszergazdai fiókot a forráskiszolgálótól. A forráskiszolgálón lévő összes felhasználói fiók replikálva lesz az olvasási replikákra. Csak a forráskiszolgálón elérhető felhasználói fiókok használatával csatlakozhat olvasási replikához.
A replikához a gazdagépnév és egy érvényes felhasználói fiók használatával csatlakozhat, ahogyan egy normál Azure Database for MySQL-kiszolgálón tenné. A myreplica nevű kiszolgálóhoz a myadmin rendszergazdai felhasználónévvel csatlakozhat a replikához a mysql parancssori felületével:
mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p
Amikor a rendszer kéri, adja meg a felhasználói fiók jelszavát.
Replikálás figyelése
Az Azure Database for MySQL másodpercek alatt biztosítja a replikáció késését az Azure Monitorban. Ez a metrika csak replikákhoz érhető el. Ezt a metrikát a seconds_behind_master MySQL parancsában elérhető metrika alapján számítjuk SHOW SLAVE STATUS ki. Állítson be egy riasztást, amely tájékoztatja, ha a replikáció késése elér egy olyan értéket, amely nem elfogadható a számítási feladat számára.
Ha megnövekedett replikációs késést tapasztal, tekintse meg a replikáció késésének hibaelhárítását a lehetséges okok elhárításához és megértéséhez.
Replikáció leállítása
Leállíthatja a replikációt egy forrás és egy replika között. Miután a replikáció leállt egy forráskiszolgáló és egy olvasási replika között, a replika önálló kiszolgálóvá válik. Az önálló kiszolgálón lévő adatok azok az adatok, amelyek a replikáció leállítása parancs elindításakor voltak elérhetők a replikán. Az önálló kiszolgáló nem tud felzárkózni a forráskiszolgálóhoz.
Ha úgy dönt, hogy leállítja a replikára történő replikációt, az elveszíti a korábbi forrásra és más replikákra mutató összes hivatkozást. A forrás és a replika között nincs automatikus feladatátvétel.
Fontos
Az önálló kiszolgáló nem készíthető újra replikává. Mielőtt leállítja a replikációt egy olvasási replikán, győződjön meg arról, hogy a replika rendelkezik a szükséges adatokkal.
Megtudhatja, hogyan állíthatja le a replikára történő replikációt.
Feladatátvétel
A forrás- és replikakiszolgálók között nincs automatikus feladatátvétel.
Mivel a replikáció aszinkron, késés van a forrás és a replika között. A késés mértékét számos tényező befolyásolhatja, például a forráskiszolgálón futó számítási feladatok nagysága és az adatközpontok közötti késés. A legtöbb esetben a replika késése pár másodperc vagy pár perc. A tényleges replikációs késést az egyes replikákhoz elérhető metrika késésével követheti nyomon. Ez a metrika az utolsó újrajátszott tranzakció óta eltelt időt mutatja. Javasoljuk, hogy a replika késésének megfigyelésével azonosítsa az átlagos késést. Beállíthat egy riasztást a replika késése esetén, így ha az túllépi a várt tartományt, műveletet végezhet.
Tipp.
Ha feladatátvételt tesz a replikára, a replika forrásból való leválasztásának késleltetése jelzi, hogy mennyi adat veszett el.
Miután eldöntötte, hogy feladatátvételt szeretne végrehajtani egy replikára:
Replikáció leállítása a replikára
Ez a lépés szükséges ahhoz, hogy a replikakiszolgáló képes legyen írásokat fogadni. Ennek a folyamatnak a részeként a replikakiszolgáló el lesz távolítva a forrásból. A replikáció leállítása után a háttérfolyamat általában körülbelül 2 percet vesz igénybe. A művelet következményeinek megismeréséhez tekintse meg a cikk replikációs leállítása című szakaszát.Az alkalmazás rámutatása a (korábbi) replikára
Minden kiszolgáló egyedi kapcsolati sztring rendelkezik. Frissítse az alkalmazást úgy, hogy a forrás helyett a (korábbi) replikára mutasson.
Miután az alkalmazás sikeresen feldolgozta az olvasásokat és írásokat, elvégezte a feladatátvételt. Az alkalmazás által tapasztalt állásidő mértéke attól függ, hogy mikor észleli a problémát, és végrehajtja a korábban felsorolt 1. és 2. lépést.
Globális tranzakcióazonosító (GTID)
A globális tranzakcióazonosító (GTID) egy egyedi azonosító, amely minden lekötött tranzakcióval létrejön egy forráskiszolgálón, és alapértelmezés szerint ki van kapcsolva az Azure Database for MySQL-ben. A GTID az 5.7-s és a 8.0-s verzióban támogatott, és csak olyan kiszolgálókon, amelyek legfeljebb 16 TB-os (általános célú tárolás v2)-t támogatnak. Ha többet szeretne megtudni a GTID-ről és a replikációban való használatáról, tekintse meg a MySQL replikációját a GTID dokumentációjával.
A MySQL kétféle tranzakciótípust támogat: GTID-tranzakciókat (a GTID-vel azonosítva) és névtelen tranzakciókat (nincs lefoglalva GTID)
A GTID konfigurálásához a következő kiszolgálóparaméterek érhetők el:
| Kiszolgálóparaméter | Leírás | Alapértelmezett érték | Értékek |
|---|---|---|---|
gtid_mode |
Azt jelzi, hogy a GTID-k a tranzakciók azonosítására szolgálnak-e. A módok közötti módosításokat egyszerre csak egy lépésben, növekvő sorrendben lehet elvégezni (pl. OFF - ->>ON_PERMISSIVEOFF_PERMISSIVE -)>ON |
OFF |
OFF: Az új és a replikációs tranzakcióknak névtelennek kell lenniük OFF_PERMISSIVE: Az új tranzakciók névtelenek. A replikált tranzakciók lehetnek névtelen vagy GTID-tranzakciók. ON_PERMISSIVE: Az új tranzakciók GTID-tranzakciók. A replikált tranzakciók lehetnek névtelen vagy GTID-tranzakciók. ON: Az új és a replikált tranzakcióknak GTID-tranzakcióknak kell lenniük. |
enforce_gtid_consistency |
A GTID konzisztenciáját úgy kényszeríti ki, hogy csak azokat az utasításokat engedélyezi, amelyek tranzakciós szempontból biztonságos módon naplózhatók. Ezt az értéket a GTID-replikáció engedélyezése előtt be kell állítani ON . |
OFF |
OFF: Minden tranzakció megsértheti a GTID konzisztenciáját. ON: Egyetlen tranzakció sem sértheti a GTID konzisztenciáját. WARN: Minden tranzakció megsértheti a GTID konzisztenciáját, de figyelmeztetés jön létre. |
Feljegyzés
A GTID engedélyezése után nem kapcsolhatja vissza. Ha ki kell kapcsolnia a GTID-t, forduljon az ügyfélszolgálathoz.
Ha a GTID-eket egy értékről egy másikra szeretné módosítani, egyszerre csak egy lépés lehet növekvő sorrendben. Ha például gtid_mode jelenleg OFF_PERMISSIVE értékre van állítva, akkor lehetséges a ON_PERMISSIVE értékre váltani, de nem BE értékre.
A replikáció konzisztensségének megőrzése érdekében nem frissítheti a főkiszolgáló/replikakiszolgáló esetében.
Ajánlott bekapcsolva enforce_gtid_consistency beállítani, mielőtt beállíthat gtid_mode=BE
A GTID engedélyezéséhez és a konzisztencia viselkedésének konzisztenciájának konfigurálásához frissítse a és a gtid_mode kiszolgáló paramétereit az Azure Portal, az Azure CLI vagy a PowerShellenforce_gtid_consistency használatával.
Ha a GTID engedélyezve van egy forráskiszolgálón (gtid_mode = ON), az újonnan létrehozott replikák is engedélyezve lesznek a GTID-vel, és GTID-replikációt használnak. Annak érdekében, hogy a replikáció konzisztens legyen, nem módosítható, gtid_mode ha a fő- vagy replikakiszolgáló(ka)t engedélyezve van a GTID.
Szempontok és korlátozások
Tarifacsomagok
Az olvasási replikák jelenleg csak az Általános célú és memóriaoptimalizált tarifacsomagokban érhetők el.
Feljegyzés
A replikakiszolgáló futtatásának költsége azon a régión alapul, ahol a replikakiszolgáló fut.
Forráskiszolgáló újraindítása
Az általános célú tároló v1-et log_bin tartalmazó kiszolgáló alapértelmezés szerint KI lesz kapcsolva. Az érték be lesz kapcsolva az első olvasási replika létrehozásakor. Ha egy forráskiszolgáló nem rendelkezik meglévő olvasási replikákkal, a forráskiszolgáló először újraindul, hogy előkészítse magát a replikációra. Fontolja meg a kiszolgáló újraindítását, és hajtsa végre ezt a műveletet csúcsidőn kívül.
Az általános célú tároló v2-vel rendelkező forráskiszolgáló alapértelmezés szerint be van kapcsolva, log_bin és nem igényel újraindítást olvasási replika hozzáadásakor.
Új replikák
Az olvasási replika új Azure Database for MySQL-kiszolgálóként jön létre. Egy meglévő kiszolgáló nem készíthető replikává. Egy másik olvasási replika replikája nem hozható létre.
Replika konfigurálása
A replika a forrással megegyező kiszolgálókonfigurációval jön létre. A replika létrehozása után a forráskiszolgálótól függetlenül több beállítás is módosítható: számítási létrehozás, virtuális magok, tárolási és biztonsági mentési megőrzési időszak. A tarifacsomag az Alapszintű szint kivételével függetlenül is módosítható.
Fontos
Mielőtt a forráskiszolgálói konfigurációt új értékekre frissítené, frissítse a replika konfigurációját az értékekkel egyenlő vagy nagyobb értékekre. Ez a művelet biztosítja, hogy a replika összhangban lehessen a forráson végrehajtott módosításokkal.
A tűzfalszabályok és a paraméterbeállítások a forráskiszolgálótól a replikaig öröklődnek a replika létrehozásakor. Ezt követően a replika szabályai függetlenek.
Leállított replikák
Ha leállítja a replikációt egy forráskiszolgáló és egy olvasási replika között, a leállított replika önálló kiszolgálóvá válik, amely olvasást és írást egyaránt elfogad. Az önálló kiszolgáló nem készíthető újra replikává.
Törölt forrás- és önálló kiszolgálók
A forráskiszolgáló törlésekor a replikáció le lesz állítva az összes olvasási replikára. Ezek a replikák automatikusan önálló kiszolgálókká válnak, és olvasási és írási műveleteket is elfogadnak. Maga a forráskiszolgáló törlődik.
Felhasználói fiókok
A forráskiszolgáló felhasználóit a rendszer az olvasási replikákra replikálja. Csak a forráskiszolgálón elérhető felhasználói fiókok használatával csatlakozhat olvasási replikához.
Kiszolgálóparaméterek
Az adatszinkronizálás biztosítása és az esetleges adatvesztés vagy -sérülés elkerülése érdekében bizonyos kiszolgálóparaméterek zárolva vannak, hogy ne lehessen őket módosítani olvasási replikák használata során.
A forrás- és replikakiszolgálókon a következő kiszolgálóparaméterek vannak zárolva:
A event_scheduler paraméter zárolva van a replikakiszolgálókon.
A forráskiszolgáló fenti paramétereinek frissítéséhez törölje a replikakiszolgálókat, frissítse a forrás paraméterértékét, és hozza létre újra a replikákat.
GTID
A GTID a következő eszközökön támogatott:
- A MySQL 5.7-ös és 8.0-s verziója.
- Legfeljebb 16 TB tárhelyet támogató kiszolgálók. A 16 TB-os tárterületet támogató régiók teljes listáját a tarifacsomagról szóló cikkben találja.
A GTID alapértelmezés szerint KI VAN kapcsolva. A GTID engedélyezése után azt nem kapcsolhatja vissza. Ha ki szeretné kapcsolni a GTID-t, forduljon az ügyfélszolgálathoz.
Ha a GTID engedélyezve van egy forráskiszolgálón, az újonnan létrehozott replikákon is engedélyezve lesz a GTID, és azok a GTID-replikációt használják majd. A replikáció konzisztensen tartása érdekében nem frissíthet gtid_mode a forrás- vagy replikakiszolgáló(ka)n.
Egyéb
- A replika replika létrehozása nem támogatott.
- A memóriában lévő táblák miatt a replikák nem lesznek szinkronizálva. Ez a MySQL replikációs technológia korlátozása. További információt a MySQL referenciadokumentációjában talál.
- Győződjön meg arról, hogy a forráskiszolgáló táblái rendelkeznek elsődleges kulcsokkal. Az elsődleges kulcsok hiánya replikációs késést okozhat a forrás és a replikák között.
- Tekintse át a MySQL-replikációs korlátozások teljes listáját a MySQL dokumentációjában