Replikáció késésének hibaelhárítása az Azure Database for MySQL-ben – rugalmas kiszolgáló
A következőkre vonatkozik: 
Azure Database for MySQL – Egykiszolgálós Azure Database for MySQL – Rugalmas 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?
Feljegyzés
Ez a cikk egy olyan kifejezésre hivatkozik, 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.
Az olvasási replika funkcióval adatokat replikálhat egy Azure Database for MySQL-kiszolgálóról egy írásvédett replikakiszolgálóra. A számítási feladatokat úgy skálázhatja fel, hogy olvasási és jelentéskészítési lekérdezéseket irányít az alkalmazástól a replikakiszolgálókig. Ez a beállítás csökkenti a forráskiszolgálóra nehezedő nyomást, és skálázáskor javítja az alkalmazás általános teljesítményét és késését.
A replikák aszinkron módon frissülnek a MySQL-motor natív bináris naplójának (binlog) fájlhelyalapú replikációs technológiájával. További információ: MySQL binlog fájl pozícióalapú replikációs konfiguráció áttekintése.
A másodlagos olvasási replikák replikációs késése több tényezőtől függ. Ezek a tényezők közé tartoznak, de nem korlátozódnak a következőkre:
- Hálózati késés.
- Tranzakciómennyiség a forráskiszolgálón.
- A forráskiszolgáló és a másodlagos olvasási replikakiszolgáló számítási szintje.
- A forráskiszolgálón és a másodlagos kiszolgálón futó lekérdezések.
Ebben a cikkben megtudhatja, hogyan háríthatja el a replikáció késését az Azure Database for MySQL-ben. Emellett jobban megismerheti a replikakiszolgálók replikációs késésének gyakori okait is.
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.
Replikációs fogalmak
Ha engedélyezve van a bináris napló, a forráskiszolgáló véglegesített tranzakciókat ír a bináris naplóba. A bináris napló a replikációhoz használatos. Alapértelmezés szerint be van kapcsolva az összes újonnan kiépített kiszolgáló esetében, amely legfeljebb 16 TB tárterületet támogat. Replikakiszolgálókon két szál fut mindegyik replikakiszolgálón. Az egyik szál az IO-szál, a másik az SQL-szál:
- Az IO-szál csatlakozik a forráskiszolgálóhoz, és frissített bináris naplókat kér. Ez a szál megkapja a bináris naplófrissítéseket. Ezek a frissítések egy replikakiszolgálón, a továbbítási napló nevű helyi naplóban vannak mentve.
- Az SQL-szál beolvassa a továbbítási naplót, majd alkalmazza az adatváltozásokat a replikakiszolgálókon.
Replikáció késésének monitorozása
Az Azure Database for MySQL másodpercek alatt biztosítja a replikáció késésének metrikáit az Azure Monitorban. Ez a metrika csak olvasási replikakiszolgálókon érhető el. Ezt a MySQL-ben elérhető seconds_behind_master metrika számítja ki.
A megnövekedett replikációs késés okának megértéséhez csatlakozzon a replikakiszolgálóhoz a MySQL Workbench vagy az Azure Cloud Shell használatával. Ezután futtassa a következő parancsot.
Feljegyzés
A kódban cserélje le a példaértékeket a replikakiszolgáló nevére és a rendszergazdai felhasználónévre. A rendszergazdai felhasználónév az Azure Database for MySQL-hez szükséges @\<servername> .
mysql --host=myreplicademoserver.mysql.database.azure.com --user=myadmin@mydemoserver -p
Így néz ki a felület a Cloud Shell-terminálban:
Requesting a Cloud Shell.Succeeded.
Connecting terminal...
Welcome to Azure Cloud Shell
Type "az" to use Azure CLI
Type "help" to learn about Cloud Shell
user@Azure:~$mysql -h myreplicademoserver.mysql.database.azure.com -u myadmin@mydemoserver -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 64796
Server version: 5.6.42.0 Source distribution
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>
Ugyanazon a Cloud Shell-terminálon futtassa a következő parancsot:
mysql> SHOW SLAVE STATUS;
Íme egy tipikus kimenet:
A kimenet számos információt tartalmaz. Általában csak azokra a sorokra kell összpontosítania, amelyeket az alábbi táblázat ír le.
Ha Slave_IO_Running van Yes , és Slave_SQL_Running, Yesakkor a replikáció jól fut.
Ezután ellenőrizze Last_IO_Errno, Last_IO_Error, Last_SQL_Errno és Last_SQL_Error. Ezek a mezők az SQL-szál leállását okozó legutóbbi hiba hibaszámát és hibaüzenetét jelenítik meg. A hibaszám 0 és az üres üzenet azt jelenti, hogy nincs hiba. A mySQL-kiszolgáló hibaüzenet-hivatkozásában található hibakód ellenőrzésével vizsgálja meg a nem kötelező hibaértékeket.
Gyakori forgatókönyvek a magas replikációs késéshez
Az alábbi szakaszok olyan forgatókönyveket ismertetik, amelyekben gyakori a magas replikációs késés.
Hálózati késés vagy magas processzorhasználat a forráskiszolgálón
Ha a következő értékeket látja, akkor a replikáció késését valószínűleg a forráskiszolgáló magas hálózati késése vagy magas processzorhasználata okozza.
Slave_IO_State: Waiting for master to send event
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller than Master_Log_File, e.g. mysql-bin.00010
Ebben az esetben az IO-szál fut, és a forráskiszolgálón várakozik. A forráskiszolgáló már írt a 20-es bináris naplófájlszámra. A replika csak a 10-es fájlszámot kapta. Ebben a forgatókönyvben a magas replikációs késés elsődleges tényezői a hálózati sebesség vagy a forráskiszolgáló magas processzorhasználata.
Az Azure-ban a régión belüli hálózati késés általában ezredmásodpercben mérhető. Régiók között a késés ezredmásodperctől másodpercig terjed.
A legtöbb esetben az IO-szálak és a forráskiszolgáló közötti kapcsolat késleltetését a forráskiszolgáló magas processzorhasználata okozza. Az IO-szálak feldolgozása lassan történik. Ezt a problémát az Azure Monitor használatával észlelheti a processzorkihasználtság és az egyidejű kapcsolatok számának ellenőrzéséhez a forráskiszolgálón.
Ha nem látja a forráskiszolgáló magas processzorkihasználtságát, a probléma hálózati késés lehet. Ha a hálózati késés hirtelen kirívóan magas, ellenőrizze az Azure állapotlapján az ismert problémákat vagy kimaradásokat.
Nagy mennyiségű tranzakció a forráskiszolgálón
Ha a következő értékeket látja, akkor a forráskiszolgálón a tranzakciók nagy száma valószínűleg a replikáció késését okozza.
Slave_IO_State: Waiting for the slave SQL thread to free enough relay log space
Master_Log_File: the binary file sequence is larger then Relay_Master_Log_File, e.g. mysql-bin.00020
Relay_Master_Log_File: the file sequence is smaller then Master_Log_File, e.g. mysql-bin.00010
A kimenet azt mutatja, hogy a replika le tudja kérni a bináris naplót a forráskiszolgáló mögött. A replika I/O-szál azonban azt jelzi, hogy a továbbítási naplóterület már megtelt.
A hálózati sebesség nem okozza a késést. A replika próbál felzárkózni. A frissített bináris naplóméret azonban meghaladja a továbbítási naplóterület felső korlátját.
A probléma elhárításához engedélyezze a lassú lekérdezési naplót a forráskiszolgálón. Lassú lekérdezési naplók használatával azonosíthatja a forráskiszolgálón futó hosszú ideig futó tranzakciókat. Ezután hangolja be az azonosított lekérdezéseket a kiszolgáló késésének csökkentése érdekében.
Az ilyen típusú replikáció késését általában a forráskiszolgáló adatbetöltése okozza. Ha a forráskiszolgálók heti vagy havi adatterheléssel rendelkeznek, a replikáció késése sajnos elkerülhetetlen. A replikakiszolgálók végül felzárkóznak, miután a forráskiszolgáló adatbetöltése befejeződött.
Lassúság a replikakiszolgálón
Ha a következő értékeket figyeli meg, akkor a probléma a replikakiszolgálón lehet.
Slave_IO_State: Waiting for master to send event
Master_Log_File: The binary log file sequence equals to Relay_Master_Log_File, e.g. mysql-bin.000191
Read_Master_Log_Pos: The position of master server written to the above file is larger than Relay_Log_Pos, e.g. 103978138
Relay_Master_Log_File: mysql-bin.000191
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: The position of slave reads from master binary log file is smaller than Read_Master_Log_Pos, e.g. 13468882
Seconds_Behind_Master: There is latency and the value here is greater than 0
Ebben a forgatókönyvben a kimenet azt mutatja, hogy az IO-szál és az SQL-szál is jól működik. A replika ugyanazt a bináris naplófájlt olvassa be, amelyet a forráskiszolgáló ír. A replikakiszolgáló némi késése azonban ugyanazt a tranzakciót tükrözi a forráskiszolgálótól.
A következő szakaszok az ilyen típusú késés gyakori okait ismertetik.
Nincs elsődleges kulcs vagy egyedi kulcs egy táblában
Az Azure Database for MySQL soralapú replikációt használ. A forráskiszolgáló eseményeket ír a bináris naplóba, és rögzíti az egyes táblasorok változásait. Az SQL-szál ezután replikálja ezeket a módosításokat a replikakiszolgáló megfelelő táblázatsoraiba. Ha egy tábla nem rendelkezik elsődleges kulccsal vagy egyedi kulccsal, az SQL-szál a céltábla összes sorát megvizsgálja a módosítások alkalmazásához. Ez a vizsgálat replikációs késést eredményezhet.
A MySQL-ben az elsődleges kulcs egy társított index, amely gyors lekérdezési teljesítményt biztosít, mert nem tartalmazhat NULL értékeket. Ha az InnoDB-tárolómotort használja, a táblaadatok fizikailag úgy lesznek rendszerezve, hogy ultragyors kereséseket és rendezést végezzenek az elsődleges kulcs alapján.
Javasoljuk, hogy a replikakiszolgáló létrehozása előtt adjon hozzá egy elsődleges kulcsot a forráskiszolgáló tábláihoz. Adjon hozzá elsődleges kulcsokat a forráskiszolgálóhoz, majd hozzon létre újra olvasási replikákat a replikáció késésének javítása érdekében.
Az alábbi lekérdezéssel megtudhatja, hogy mely táblák hiányoznak egy elsődleges kulcsból a forráskiszolgálón:
select tab.table_schema as database_name, tab.table_name
from information_schema.tables tab left join
information_schema.table_constraints tco
on tab.table_schema = tco.table_schema
and tab.table_name = tco.table_name
and tco.constraint_type = 'PRIMARY KEY'
where tco.constraint_type is null
and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys')
and tab.table_type = 'BASE TABLE'
order by tab.table_schema, tab.table_name;
Hosszú ideig futó lekérdezések a replikakiszolgálón
A replikakiszolgáló számítási feladatai miatt az SQL-szál lemaradhat az IO-szál mögött. A replikakiszolgálón hosszan futó lekérdezések a magas replikációs késés egyik gyakori okai. A probléma elhárításához engedélyezze a lassú lekérdezési naplót a replikakiszolgálón.
A lassú lekérdezések növelhetik az erőforrás-felhasználást, vagy lelassíthatják a kiszolgálót, hogy a replika ne tudja felzárkózni a forráskiszolgálót. Ebben a forgatókönyvben finomhangolja a lassú lekérdezéseket. A gyorsabb lekérdezések megakadályozzák az SQL-szál blokkolását, és jelentősen javítják a replikáció késését.
DDL-lekérdezések a forráskiszolgálón
A forráskiszolgálón egy adatdefiníciós nyelv (DDL) parancs, például ALTER TABLE hosszú időt vehet igénybe. A DDL-parancs futtatása közben több ezer lekérdezés fut párhuzamosan a forráskiszolgálón.
A DDL replikálásakor az adatbázis konzisztenciájának biztosítása érdekében a MySQL-motor egyetlen replikációs szálon futtatja a DDL-t. Ebben a feladatban minden más replikált lekérdezés le lesz tiltva, és várnia kell, amíg a DDL-művelet befejeződik a replikakiszolgálón. Még az online DDL-műveletek is okozzák ezt a késést. A DDL-műveletek növelik a replikáció késését.
Ha engedélyezte a lassú lekérdezési naplót a forráskiszolgálón, ezt a késési problémát a forráskiszolgálón futó DDL-parancs keresésével észlelheti. Az index elvetésével, átnevezésével és létrehozásával használhatja az INPLACE algoritmust az ALTER TABLE-hez. Előfordulhat, hogy át kell másolnia a táblázat adatait, és újra kell építenie a táblát.
Az inplace algoritmus általában támogatja az egyidejű DML-t. A művelet előkészítésekor és futtatásakor azonban rövid ideig kizárólagos metaadat-zárolást végezhet a táblán. A CREATE INDEX utasítás esetében tehát az ALGORITMUS és a LOCK záradékokkal befolyásolhatja a táblázatmásolási módszert, valamint az olvasási és írási egyidejűség szintjét. Továbbra is megakadályozhatja a DML-műveleteket teljes szöveges index vagy TÉRBELI index hozzáadásával.
Az alábbi példa algoritmus- és LOCK-záradékok használatával hoz létre indexet.
ALTER TABLE table_name ADD INDEX index_name (column), ALGORITHM=INPLACE, LOCK=NONE;
Sajnos a zárolást igénylő DDL-utasítások esetében nem lehet elkerülni a replikáció késését. A lehetséges hatások csökkentése érdekében végezze el az ilyen típusú DDL-műveleteket csúcsidőn kívül, például éjszaka.
Visszaminősített replikakiszolgáló
Az Azure Database for MySQL-ben az olvasási replikák ugyanazt a kiszolgálókonfigurációt használják, mint a forráskiszolgáló. A replikakiszolgáló konfigurációját a létrehozása után módosíthatja.
Ha a replikakiszolgáló le van csökkentve, a számítási feladat több erőforrást használhat fel, ami viszont replikációs késéshez vezethet. A probléma észleléséhez az Azure Monitor használatával ellenőrizze a replikakiszolgáló processzor- és memóriahasználatát.
Ebben a forgatókönyvben azt javasoljuk, hogy a replikakiszolgáló konfigurációját a forráskiszolgáló értékeivel megegyező vagy annál nagyobb értékeken tartsa. Ez a konfiguráció lehetővé teszi, hogy a replika lépést tartson a forráskiszolgálóval.
A replikáció késésének javítása a forráskiszolgáló paramétereinek finomhangolásával
Az Azure Database for MySQL-ben alapértelmezés szerint a replikáció úgy van optimalizálva, hogy párhuzamos szálakkal fusson a replikákon. Ha a forráskiszolgálón magas egyidejűségi számítási feladatok okozzák a replikakiszolgáló lemaradását, a replikáció késését a forráskiszolgálón binlog_group_commit_sync_delay paraméter konfigurálásával javíthatja.
A binlog_group_commit_sync_delay paraméter szabályozza, hogy a bináris napló véglegesítése hány mikroszekundumot vár a bináris naplófájl szinkronizálása előtt. Ennek a paraméternek az az előnye, hogy az összes véglegesített tranzakció azonnali alkalmazása helyett a forráskiszolgáló tömegesen küldi el a bináris naplófrissítéseket. Ez a késés csökkenti a replika I/O-jának számát, és javítja a teljesítményt.
Hasznos lehet az binlog_group_commit_sync_delay paramétert 1000-re állítani. Ezután figyelje a replikáció késését. Ezt a paramétert óvatosan állítsa be, és csak nagy egyidejűségi számítási feladatokhoz használja.
Fontos
A replikakiszolgálón binlog_group_commit_sync_delay paraméter használata javasolt 0. Ez azért ajánlott, mert a forráskiszolgálótól eltérően a replikakiszolgáló nem rendelkezik magas egyidejűséggel, és a replikakiszolgálón lévő binlog_group_commit_sync_delay értékének növelése véletlenül a replikáció késésének növekedéséhez vezethet.
A sok egyszeri tranzakciót tartalmazó alacsony egyidejűségi számítási feladatok esetében a binlog_group_commit_sync_delay beállítás növelheti a késést. A késés növekedhet, mert az IO-szál akkor is vár a tömeges bináris naplófrissítésekre, ha csak néhány tranzakciót véglegesített.
Speciális hibaelhárítási beállítások
Ha a rabszolga állapotának megjelenítése parancs nem nyújt elegendő információt a replikáció késésének elhárításához, próbálja meg megtekinteni ezeket a további lehetőségeket annak megismeréséhez, hogy mely folyamatok aktívak vagy várakoznak.
A szálak táblázatának megtekintése
A performance_schema.threads táblázat a folyamat állapotát mutatja. A lock_type zárolásra váró állapotú folyamat azt jelzi, hogy az egyik táblán zárolás van, ami megakadályozza, hogy a replikációs szál frissítse a táblát.
SELECT name, processlist_state, processlist_time FROM performance_schema.threads WHERE name LIKE '%slave%';
További információ: Általános szálállapotok.
A replication_connection_status táblázat megtekintése
A performance_schema.replication_connection_status tábla a replika forráshoz való kapcsolatát kezelő replikációs I/O-szál aktuális állapotát jeleníti meg, és gyakrabban változik. A tábla a kapcsolat során változó értékeket tartalmaz.
SELECT * FROM performance_schema.replication_connection_status;
A replication_applier_status_by_worker tábla megtekintése
A performance_schema.replication_applier_status_by_worker táblázat a feldolgozó szálak állapotát, a legutóbb látott tranzakciót, valamint az utolsó hibaszámot és üzenetet jeleníti meg, amely segít megtalálni a problémát okozó tranzakciót, és azonosítani a kiváltó okot.
A hibák vagy tranzakciók kihagyásához futtassa az alábbi parancsokat a Data-in replikációban:
az_replication_skip_counter
vagy
az_replication_skip_gtid_transaction
SELECT * FROM performance_schema.replication_applier_status_by_worker;
A RELAYLOG ESEMÉNYEK MEGJELENÍTÉSE utasítás megtekintése
Az show relaylog events utasítás egy replika továbbítási naplójában lévő eseményeket jeleníti meg.
· A GITD-alapú replikáció (olvasási replika) esetében az utasítás a GTID-tranzakciót és a binlogfájlt, valamint annak pozícióját jeleníti meg, a mysqlbinlog használatával lekérheti a futtatott tartalmakat és utasításokat. · A MySQL binlog pozícióreplikációs (data-in replikációhoz használt) esetében megjeleníti a futtatott utasításokat, amelyek segítenek tudni, hogy mely táblatranzakciók futnak
Ellenőrizze az InnoDB Standard Monitor és a Lock Monitor kimenetét
Megpróbálhatja ellenőrizni az InnoDB Standard Monitor és Lock Monitor kimenetét is, hogy segítsen feloldani a zárolásokat és holtpontokat, és minimalizálni a replikáció késését. A Zárolásfigyelő ugyanaz, mint a Standard figyelő, kivéve, hogy további zárolási információkat tartalmaz. A további zárolási és holtpont-információk megtekintéséhez futtassa a show engine innodb status\G parancsát.
Következő lépések
Tekintse meg a MySQL binlog replikációjának áttekintését.