A MySQL magas rendelkezésre állású architektúrákban az elsődleges adatbázis-replikáció nagyon gyakori típus.
Amikor az elsődleges adatbázis leáll, egy szolgaadatbázist frissíthetsz új elsődleges adatbázissá a szolgáltatás elérhetőségének biztosítása érdekében. Ugyanakkor a teljes klaszter QPS-e javítható a slave könyvtár bővítésével.
A master-slave replikációs architektúra alatt a MySQL binlogot használ a master-slave adatkonzisidencián eléréséhez.
Ahogy a fenti ábrán látható, a MySQL mester-slave replikáció főként a következő lépésekből áll
1. A mester naplózza a bináris napló változásait
2. A szolga io_thread a fő könyvtár binlogját kérje, és az így kapott binlog naplót írja a relé naplóba
3. Rabszolga sql_thread ismételd meg az eseményeket a relay naplóban
A binlog nemcsak a MySQL master-slave replikációhoz való hivatkozás, hanem más célokat is szolgál. Például:
1. Használd a mysqlbinlog eszközt a binlog fájl elemzésére az időbeli adatbázis-helyreállítás végrehajtásához.
2. Adatbázis visszaemlékezése binlog események alapján (a MariaDB közvetlenül használhatja a mysqlbinlogot flashbackhez)
3. A Github nyílt forráskódú online táblázatváltó eszköze, a gh-ost szintén binlogon keresztül van megvalósítva
4. A binlogokat szegélyezéssel is fokozatosan feliratkozhatsz és fogyaszthatod
A binlog nagyon hasznos, de elkerülhetetlen, hogy a napi működés és karbantartás során problémákba ütközhetsz. Íme néhány binloghoz kapcsolódó hiba.
Az egyik leggyakrabban feltett kérdés
Jelenség
MySQLBinlog5.5 elemzi a MySQL5.7 binlog fájlt
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Ok-elemzés
A MySQL 5.6 és más magasabb binlog fájlok verziók új binlog eseményeket adtak hozzá, például GTID eseményeket.
A mysqlbinlog a mySQL5.5-ben nem ismeri fel az ilyen binlog eseményeket.
Megoldás
Használd a mysqlbinlog magasabb verzióját a mysqlbinlog alacsonyabb verzió által generált binlog feloldásához
Második gyakran feltett kérdés
Jelenség
Egy egészséges mysql szerver szolga státuszt jelenít meg
Last_SQL_Error:Relay log olvasási hiba: Nem tudtam parzálni a relay log eseménybejegyzést.
A lehetséges okok: a mester bináris naplója megsérült (ezt ellenőrizheted a 'mysqlbinlog' futtatásával a bináris naplón),
A slave relay naplója megsérült (ezt ellenőrizheted a 'MySQLBinlog' futtatásával a relay naplóban),
hálózati probléma, vagy hiba a mester vagy szolga MySQL kódjában.
Ha ellenőrizni akarod a mester bináris naplóját vagy a rabszolga relé naplóját,
A nevüket úgy tudhatod, ha kiadod a 'MUTASSA RABSZOLGA STÁTUSZ' jelzést ezen a rabszolgán.
Ok-elemzés
A relénapló bejegyzései nem olvashatók binlog hibák miatt a master könyvtárban, a slave könyvtárban lévő relay naplóhibák, vagy hálózati problémák és hibák miatt. Általában hálózati hiba vagy a szolga könyvtárra gyakorolt túlzott nyomás okozza, ami helytelen relé-log formátumot eredményez.
Megoldás
Miután megtalálták a jelenlegi szinkronizációs időpontot és újraállították a master-slave szinkronizációt, új relénaplót generálnak, és a master-slave szinkronizáció helyreáll.
A "show slave status\G" kiadásból találjuk meg a következő információkat:
Relay_Master_Log_File: mysql-bin.002540 // A szolga könyvtár által olvasott mester binlogExec_Master_Log_Pos: 950583017 // Az a pozíciópozíció pont, amelyet a szolgán futtattak
Állítsd le a szolgát, és állítsd be újra a szinkronizációt a binlog fájlból, amit a szolga olvasott, és a végrehajtott pozícióból.
Relay_Master_Log_File: mysql-bin.002540 // A szolga könyvtár által olvasott mester binlogExec_Master_Log_Pos: 950583017 // Az a pozíciópozíció pont, amelyet a szolgán futtattak
Harmadik gyakran ismételt kérdés
Jelenség
Állítsd vissza a slave státuszt leállás utáni hiba:
Last_SQL_Error: Hiba a relé log pozíciójának inicializálásában: I/O hiba a fejléc olvasása a bináris naplóból
Last_SQL_Error: Hiba inicializálója a relé napló pozíciója: A binlog rossz varázsszámú; Ez nem egy bináris naplófájl, amit ez a MySQL verzió használhat
Ok-elemzés
Leállás, például áramszünet, alaplap égése stb. vagy illegális leállítás, ami a relay-bin fájl megromlásához vezet
Megoldás
Ugyanaz a második kérdés.
relay_log_recovery = 1 is beállítható.
Amikor a slave leáll a könyvtárból, ha a relay-log megsérül és a relay napló egy része nem kerül feldolgozásra, a relay log automatikusan elhagyódik, és a naplót visszanyerik a mesterről, ezzel befejezve a relénapló helyreállítását.
Gyakran ismételt kérdés negyedik
Jelenség
Akkor jelenik meg, amikor a mastert váltja a könyvtárgép újraindítása után
Hiba (1201-es kód): Nem sikerült inicializálni a fő információs struktúrát; további hibaüzenetek találhatók a MySQL hibanaplóban
vagy
HIBA 1872 (HY000): A slave nem inicializálta a relé napló információs struktúráját a tárolóból
Ok-elemzés
Leállás, például áramszünet, alaplap égése stb., vagy illegális leállítás, ami kárt okoz master.info vagy realy-log.info fájlokban
Megoldás
Slave> reset all slave, válts master
Megelőző intézkedések
Profilbeállítások
relay_log_info_repository=táblázat
master_info_repository=táblázat
A MySQL 5.6.5 mysql.slave_master_info és mysql.slave_relay_log_info tárolómotorja alapértelmezetten MyISAM formátumra van állítva, és át kell váltanod az InnoDB tárolómotorjára
MÓDOSÍTÓ TÁBLÁZAT mysql.slave_master_info ENGINE=InnoDB;
MÓDOSÍTÓ TÁBLÁZAT mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info táblázatot sync_master_info események után frissítik.
mysql.slave_relay_log_info táblázatot minden tranzakciós commitnél frissítik.
5. Gyakran Ismételt Kérdés
Jelenség
A master slave eredetileg egy utasítás binlog_format, miután a fő adatbázist sorra binlog_format változtatta, a "show slave státusz" jelenik meg a könyvtárból:
Last_Error: Error executing row event event: 'Nem lehet végrehajtani utasítást: lehetetlen bináris naplóba írni, mivel az utasítás sorformátumban van, és BINLOG_FORMAT = STATEMENT.'
Ok-elemzés
Ha a fő adatbázis binlog_format sor, és a szolga könyvtár binlog_format is utasítás, a fenti hiba jelenik meg.
De a fő könyvtár binlog_format az állásfoglalás, a rabszolgakönyvtár binlog_format sor;
Vagy ha a fő adatbázis binlog_format sor, akkor a hiba nem kerül jelentésbe, ha az adatbázis binlog_format kevert.
Ha az SQL szálad valóban konfigurált
binlog_format=STATEMENT Ha megkap egy SOR-eseményt, megáll. A
az oka az, hogy nem tudná naplózni ezt a ROW eseményt STATEMENTformatban (néha ezt ROW injekciónak is nevezzük, ami vagy egy
BINLOG utasítás vagy egy ROW esemény, amelyet a slave SQL szála hajt végre)
Részletes indoklás:https://bugs.mysql.com/bug.php?id=69095
Megoldás
RABSZOLGA> ÁLLÍTSD RABSZOLGA;
RABSZOLGA> GLOBÁLIS KÉSZLET binlog_format=VEGYES HALMAZ;
RABSZOLGA> KEZDJ RABSZOLGA;
6. számú gyakran ismételt kérdés
Jelenség
Hiba a mysql5.6 és mysql5.5 szinkronizálásakor
Last_IO_Error: Fatal error 1236 a master-től, amikor bináris naplóból olvasott adatokat: 'Slave nem tudja kezelni a replikációs eseményeket azzal az ellenőrzőösszeggel, amelyre a master be van állítva; Az első esemény 'MySQL-bin.000001' 4-kor, az utolsó esemény a 'MySQL Bin.000001' 120-nál, az utolsó bájt a 'MySQL Bin.000001' 120-nál olvasható.
Ok-elemzés
Annak érdekében, hogy megoldják azt a problémát, hogy az elsődleges szerveren futó SQL utasítások nem konzisztenszenek a szerveren futó SQL utasításokkal (úgynevezett event corrupt) szoftver- és hardver- vagy hálózati átviteli hibák miatt, a MySQL 5.6 hozzáadja a Replikációs Esemény Ellenzőösszeg funkciót. Amikor egy eseményt a bináris naplóba írnak, az ellenőrző összeget is a bináris naplóba írják, majd miután az esemény a hálózaton keresztül továbbítódik a szolgának, az a szolgán ellenőrzik, majd a szolga átadó naplójába kerül. Mivel minden lépésnél eseményeket és ellenőrzőösszegeket rögzítenek, gyorsan kideríthetjük, mi a probléma.
A mysql5.6.5 és újabb verziókban binlog_checksum alapértelmezett érték crc32,
Az előző verzió alapértelmezett értéke binlog_checksum nem volt
megoldás
Szolga> globális készlet binlog_checksum=nincs
Gyakran ismételt kérdés 7
Jelenség
Miután a lemez tele van, tisztítsd meg kézzel a binlog fájlt és a mysql-bin.index fájlt
A show binary naplók üresek, de a show master státusz normális.
a mysql> bináris naplókat mutat; Üres készlet (0.00 sec)mysql> show master status;
+------------------+-----------+--------------+------------------+
| Fájl | Pozíció | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Ok-elemzés
Miután megnéztem a mysql-bin.index fájlt, megtaláltam az első üres sort.
A mysql forráskódban rpl_master.cc:show_binlogs() a következő kódot találod:
/* The file ends with EOF or empty line */
míg ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Az üres sorokat a dokumentum végének tekintik
(Hivatkozás.)https://yq.aliyun.com/articles/213657Cikk)
Megelőző intézkedések
Ne töröld kézzel a binlogot, ne szerkessze kézzel a mysql-bin.index fájlt, hacsak nem tudod, mit csinálsz, különben magadnak kell bányákat rakni!
összefoglalás
A DBA-knak odafigyelniük kell a binlog fejlesztéseire minden új MySQL verzióban (például az 5.6-os verzióban hozzáadott gtid funkcióra, az 5.7-es verzióban hozzáadott Enhanced Multi-threaded Slaves-re), és részletesen meg kell érteniük minden paraméter jelentését, hogy tudják, mit jelentenek, ha hibákkal találkoznak, és könnyen megoldják a problémákat.
|
Közzétéve 2018. 09. 25. 10:31:40
|
|
|
|
