I MySQL high-availability-arkitekturer er primær databasereplikation en meget almindelig type.
Når den primære database går ned, kan du opgradere en slave-database som en ny primær database for at sikre servicetilgængelighed. Samtidig kan QPS for hele klyngen forbedres ved at udvide slavebiblioteket.
Under master-slave replikationsarkitekturen bruger MySQL binlog til at opnå master-slave datakonsistens.
Som vist i figuren ovenfor har MySQL master-slave replikation hovedsageligt følgende trin
1. master logger ændringerne til den binære log
2. Slaven io_thread anmode om binloggen fra hovedbiblioteket og skrive den resulterende binloglog til relæloggen
3. Lav sql_thread gentag begivenheder i relæloggen
Ud over at være et link til MySQL master-slave replikering tjener binlog også andre formål. Som hvad:
1. Brug mysqlbinlog-værktøjet til at parse binlog-filen for at udføre punkt-i-tid databasegendannelse.
2. Flashback af databasen baseret på binlog-hændelser (MariaDB kan direkte bruge mysqlbinlog til flashback)
3. Githubs open source online tabelændringsværktøj gh-ost er også implementeret via binlog
4. Du kan også inkrementelt abonnere og forbruge ved at parse binlogs
BLogg er så nyttigt, men det er uundgåeligt, at du vil støde på problemer i den daglige drift og vedligeholdelsesproces. Her er nogle fejl relateret til binlog.
Et af de ofte stillede spørgsmål
Fænomen
MySQLBinlog5.5 parser MySQL5.7 Binlog-filen appears appears
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.
Årsagsanalyse
MySQL 5.6 og andre højere versioner af binlog-filer har tilføjet nye binlog-hændelser, såsom GTID-begivenheder.
MySQLBinlog i MySQL5.5 genkender ikke sådanne Binlog-hændelser.
Workaround
Brug den højere version af mysqlbinlog til at løse binloggen, der genereres af den lavere version af mysql
Ofte stillede spørgsmål to
Fænomen
En sund Mysql-server viser slavestatus vises
Last_SQL_Error:Relay log read failure failure: Kunne ikke parse relay log event entry.
De mulige årsager er: masterens binære log er korrupt (du kan tjekke dette ved at køre 'mysqlbinlog' på den binære log),
Slavens relælog er korrupt (du kan tjekke dette ved at køre 'mysqlbinlog' på relæloggen),
et netværksproblem eller en fejl i masterens eller slavens MySQL-kode.
Hvis du vil tjekke masterens binære log eller slavens relælog,
du vil kunne kende deres navne ved at udstede 'VIS SLAVESTATUS' på denne slave.
Årsagsanalyse
Posterne i relæloggen kan ikke læses på grund af binlogfejl i masterbiblioteket, relælogfejl i slavebiblioteket eller netværksproblemer og fejl. Det skyldes som regel en netværksfejl eller overdreven belastning på slavebiblioteket, hvilket resulterer i et forkert relæ-log-format.
Workaround
Efter at have fundet det aktuelle synkroniseringstidspunkt og nulstillet master-slave synkroniseringen, vil en ny relælog blive genereret, og master-slave-synkroniseringen vil blive genoprettet.
Fra outputtet "vis slave status\G" finder du følgende information:
Relay_Master_Log_File: mysql-bin.002540 // Masters binlogExec_Master_Log_Pos læst af slavebiblioteket: 950583017 // Positionspositionspunktet, der er udført på slaven
Stop slaven og sæt synkroniseringen igen, startende fra binlog-filen, som slaven har læst, og den position, der er blevet udført.
Relay_Master_Log_File: mysql-bin.002540 // Masters binlogExec_Master_Log_Pos læst af slavebiblioteket: 950583017 // Positionspositionspunktet, der er udført på slaven
Ofte stillede spørgsmål tre
Fænomen
Genopfør visning slave-status efter nedetid-fejl:
Last_SQL_Error: Fejl ved initialisering af relælogposition: I/O-fejl ved aflæsning af headeren fra den binære log
Last_SQL_Error: Fejl ved initialisering af relælogens logposition: Binlog har et dårligt magisk tal; Det er ikke en binær logfil, som kan bruges af denne version af MySQL
Årsagsanalyse
Nedetid, såsom strømsvigt, bundkortbrænding osv., eller ulovlig nedlukning, hvilket resulterer i korruption af relæ-bin-filen
Workaround
Samme spørgsmål to.
relay_log_recovery = 1 kan også sættes.
Når slaven går ned fra biblioteket, hvis relæ-loggen er korrupt og en del af relæloggen ikke behandles, bliver relæloggen automatisk opgivet, og logen hentes tilbage fra masteren, hvilket fuldender genoprettelsen af relæloggen.
Ofte stillede spørgsmål fire
Fænomen
Dukker op, når man skifter master til efter en genstart fra biblioteksmaskinen går ned
Fejl (kode 1201): Kunne ikke initialisere master info-strukturen; flere fejlmeddelelser kan findes i MySQL-fejlloggen
eller
FEJL 1872 (HY000): Slave kunne ikke initialisere relæloginfo-strukturen fra repositoryet
Årsagsanalyse
Nedetid, såsom strømsvigt, brændende bundkort osv., eller ulovlig nedlukning, der forårsager skade på master.info eller realy-log.info filer
Workaround
slave> nulstillet slave alle, skift master til
Forebyggende tiltag
Profilindstillinger
relay_log_info_repository=tabel
master_info_repository=tabel
Lagringsmotoren i MySQL 5.6.5 mysql.slave_master_info og mysql.slave_relay_log_info er sat til MyISAM som standard, og du skal ændre den til lagringsmotoren i InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabel vil blive opdateret efter sync_master_info begivenheder.
mysql.slave_relay_log_info tabel vil blive opdateret med hver transaktionscommit.
Ofte stillede spørgsmål 5
Fænomen
Master slave binlog_format oprindeligt en sætning, efter at have ændret hoveddatabasen binlog_format til række, vises slavestatus fra biblioteket:
Last_Error: Fejl ved udførelse af rækkebegivenhed: 'Kan ikke udføre sætningen: umulig at skrive til binær log, da sætningen er i rækkeformat og BINLOG_FORMAT = SÆTNING.'
Årsagsanalyse
Når hoveddatabasen binlog_format er række, og slavebiblioteket binlog_format is-sætningen, vil ovenstående fejl vises.
Men hovedbiblioteket binlog_format er erklæring, og slavebiblioteket binlog_format række;
Eller hvis hoveddatabasen binlog_format er række, vil fejlen ikke blive rapporteret, hvis databasen binlog_format er blandet.
Hvis din SQL-tråd faktisk er konfigureret med
binlog_format=STATEMENT: Når den modtager en ROW-hændelse, stopper den. Den
årsagen er, at den ikke ville kunne logge den ROW-hændelse i STATEMENTformat (nogle gange kalder vi dette ROW-injektion, hvilket enten er en
BINLOG-sætningen eller en ROW-begivenhed, der udføres af slavens SQL-tråd)
Detaljeret begrundelsesreference:https://bugs.mysql.com/bug.php?id=69095
Workaround
SLAVE> STOP SLAVE;
SLAVE> SÆT GLOBAL binlog_format=BLANDET;
SLAVE> START SLAVE;
Ofte stillede spørgsmål nummer 6
Fænomen
Fejl ved synkronisering af mysql5.6 til mysql5.5
Last_IO_Error: Fik fatal fejl 1236 fra masteren ved læsning af data fra binær log: 'Slave kan ikke håndtere replikationshændelser med kontrolsummen, som masteren er konfigureret til at logge; den første begivenhed 'mysql-bin.000001' kl. 4, den sidste begivenhed læst fra 'mysql-bin.000001' kl. 120, den sidste byte læst fra 'mysql-bin.000001' kl. 120.'
Årsagsanalyse
For at løse problemet med, at SQL-sætningerne, der kører på den primære server, er inkonsistente med SQL-sætningerne på serveren (kaldet event-korrupte) på grund af software- og hardware- eller netværkstransmissionsfejl, tilføjer MySQL 5.6 funktionen Replication Event Checksum. Når en begivenhed skrives til den binære log, skrives checksum også til den binære log, og efter at begivenheden er sendt til slaven gennem netværket, verificeres den på slaven og skrives til slavens relælog. Da begivenheder og checksums logges ved hvert trin, kan vi hurtigt finde ud af, hvad problemet er.
I mysql5.6.5 og senere versioner binlog_checksum standardværdien crc32,
Standardværdien binlog_checksum tidligere version var ingen
opløsning
Slave> sæt global binlog_checksum=ingen
Ofte stillede spørgsmål 7
Fænomen
Når disken er fuld, skal du manuelt rydde op i binlog-filen og filen mysql-bin.index.
Vises binære logs er tomme, men showmasterstatus er normal.
MySQL> viser binære logfiler; Tomt sæt (0,00 sek)mysql> vis masterstatus;
+------------------+-----------+--------------+------------------+
| Fil | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Årsagsanalyse
Efter at have tjekket filen mysql-bin.index, fandt jeg den første tomme linje.
I mysql-kildekoden rpl_master.cc:show_binlogs() finder du følgende kode:
/* The file ends with EOF or empty line */
mens ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Blanke linjer betragtes som slutningen af dokumentet
(Reference.)https://yq.aliyun.com/articles/213657Artikel)
Forebyggende tiltag
Slet ikke binlog manuelt, rediger ikke manuelt mysql-bin.index-filen, medmindre du ved, hvad du laver, ellers kan du risikere at lægge miner for dig selv!
resumé
DBA'er skal være opmærksomme på forbedringerne i binlog i hver ny version af MySQL (såsom gtid-funktionen tilføjet i version 5.6, Enhanced Multi-threaded Slaves i version 5.7), og forstå betydningen af hver parameter i detaljer, så de kan vide, hvad de mener, når de støder på fejl, og nemt løse problemer.
|
Opslået på 25/09/2018 10.31.40
|
|
|
|
