Share via

Olvasási replikák az Azure Database for MySQL-ben

  • Cikk

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. You can replicate from the source server to up to five replicas. Replicas are updated asynchronously using the MySQL engine's native binary log (binlog) file position-based replication technology. 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.

Megjegyzés:

This article contains references to the term slave, a term that Microsoft no longer uses. 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:

Region Replika rendelkezésre állása
Australia East ✔️
Délkelet-Ausztrália ✔️
Dél-Brazília ✔️
Canada Central ✔️
Canada East ✔️
Central US ✔️
East US ✔️
East US 2 ✔️
East Asia ✔️
Japan East ✔️
Japan West ✔️
Korea Central ✔️
Dél-Korea déli régiója ✔️
North Europe ✔️
North Central US ✔️
South Central US ✔️
Southeast Asia ✔️
Switzerland North ✔️
UK South ✔️
UK West ✔️
West Central US ✔️
West US ✔️
West US 2 ✔️
West Europe ✔️
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* ✔️

Megjegyzé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:

  1. 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.

  2. 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 Ismerteté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.

Megjegyzé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 Standard kiadás T enforce_gtid_consistency BE értékre, 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.

Megjegyzé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

További lépések