V architektúrach MySQL s vysokou dostupnosťou je primárna replikácia databázy veľmi bežným typom.
Keď primárna databáza prestane fungovať, môžete upgradovať slave databázu ako novú primárnu databázu, aby ste zabezpečili dostupnosť služieb. Zároveň je možné QPS celého klastra zlepšiť rozšírením slave knižnice.
V rámci architektúry replikácie master-slave používa MySQL binlog na dosiahnutie konzistencie dát master-slave.
Ako je znázornené na obrázku vyššie, replikácia MySQL master-slave obsahuje najmä nasledujúce kroky
1. Hlavný záznam zaznamenáva zmeny v binárnom logu
2. Slave io_thread požiadať o binlog hlavnej knižnice a zapísať výsledný binlog log do relé logu
3. Otrok sql_thread opakovať udalosti v relé logu
Okrem toho, že slúži ako odkaz na replikáciu MySQL master-slave, binlog slúži aj ďalším účelom. Napríklad čo:
1. Použite nástroj mysqlbinlog na analýzu binlog súboru na vykonanie obnovy databázy v danom čase.
2. Flashback databázy založený na binlog udalostiach (MariaDB môže priamo použiť mysqlbinlog pre flashback)
3. Githubov open-source nástroj na zmenu online tabuliek gh-ost je tiež implementovaný cez binlog
4. Môžete sa tiež postupne prihlásiť na odber a konzumovať analýzou binlogov
Binlog je veľmi užitočný, ale je nevyhnutné, že sa v každodennej prevádzke a údržbe stretnete s nejakými problémami. Tu je niekoľko chýb súvisiacich s binlogom.
Jedna z často kladených otázok
Fenomén
mysqlbinlog5.5 parsuje binlog súbor mysql5.7
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.
Analýza príčin
MySQL 5.6 a ďalšie vyššie verzie binlog súborov pridali nové binlog udalosti, ako sú GTID udalosti.
mysqlbinlog v mysql5.5 takéto binlog udalosti nerozpoznáva.
Obchádzka
Použite vyššiu verziu mysqlbinlog na vyriešenie binlogu generovaného nižšou verziou mysql
Často kladená druhá otázka
Fenomén
Zdravý MySQL server zobrazuje status slave
Last_SQL_Error: Zlyhanie čítania relé logu: Nepodarilo sa spracovať záznam relé logu.
Možné dôvody sú: binárny log mastera je poškodený (môžete to skontrolovať spustením 'mysqlbinlog' na binárnom logu),
Relay log slave je poškodený (môžete to skontrolovať spustením 'mysqlbinlog' na relay logu),
sieťový problém alebo chyba v MySQL kóde mastera či slave.
Ak chcete skontrolovať binárny log mastera alebo relay log slave,
Ich mená sa dozviete tým, že na tomto otrokovi vydáte 'ZOBRAZIŤ STATUS OTROKA'.
Analýza príčin
Záznamy v relay logu nie je možné čítať kvôli chybám binlogu v master knižnici, chybám relay logu v slave knižnici alebo sieťovým problémom a chybám. Zvyčajne je spôsobená zlyhaním siete alebo nadmerným tlakom na slave knižnicu, čo vedie k nesprávnemu formátu relé-log.
Obchádzka
Po nájdení aktuálneho synchronizačného bodu a resetovaní synchronizácie master-slave sa vygeneruje nový relé log a synchronizácia master-podriadená bude obnovená.
Z výstupu "zobraziť slave status\G" nájdete nasledujúce informácie:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera čítaný slave knižnicou: 950583017 // Bod pozície, ktorý bol vykonaný na slave
Zastavte slave a nastavte synchronizáciu znova, začínajúc binlog súborom, ktorý slave prečítal, a pozíciou, ktorá bola vykonaná.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera čítaný slave knižnicou: 950583017 // Bod pozície, ktorý bol vykonaný na slave
Často kladená tretia otázka
Fenomén
Obnovenie stavu zobraziť otroka po chybe výpadku:
Last_SQL_Error: Chyba pri inicializácii polohy relé logu: I/O chyba čítajúca hlavičku z binárneho logu
Last_SQL_Error: Chyba pri inicializácii polohy relé logu: Binlog má zlé magické číslo; Nie je to binárny log súbor, ktorý by táto verzia MySQL mohla použiť
Analýza príčin
Výpadky, ako výpadok elektriny, spálenie základnej dosky a podobne, alebo nelegálne vypnutie, ktoré vedú k poškodeniu súboru relé-bin
Obchádzka
Tá istá druhá otázka.
relay_log_recovery = 1 môže byť tiež nastavené.
Keď slave vypadne z knižnice, ak je záznam relé poškodený a časť logu relé nie je spracovaná, log relé sa automaticky opustí a záznam sa znovu získa z mastera, čím sa obnova logu relé dokončí.
Často kladená štvrtá otázka
Fenomén
Objaví sa pri zmene master na po reštarte z knižničného stroja, ktorý prestane fungovať
Chyba (kód 1201): Nepodarilo sa inicializovať hlavnú informačnú štruktúru; viac chybových hlásení možno nájsť v MySQL error log
alebo
CHYBA 1872 (HY000): Slave nedokázal inicializovať reléovú logovú informačnú štruktúru z repozitára
Analýza príčin
Výpadky, ako výpadok napájania, spálenie základnej dosky a podobne, alebo nelegálne vypnutie, ktoré poškodzujú master.info alebo realy-log.info súbory
Obchádzka
Slave> resetovať Slave všetko, zmeniť master na
Preventívne opatrenia
Nastavenia profilu
relay_log_info_repository=tabuľka
master_info_repository=tabuľka
Úložný engine MySQL 5.6.5 mysql.slave_master_info a mysql.slave_relay_log_info je predvolene nastavený na MyISAM a musíte ho zmeniť na storage engine InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabuľka bude aktualizovaná po sync_master_info podujatiach.
mysql.slave_relay_log_info tabuľka sa bude aktualizovať pri každom potvrdení transakcie.
Často kladená otázka 5
Fenomén
Hlavný slave binlog_format pôvodne príkaz, po zmene hlavnej databázovej binlog_format na riadok sa z knižnice zobrazí stav slave:
Last_Error: Chyba pri vykonávaní riadku: 'Nemožno vykonať príkaz: nie je možné zapísať do binárneho logu, keďže príkaz je vo formáte riadku a BINLOG_FORMAT = PRÍKAZ.'
Analýza príčin
Keď je hlavná databázová binlog_format riadok a podriadená knižnica binlog_format je príkaz, zobrazí sa vyššie uvedená chyba.
Ale hlavná binlog_format knižnice je statement a knižnica otrokov binlog_format rade;
Alebo ak je hlavná databázová binlog_format riadok, chyba sa nenahlási, ak je databázový binlog_format zmiešaný.
Ak je vaše SQL vlákno naozaj nakonfigurované s
binlog_format=PRÍKAZ akonáhle prijme udalosť RIADKU, zastaví sa. The
Dôvodom je, že by nebolo možné zaznamenať túto udalosť ROW vo formáte STATEMENT (niekedy to nazývame ROW injection, čo je buď
príkaz BINLOG alebo udalosť ROW vykonanú SQL vláknom slave)
Podrobný dôvod:https://bugs.mysql.com/bug.php?id=69095
Obchádzka
OTROK> ZASTAV OTROKA;
SLAVE> MNOŽINA GLOBÁLNA binlog_format=ZMIEŠANÉ;
OTROK> ZAČAŤ OTROK;
Často kladená otázka číslo 6
Fenomén
Chyba pri synchronizácii mysql5.6 s mysql5.5
Last_IO_Error: Pri čítaní dát z binárneho logu som dostal fatálnu chybu 1236 od mastera: 'Slave nemôže spracovať replikačné udalosti s kontrolným súčtom, ktorý master je nastavený na logovanie; Prvá udalosť 'mysql-bin.000001' na 4, posledná udalosť čítaná z 'mysql-bin.000001' na 120, posledný bajt z 'mysql-bin.000001' na 120.'
Analýza príčin
Aby sa vyriešil problém, že SQL príkazy bežiace na primárnom serveri sú nekonzistentné s SQL príkazmi bežiacimi na serveri (označované ako event corrupt) v dôsledku softvérových a hardvérových alebo sieťových chýb, MySQL 5.6 pridáva funkciu kontrolného súčtu replikačných udalostí. Keď sa udalosť zapíše do binárneho logu, kontrolný súčet sa tiež zapíše do binárneho logu a po odoslaní udalosti slave cez sieť sa overí na slave a zapíše do relay logu slave. Keďže udalosti a kontrolné súčty sa zaznamenávajú v každom kroku, môžeme rýchlo zistiť, v čom je problém.
V mysql5.6.5 a novších verziách binlog_checksum je predvolená hodnota crc32,
Predvolená hodnota binlog_checksum predchádzajúcej verzii bola žiadna
riešenie
Slave> nastaviť globálne binlog_checksum=žiadne
Často kladená otázka 7
Fenomén
Keď je disk plný, manuálne vyčistite binlog súbor a súbor mysql-bin.index
Zobraziť binárne logy sú prázdne, ale stav hlavného zobrazenia je normálny.
mysql> zobraziť binárne logy; Prázdna sada (0,00 sekundy)mysql> zobraziť stav mastera;
+------------------+-----------+--------------+------------------+
| Súbor | Pozícia | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analýza príčin
Po kontrole súboru mysql-bin.index som našiel prvý prázdny riadok.
V zdrojovom kóde mysql rpl_master.cc:show_binlogs() nájdete nasledujúci kód:
/* The file ends with EOF or empty line */
zatiaľ čo ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Prázdne riadky sa považujú za koniec dokumentu
(Referencia.)https://yq.aliyun.com/articles/213657Článok)
Preventívne opatrenia
Nemazajte binlog manuálne, neupravujte manuálne súbor mysql-bin.index, pokiaľ neviete, čo robíte, inak si môžete sami klásť míny!
súhrn
DBA musia venovať pozornosť zlepšeniam binlogu v každej novej verzii MySQL (napríklad funkcia gtid pridaná vo verzii 5.6, vylepšené viacvláknové slave vo verzii 5.7) a podrobne rozumieť významu každého parametra, aby vedeli, čo znamenajú, keď narazia na chyby a ľahko riešia problémy.
|
Zverejnené 25. 9. 2018 10:31:40
|
|
|
|
