V arhitekturah z visoko dostopnostjo MySQL je primarna replikacija baze podatkov zelo pogosta vrsta.
Ko primarna baza podatkov ne deluje, lahko podrejeno bazo nadgradite kot novo primarno bazo, da zagotovite razpoložljivost storitev. Hkrati je mogoče izboljšati QPS celotnega grozda z razširitvijo podrejene knjižnice.
Pod arhitekturo master-slave replikacije MySQL uporablja binlog za doseganje skladnosti master-slave podatkov.
Kot je prikazano na zgornji sliki, MySQL master-slave replikacija večinoma vključuje naslednje korake
1. Glavni dnevnik beleži spremembe binarnega loga
2. Podrejena io_thread zahteva binlog glavne knjižnice in zapiše nastali binlog log v relejni dnevnik
3. Suženj sql_thread ponovi dogodke v dnevniku releja
Poleg tega, da je povezava za MySQL master-slave replikacijo, binlog služi tudi drugim namenom. Na primer kaj:
1. Uporabite orodje mysqlbinlog za razčlenitev datoteke binlog za obnovo baze podatkov v določenem trenutku.
2. Flashback baze podatkov na podlagi binlog dogodkov (MariaDB lahko neposredno uporabi mysqlbinlog za flashback)
3. Githubovo odprtokodno orodje za spreminjanje spletnih tabel gh-ost je prav tako implementirano preko binlog
4. Lahko se tudi postopoma naročite in porabite z razčlenjevanjem bilogov
Binlog je zelo uporaben, vendar je neizogibno, da boste v vsakodnevnem delovanju in vzdrževanju naleteli na težave. Tukaj je nekaj napak, povezanih z binlogom.
Ena izmed pogosto zastavljenih vprašanj
Pojav
mysqlbinlog5.5 razčlenjuje datoteko mysql5.7 binlog, ki se pojavi
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.
Analiza vzrokov
MySQL 5.6 in druge višje različice binlog datotek so dodale nove binlog dogodke, kot so GTID dogodki.
mysqlbinlog v mysql5.5 takšnih binlog dogodkov ne prepozna.
Rešitev
Uporabite višjo različico mysqlbinlog za rešitev binloga, ki ga generira nižja različica mysql
Pogosto zastavljeno drugo vprašanje
Pojav
Zdrav MySQL strežnik prikazuje status slave
Last_SQL_Error: Neuspeh pri branju dnevnika releja: Ni bilo mogoče razčleniti vnosa dnevnika releja.
Možni razlogi so: glavni binarni dnevnik je poškodovan (to lahko preverite tako, da na binarnem dnevniku zaženete 'mysqlbinlog'),
Dnevnik releja slave je poškodovan (to lahko preverite tako, da zaženete 'mysqlbinlog' na dnevniku releja),
omrežna težava ali napaka v MySQL kodi mojstra ali podrejence.
Če želite preveriti glavni binarni dnevnik ali dnevnik releja podrejenega,
Njihova imena boste lahko izvedeli z napisom 'PRIKAŽI STATUS SUŽNJA' na tem sužnju.
Analiza vzrokov
Vnosov v dnevniku releja ni mogoče prebrati zaradi napak v bilogu v glavni knjižnici, napak dnevnika releja v podrejeni knjižnici ali omrežnih težav in hroščev. Običajno je posledica okvare omrežja ali prevelikega pritiska na podrejeno knjižnico, kar povzroči napačen format relej-dnevnik.
Rešitev
Po iskanju trenutne točke sinhronizacije in ponastavitvi sinhronizacije master-slave se generira nov dnevnik releja in sinhronizacija master-slave se obnovi.
Iz izhoda »prikaži status suženja\G« poiščite naslednje informacije:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos masterja, ki ga bere podrejena knjižnica: 950583017 // Pozicijska točka, ki je bila izvedena na podrejeni
Ustavi podrejenega in nastavi sinhronizacijo znova, začni z binlog datoteko, ki jo je podrejeni prebral, in položajem, ki je bil izveden.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos masterja, ki ga bere podrejena knjižnica: 950583017 // Pozicijska točka, ki je bila izvedena na podrejeni
Pogosto zastavljeno tretje vprašanje
Pojav
Obnovitev statusa prikaza suženjstva po napaki izpada:
Last_SQL_Error: Napaka pri inicializiranju položaja relejnega dnevnika: I/O napaka pri branju glave iz binarnega dnevnika
Last_SQL_Error: Napaka pri inicializiranju položaja dnevnika releja: Binlog ima napačno magično številko; To ni binarna dnevniška datoteka, ki bi jo lahko uporabljala ta različica MySQL
Analiza vzrokov
Izpadi, kot so izpad elektrike, zgorevanje matične plošče itd., ali nezakonito izklopljanje, ki povzroči poškodbo datoteke relejnega zaboja
Rešitev
Isto vprašanje dve.
relay_log_recovery = 1 je prav tako mogoče nastaviti.
Ko podrejeni dnevnik preneha delovati iz knjižnice, če je dnevnik releja poškodovan in del dnevnika ni obdelan, se dnevnik samodejno opusti, dnevnik pa se ponovno pridobi iz glavnega dnevnika, s čimer se obnovitev dnevnika releja zaključi.
Pogosto zastavljeno četrto vprašanje
Pojav
Pojavi se, ko preklopim master na po ponovnem zagonu iz knjižničnega računalnika, ki pade
Napaka (koda 1201): Ni bilo mogoče inicializirati glavne informacijske strukture; več sporočil o napakah je mogoče najti v dnevniku napak MySQL
ali
NAPAKA 1872 (HY000): Slave ni uspel inicializirati informacijske strukture dnevnika releja iz repozitorija
Analiza vzrokov
Izpadi, kot so izpad elektrike, zažganje matične plošče itd., ali nezakonito izklopljanje, ki poškoduje master.info ali realy-log.info datoteke
Rešitev
suženj> ponastavi podrejen vse, spremeni gospodarja v
Preventivni ukrepi
Nastavitve profila
relay_log_info_repository=Tabela
master_info_repository=tabela
Pogon za shranjevanje v MySQL 5.6.5 mysql.slave_master_info in mysql.slave_relay_log_info je privzeto nastavljen na MyISAM, ki ga morate spremeniti v pogon za shranjevanje InnoDB
ALTER TABELA mysql.slave_master_info ENGINE=InnoDB;
ALTER TABELA mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabela bo posodobljena po sync_master_info dogodkih.
mysql.slave_relay_log_info tabela bo posodobljena z vsako potrditvijo transakcije.
Pogosto zastavljeno vprašanje 5
Pojav
Glavni podrejeni binlog_format prvotno stavek, po spremembi glavne baze binlog_format v vrstico se iz knjižnice prikaže status podrejenstva:
Last_Error: Napaka pri izvajanju dogodkov vrstice: 'Ni mogoče izvesti stavka: nemogoče ga je zapisati v binarni log, saj je stavek v obliki vrstice in BINLOG_FORMAT = IZJAVA.'
Analiza vzrokov
Ko je glavni binlog_format baze podatkov vrstica, in je podrejena knjižnica binlog_format stavka, se pojavi zgornja napaka.
Glavna knjižnična binlog_format je izjavna, suženjska knjižnica pa binlog_format vrsti;
Ali pa, če je glavni binlog_format baze podatkov vrstica, napaka ne bo prijavljena, če je binlog_format baze mešan.
Če je vaša SQL nit res konfigurirana z
binlog_format=IZJAVA: ko prejme dogodek VRSTICA, se ustavi. The
razlog je, da ne bi mogla zabeležiti tega ROW dogodka v STATEMENTformatu (včasih temu pravimo ROW injection, kar je bodisi
Stavek BINLOG ali dogodek ROW, ki ga izvede SQL nit podrejenega uporabnika)
Podrobna referenca razloga:https://bugs.mysql.com/bug.php?id=69095
Rešitev
SUŽENJ> USTAVI SUŽENJ;
SLAVE> MNOŽICA GLOBAL binlog_format=MEŠANO;
SUŽENJ> ZAČNI SUŽENJ;
Pogosto zastavljeno vprašanje številka 6
Pojav
Napaka pri sinhronizaciji mysql5.6 z mysql5.5
Last_IO_Error: Prejel sem usodno napako 1236 od masterja pri branju podatkov iz binarnega dnevnika: 'Slave ne more obravnavati replikacijskih dogodkov s kontrolno vsoto, ki je master konfigurirana za beleženje; Prvi dogodek 'mysql-bin.000001' pri 4, zadnji dogodek prebran od 'mysql-bin.000001' pri 120, zadnji bajt prebran od 'mysql-bin.000001' pri 120.'
Analiza vzrokov
Da bi rešili težavo, da so SQL stavki, ki tečejo na primarnem strežniku, neskladni s SQL stavki, ki tečejo na strežniku (imenovani event damaged) zaradi napak programske in strojne opreme ali omrežnega prenosa, MySQL 5.6 doda funkcijo kontrolne vsote dogodkov replikacije. Ko se dogodek zapiše v binarni dnevnik, se kontrolna vsota zapiše tudi v binarni dnevnik, nato pa, ko je dogodek prenesen podrejeni prek omrežja, se preveri na podrejeni in zapiše v njegov relejni dnevnik. Ker se dogodki in kontrolne vsote beležijo na vsakem koraku, lahko hitro ugotovimo, v čem je težava.
V različicah mysql5.6.5 in novejših binlog_checksum je privzeta vrednost crc32,
Privzeta vrednost binlog_checksum prejšnji različici ni bila
rešitev
Suženj> množica globalna binlog_checksum=nič
Pogosto zastavljeno vprašanje 7
Pojav
Ko je disk poln, ročno očistite datoteko binlog in datoteko mysql-bin.index
Prikaz binarnih dnevnikov je prazen, vendar je status mojstra prikaza normalen.
mysql> prikaži binarne dnevnike; Prazen nabor (0,00 sek)mysql> prikaži status mojstra;
+------------------+-----------+--------------+------------------+
| Datoteka | Položaj | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analiza vzrokov
Po pregledu datoteke mysql-bin.index sem našel prvo prazno vrstico.
V izvorni kodi mysql rpl_master.cc:show_binlogs() boste našli naslednjo kodo:
/* The file ends with EOF or empty line */
medtem ko ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Prazne vrstice se štejejo za konec dokumenta
(Referenca.)https://yq.aliyun.com/articles/213657Članek)
Preventivni ukrepi
Ne briši ročno binloga, ne urejaj ročno datoteke mysql-bin.index, razen če veš, kaj počneš, sicer si lahko sam postavljaš mine!
Povzetek
DBA-ji morajo biti pozorni na izboljšave binloga v vsaki novi različici MySQL (kot je funkcija gtid, dodana v različici 5.6, izboljšani večnitni podrejeni v različici 5.7) in podrobno razumeti pomen vsakega parametra, da bodo vedeli, kaj pomenijo, ko naletijo na napake in enostavno rešujejo težave.
|
Objavljeno na 25. 09. 2018 10:31:40
|
|
|
|
