MySQL didelio prieinamumo architektūrose pirminė duomenų bazės replikacija yra labai paplitęs tipas.
Kai pirminė duomenų bazė neveikia, galite atnaujinti pavaldinę duomenų bazę kaip naują pirminę duomenų bazę, kad užtikrintumėte tarnybos pasiekiamumą. Tuo pačiu metu viso klasterio QPS galima patobulinti išplečiant vergų biblioteką.
Pagal master-slave replikacijos architektūrą, MySQL naudoja binlog, kad pasiektų master-slave duomenų nuoseklumą.
Kaip parodyta aukščiau esančiame paveikslėlyje, "MySQL" pagrindinio-pavaldinio replikacija daugiausia atliekama šiais veiksmais
1. Meistras registruoja dvejetainio žurnalo pakeitimus
2. Vergas io_thread paprašyti pagrindinės bibliotekos binlog ir įrašyti gautą binlog žurnalą į relės žurnalą
3. Vergų sql_thread perdaryti įvykius relės žurnale
Binlog yra ne tik MySQL master-slave replikacijos nuoroda, bet ir kitiems tikslams. Pavyzdžiui, kas:
1. Naudokite mysqlbinlog įrankį, kad išanalizuotumėte binlog failą, kad atliktumėte duomenų bazės atkūrimą laiku.
2. Duomenų bazės atkūrimas pagal binlog įvykius (MariaDB gali tiesiogiai naudoti mysqlbinlog flashback)
3. "Github" atvirojo kodo internetinis lentelės keitimo įrankis gh-ost taip pat įdiegtas per binlog
4. Taip pat galite palaipsniui užsiprenumeruoti ir vartoti analizuodami binlogs
Binlog yra toks naudingas, tačiau neišvengiama, kad kasdieniame eksploatavimo ir priežiūros procese susidursite su tam tikromis problemomis. Štai keletas su binlog susijusių klaidų.
Vienas iš dažniausiai užduodamų klausimų
reiškinys
mysqlbinlog5.5 analizuoja mysql5.7 binlog failą pasirodo
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.
Priežasties analizė
MySQL 5.6 ir kitos aukštesnės binlog failų versijos pridėjo naujų binlog įvykių, tokių kaip GTID įvykiai.
mysqlbinlog mysql5.5 neatpažįsta tokių binlog įvykių.
Sprendimo būdas
Naudokite aukštesnę mysqlbinlog versiją, kad išspręstumėte binlogą, kurį sugeneravo žemesnė mysql versija
Dažnai užduodamas antras klausimas
reiškinys
Pasirodo sveikas mysql serveris rodyti vergų būseną
Last_SQL_Error:Relės žurnalo skaitymo klaida: Nepavyko išanalizuoti relės žurnalo įvykio įrašo.
Galimos priežastys: pagrindinio dvejetainis žurnalas yra sugadintas (tai galite patikrinti paleisdami "mysqlbinlog" dvejetainiame žurnale),
vergų relės žurnalas yra sugadintas (tai galite patikrinti paleisdami "mysqlbinlog" relės žurnale),
tinklo problema arba pagrindinio ar vergo MySQL kodo klaida.
Jei norite patikrinti pagrindinio dvejetainį žurnalą arba vergo relės žurnalą,
Jų vardus galėsite sužinoti išdavę "SHOW SLAVE STATUS" šiam vergui.
Priežasties analizė
Relės žurnalo įrašų negalima perskaityti dėl binlog klaidų pagrindinėje bibliotekoje, relės žurnalo klaidų vergų bibliotekoje arba tinklo problemų ir klaidų. Paprastai tai sukelia tinklo gedimas arba per didelis spaudimas vergų bibliotekai, dėl kurio neteisingas relės žurnalo formatas.
Sprendimo būdas
Suradus dabartinį sinchronizavimo laiko tašką ir iš naujo nustačius pagrindinio-pavaldinio sinchronizavimą, bus sugeneruotas naujas relės žurnalas ir atkurtas pagrindinio-pavaldinio sinchronizavimas.
Iš "show slave status\G" išvesties raskite šią informaciją:
Relay_Master_Log_File: mysql-bin.002540 // Vergų bibliotekos skaitomas meistro binlogExec_Master_Log_Pos: 950583017 // Padėties padėties taškas, kuris buvo įvykdytas vergui
Sustabdykite vergą ir vėl nustatykite sinchronizavimą, pradedant nuo binlog failo, kurį perskaitė vergas, ir pareigų, kurios buvo įvykdytos.
Relay_Master_Log_File: mysql-bin.002540 // Vergų bibliotekos skaitomas meistro binlogExec_Master_Log_Pos: 950583017 // Padėties padėties taškas, kuris buvo įvykdytas vergui
Dažnai užduodamas trečias klausimas
reiškinys
Atkurti rodyti vergo būseną po prastovos klaidos:
Last_SQL_Error: Klaida inicijuojant relės žurnalo padėtį: Įvesties / išvesties klaida skaitant antraštę iš dvejetainio žurnalo
Last_SQL_Error: Klaida inicijuojant relės žurnalo poziciją: Binlog turi blogą magišką numerį; Tai nėra dvejetainis žurnalo failas, kurį gali naudoti ši MySQL versija
Priežasties analizė
Prastovos, pvz., elektros energijos tiekimo sutrikimas, pagrindinės plokštės degimas ir kt., arba neteisėtas išjungimas, dėl kurio sugadinamas relės dėžės failas
Sprendimo būdas
Tas pats klausimas du.
relay_log_recovery = 1 taip pat galima nustatyti.
Kai pavaldus nueina iš bibliotekos, jei relės žurnalas yra sugadintas ir dalis relės žurnalo nėra apdorojama, relės žurnalas automatiškai atsisakomas, o žurnalas vėl nuskaitomas iš pagrindinio, užbaigiant relės žurnalo atkūrimą.
Dažnai užduodamas ketvirtas klausimas
reiškinys
Pasirodo, kai keičiasi pagrindinis į po perkrovimo iš bibliotekos kompiuterio neveikia
Klaida (kodas 1201): Nepavyko inicijuoti pagrindinės informacijos struktūros; daugiau klaidų pranešimų galima rasti MySQL klaidų žurnale
arba
KLAIDA 1872 (HY000): Vergui nepavyko inicijuoti relės žurnalo informacijos struktūros iš saugyklos
Priežasties analizė
Prastovos, pvz., elektros energijos tiekimo nutraukimas, pagrindinės plokštės degimas ir kt., arba neteisėtas išjungimas, dėl kurio pažeidžiami master.info ar realy-log.info failai
Sprendimo būdas
vergas> iš naujo nustatyti vergas visi, pakeisti meistras į
Prevencinės priemonės
Profilio nustatymai
relay_log_info_repository=lentelė
master_info_repository=lentelė
MySQL 5.6.5 mysql.slave_master_info ir mysql.slave_relay_log_info saugojimo variklis pagal numatytuosius nustatymus nustatytas į MyISAM, todėl turite jį pakeisti į InnoDB saugojimo variklį
PAKEISTI LENTELĘ mysql.slave_master_info VARIKLIS=InnoDB;
PAKEISTI LENTELĘ mysql.slave_relay_log_info VARIKLIS = InnoDB;
mysql.slave_master_info lentelė bus atnaujinta po sync_master_info įvykių.
mysql.slave_relay_log_info lentelė bus atnaujinta su kiekvienu operacijos įsipareigojimu.
Dažnai užduodamas klausimas 5
reiškinys
Pagrindinis vergas binlog_format iš pradžių sakinys, pakeitus pagrindinę duomenų bazę binlog_format į eilutę, rodyti vergo būseną pasirodo iš bibliotekos:
Last_Error: Klaida vykdant eilutės įvykį: 'Neįmanoma įvykdyti sakinio: neįmanoma rašyti į dvejetainį žurnalą, nes sakinys yra eilutės formatu ir BINLOG_FORMAT = STATEMENT.'
Priežasties analizė
Kai pagrindinė duomenų bazės binlog_format yra eilutė, o vergų bibliotekos binlog_format yra sakinys, pasirodys aukščiau pateikta klaida.
Bet pagrindinė biblioteka binlog_format yra pareiškimas, o vergų biblioteka binlog_format eilėje;
Arba jei pagrindinė duomenų bazės binlog_format yra eilutė, apie klaidą nebus pranešta, jei duomenų bazės binlog_format yra mišri.
Jei jūsų SQL gija iš tiesų sukonfigūruota su
binlog_format=STATEMENT, kai tik gaus ROW įvykį, jis sustos. Į
priežastis yra ta, kad ji negalėtų užregistruoti, kad ROW įvykis STATEMENTformat (kartais mes vadiname tai kaip ROW injekcija, kuri yra arba
BINLOG sakinys arba ROW įvykis, kurį vykdo vergo SQL gija)
Išsami priežasties nuoroda:https://bugs.mysql.com/bug.php?id=69095
Sprendimo būdas
VERGAS> SUSTABDYKITE VERGĄ;
SLAVE> NUSTATYTI VISUOTINĮ binlog_format=MIŠRUS;
VERGAS> PRADĖTI VERGAS;
Dažnai užduodamas klausimas numeris 6
reiškinys
Klaida sinchronizuojant mysql5.6 su mysql5.5
Last_IO_Error: Gavau lemtingą klaidą 1236 iš meistro skaitant duomenis iš dvejetainio žurnalo: "Slave negali apdoroti replikacijos įvykių su kontroline suma, kurią pagrindinis yra sukonfigūruotas registruoti; pirmasis įvykis "mysql-bin.000001" 4, paskutinis įvykis nuskaitytas iš "mysql-bin.000001" 120, paskutinis baitas nuskaitytas iš "mysql-bin.000001" 120.
Priežasties analizė
Siekiant išspręsti problemą, kad pirminiame serveryje veikiantys SQL sakiniai neatitinka serveryje veikiančių SQL sakinių (vadinamų įvykių sugadintais) dėl programinės ir aparatinės įrangos arba tinklo perdavimo klaidų, MySQL 5.6 prideda replikacijos įvykio kontrolinės sumos funkciją. Kai įvykis įrašomas į dvejetainį žurnalą, kontrolinė suma taip pat įrašoma į dvejetainį žurnalą, o po to, kai įvykis perduodamas vergui per tinklą, jis patikrinamas verge ir įrašomas į vergo relės žurnalą. Kadangi įvykiai ir kontrolinės sumos registruojami kiekviename žingsnyje, galime greitai išsiaiškinti, kokia yra problema.
Mysql5.6.5 ir naujesnėse versijose numatytoji binlog_checksum reikšmė yra crc32,
Numatytoji reikšmė binlog_checksum ankstesnės versijos nebuvo
sprendimas
Vergas> nustatyti visuotinį binlog_checksum=none
Dažnai užduodamas klausimas 7
reiškinys
Kai diskas bus pilnas, rankiniu būdu išvalykite binlog failą ir mysql-bin.index failą
Rodyti dvejetainius žurnalus yra tušti, bet Rodyti pagrindinio būseną yra normali.
mysql> rodyti dvejetainius žurnalus; Tuščias rinkinys (0,00 sek.)mysql> rodyti pagrindinį statusą;
+------------------+-----------+--------------+------------------+
| Failas | Pareigos | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Priežasties analizė
Patikrinęs mysql-bin.index failą, radau pirmąją tuščią eilutę.
MySQL šaltinio kode rpl_master.cc:show_binlogs() rasite šį kodą:
/* The file ends with EOF or empty line */
o ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Tuščios eilutės laikomos dokumento pabaiga
(Nuoroda.)https://yq.aliyun.com/articles/213657straipsnis)
Prevencinės priemonės
Neištrinkite binlog rankiniu būdu, neredaguokite mysql-bin.index failo, nebent žinote, ką darote, kitaip galite kloti minas sau!
suvestinė
DBA turi atkreipti dėmesį į binlog patobulinimus kiekvienoje naujoje MySQL versijoje (pvz., gtid funkcija, pridėta 5.6 versijoje, Enhanced Multi-threaded Slaves 5.7 versijoje) ir išsamiai suprasti kiekvieno parametro reikšmę, kad jie galėtų žinoti, ką jie reiškia, kai susiduria su klaidomis ir lengvai išspręsti problemas.
|
Paskelbta 2018-09-25 10:31:40
|
|
|
|
