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

Replikák olvasása az Azure Database for MySQL-ben – rugalmas kiszolgáló

  • Cikk

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

A MySQL az internetes webes és mobilalkalmazások futtatásának egyik népszerű adatbázismotorja. Sok ügyfelünk online oktatási szolgáltatásokhoz, videostreamelési szolgáltatásokhoz, digitális fizetési megoldásokhoz, e-kereskedelmi platformokhoz, játékszolgáltatásokhoz, hírportálokhoz, kormányzati és egészségügyi webhelyekhez használja. Ezek a szolgáltatások a webes vagy mobilalkalmazások forgalmának növekedésével kapcsolatos kiszolgáláshoz és skálázáshoz szükségesek.

Az alkalmazások oldalán az alkalmazás általában Java-ban vagy PHP-ben van kifejlesztve, és migrálva van az Azure-beli virtuálisgép-méretezési csoportokon vagy Azure-alkalmazás-szolgáltatásokon való futtatáshoz, vagy tárolóba van állítva az Azure Kubernetes Service-en (AKS) való futtatáshoz. A virtuálisgép-méretezési csoport, az App Service vagy az AKS háttérinfrastruktúra esetén az alkalmazás skálázása egyszerűsödik új virtuális gépek azonnali kiépítésével és az alkalmazások állapot nélküli összetevőinek replikálásával, hogy kiszolgálják a kéréseket, de az adatbázis gyakran szűk keresztmetszetet jelent központosított állapotalapú összetevőként.

Az olvasási replika funkcióval adatokat replikálhat egy rugalmas Azure Database for MySQL-kiszolgálópéldányból egy írásvédett kiszolgálóra. A forráskiszolgálóról legfeljebb 10 replikára replikálhat. 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 rugalmas Azure Database for MySQL-kiszolgálópéldányokhoz hasonlóan kezel. Az egyes olvasási replikákért számlázási díjakat kell fizetnie a virtuális magokban kiosztott számítás és a gb/hó tárterület alapján. További információt a díjszabás tartalmaz.

Feljegyzés

Az olvasási replika funkció csak a rugalmas Azure Database for MySQL-kiszolgálópéldányokhoz érhető el az Általános célú vagy üzletileg kritikus tarifacsomagokban. Győződjön meg arról, hogy a forráskiszolgáló ezen tarifacsomagok egyikében található.

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.

Olvasási replika gyakori használati esetei

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önyvek a következők:

  • Az alkalmazásból származó olvasási számítási feladatok skálázása egyszerű kapcsolatproxyval, például ProxySQL-lel vagy mikroszolgáltatás-alapú mintával az alkalmazásból érkező olvasási lekérdezések felskálázásához replikák olvasásához
  • A BI- vagy elemzési jelentéskészítési számítási feladatok olvasási replikákat használhatnak adatforrásként jelentéskészítéshez
  • Olyan IoT- vagy gyártási forgatókönyv esetén, amikor a telemetriai adatok a MySQL-adatbázismotorba kerülnek, miközben több olvasási replikát használnak az adatok jelentéséhez

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 van 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. A rugalmas Azure Database for MySQL-kiszolgáló lehetővé teszi olvasási replika kiépítését minden olyan Azure-támogatás régióban, ahol az Azure Database for MySQL rugalmas kiszolgáló elérhető. Ezzel a funkcióval a forráskiszolgáló rendelkezhet replikával a párosított régióban vagy az univerzális replikarégiókban. Itt találja azoknak az Azure-régióknak a listáját, ahol a rugalmas Azure Database for MySQL-kiszolgáló jelenleg elérhető.

Replika létrehozása

Ha egy forráskiszolgáló nem rendelkezik meglévő replikakiszolgálókkal, a forrás először újraindul, hogy előkészítse magát a replikációra.

A replika létrehozásakor létrejön egy üres Azure Database for MySQL-kiszolgálópéldány. 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.

Feljegyzés

Az olvasási replikák a forrással megegyező kiszolgálókonfigurációval jönnek létre. A replikakiszolgáló konfigurációja a létrehozása után módosítható. 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 . Javasoljuk, hogy a replikakiszolgáló konfigurációját a forrásnál egyenlő vagy nagyobb értéken tartsa, hogy a replika lépést tudjon tartani a forrással.

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ó csatlakozási módszerét. A replika csatlakozási módszere nem módosítható. Ha például a forráskiszolgáló privát hozzáféréssel (VNet-integrációval) rendelkezik, akkor a replika nem lehet nyilvános hozzáférésű (engedélyezett IP-címek).

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 rugalmas Azure Database for MySQL-kiszolgálópéldányon 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 -p

Amikor a rendszer kéri, adja meg a felhasználói fiók jelszavát.

Replikálás figyelése

A rugalmas Azure Database for MySQL-kiszolgáló 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.

Fontos

Az Olvasási replika tárolási alapú replikációs technológiát használ, amely már nem használja a MySQL "SHOW SLAVE STATUS"/"SHOW REPLICA STATUS" parancsában elérhető "SLAVE_IO_RUNNING"/"REPLICA_IO_RUNNING" metrikát. Ez az érték mindig "Nem" értékként jelenik meg, és nem jelzi a replikáció állapotát. A replikáció helyes állapotának megismeréséhez tekintse meg a replikációs metrikákat – Replika IO-állapota és replika SQL-állapota a Figyelés panelen.

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.

Az olvasási replikák olvasásigényes számítási feladatok skálázására szolgálnak, és nem a kiszolgáló magas rendelkezésre állási igényeinek kielégítésére lettek kialakítva. A manuális feladatátvétel végrehajtásának módja, hogy az olvasási replikán leállítsa a replikációt, hogy online állapotba hozza azt olvasási módban.

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 végzett a replikára, a replika forrásból való leválasztásának késése jelzi, hogy mennyi adat veszett el.

Miután eldöntötte, hogy át szeretne adni egy replikát:

  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 fenti 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 véglegesített tranzakcióval létrejön egy forráskiszolgálón, és alapértelmezés szerint ki van kapcsolva a rugalmas Azure Database for MySQL-kiszolgálón. A GTID az 5.7-ös és a 8.0-s verzióban támogatott. 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 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.

Azon rugalmas Azure Database for MySQL-kiszolgálópéldányok esetében, amelyeken engedélyezve van a magas rendelkezésre állási funkció, az alapértelmezett érték a következőre ONvan állítva: .

Feljegyzés

  • A GTID engedélyezése után azt nem kapcsolhatja vissza. Ha ki kell kapcsolnia a GTID-t, forduljon az ügyfélszolgálathoz.
  • A GTID-ket egyszerre csak egy lépésben, növekvő sorrendben módosíthatja az egyik értékről a másikra. Ha például az gtid_mode jelenleg OFF_PERMISSIVE értékre van állítva, lehetséges, hogy ON_PERMISSIVE értékre vált, 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.
  • A gtid_mode=ON beállítás előtt ajánlott enforce_gtid_consistency BE értékre állítani.

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 vagy az Azure CLIenforce_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 vannak a GTID-vel, és GTID-replikációt használnak. Annak érdekében, hogy a replikáció konzisztens legyen, gtid_mode nem módosítható, ha a főkiszolgáló vagy replikakiszolgáló(k) létrejöttek a GTID engedélyezésével.

Szempontok és korlátozások

Eset Korlátozás/megfontolandó szempontok
Replika a kiszolgálón a burstable tarifacsomagban Nem támogatott
Díjszabá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 Ha olyan forráshoz hoz létre replikát, amely nem rendelkezik meglévő replikákkal, a forrás először újraindul, hogy felkészüljön a replikációra. Ezt vegye figyelembe, és hajtsa végre ezeket a műveleteket csúcsidőn kívüli időszakban
Új replikák Az olvasási replika új rugalmas Azure Database for MySQL-kiszolgálópéldányké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 számítási szint egymástól függetlenül is módosítható.

FONTOS – Mielőtt a forráskiszolgáló konfigurációja új értékekre frissül, frissítse a replika konfigurációját 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 kapcsolati módszer és a paraméterbeállítások a forráskiszolgálótól a replikához ö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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Munkamenet-szintű paraméterek Amikor munkamenetszintű paramétereket (például "foreign_keys_checks" ) konfigurál az olvasási replikán, győződjön meg arról, hogy az olvasási replikán beállított paraméterértékek összhangban vannak a forráskiszolgáló paraméterértékeivel.
AUTO_INCREMENT Elsődleges kulcs oszlop hozzáadása a forráskiszolgáló meglévő táblához. Nem javasoljuk a tábla módosítását AUTO_INCREMENT olvasás utáni replika létrehozásakor, mivel az megszakítja a replikációt. Ha azonban replikakiszolgáló létrehozása után szeretné hozzáadni az automatikus növekményes oszlopot, az alábbi két módszert javasoljuk:
– Hozzon létre egy új táblát ugyanazzal a sémával, amelyet módosítani szeretne. Az új táblában módosítsa az oszlopot AUTO_INCREMENT, majd az eredeti táblából állítsa vissza az adatokat. Helyezze el a régi táblát, és nevezze át a forrásban. Ehhez nincs szükség a replikakiszolgáló törlésére, de előfordulhat, hogy a biztonsági mentési tábla létrehozásához nagy beszúrási költségre van szükség.
- A másik gyorsabb módszer a replika újbóli létrehozása az összes automatikus növekményes oszlop hozzáadása után.
Egyéb – Replika replika létrehozása nem támogatott.
- A memóriában lévő táblák miatt a replikák nem szinkronizálódnak. 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

Következő lépések