I MySQL-arkitekturer med høy tilgjengelighet er primær databasereplikering en svært vanlig type.
Når primærdatabasen går ned, kan du oppgradere en slavedatabase til en ny primærdatabase for å sikre tjenestetilgjengelighet. Samtidig kan QPS for hele klyngen forbedres ved å utvide slavebiblioteket.
Under master-slave-replikasjonsarkitekturen bruker MySQL binlog for å oppnå konsistens mellom master-slave data.
Som vist i figuren ovenfor, har MySQL master-slave-replikering hovedsakelig følgende trinn
1. Master logger endringene i den binære loggen
2. Slaven io_thread be om binloggen til hovedbiblioteket og skrive den resulterende binlogloggen til reléloggen
3. Slave sql_thread gjøre om hendelser i reléloggen
I tillegg til å være en lenke for MySQL master-slave-replikasjon, tjener binlog også andre formål. Som hva:
1. Bruk verktøyet mysqlbinlog til å analysere binlog-filen for å utføre punkt-i-tid databasegjenoppretting.
2. Tilbakeblikk av databasen basert på binlog-hendelser (MariaDB kan direkte bruke mysqlbinlog for tilbakeblikk)
3. Githubs åpne nettbaserte tabellendringsverktøy gh-ost er også implementert gjennom binlog
4. Du kan også inkrementelt abonnere og konsumere ved å analysere binlogger
BLogg er veldig nyttig, men det er uunngåelig at du vil støte på noen problemer i den daglige driften og vedlikeholdsprosessen. Her er noen binlog-relaterte feil.
Et av de mest stilte spørsmålene
Fenomen
MySQLBinlog5.5 parser MySQL5.7 Binlog-filen 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.
Årsaksanalyse
MySQL 5.6 og andre høyere versjoner av binlog-filer har lagt til nye binlog-hendelser, som GTID-hendelser.
MySQLBINLOG i MySQL5.5 gjenkjenner ikke slike Binlog-hendelser.
Løsningsløsning
Bruk den høyere versjonen av mysqlbinlog for å løse binloggen generert av den lavere versjonen av mysql
Ofte stilte spørsmål to
Fenomen
En sunn mysql-server viser slavestatus vises
Last_SQL_Error:Relé-logglesing feil: Kunne ikke parse relé-logghendelsesoppføring.
De mulige årsakene er: masterens binære logg er korrupt (du kan sjekke dette ved å kjøre 'mysqlbinlog' på den binære loggen),
Slavens relélogg er korrupt (du kan sjekke dette ved å kjøre 'mysqlbinlog' på reléloggen),
et nettverksproblem, eller en feil i masterens eller slavens MySQL-kode.
Hvis du vil sjekke masterens binære logg eller slavens relélogg,
du vil kunne kjenne navnene deres ved å skrive 'VIS SLAVESTATUS' på denne slaven.
Årsaksanalyse
Oppføringene i reléloggen kan ikke leses på grunn av binlog-feil i masterbiblioteket, reléloggfeil i slavebiblioteket, eller nettverksproblemer og feil. Det skyldes vanligvis en nettverksfeil eller overdreven belastning på slavebiblioteket, noe som resulterer i et feil relé-loggformat.
Løsningsløsning
Etter å ha funnet det nåværende synkroniseringstidspunktet og tilbakestilt master-slave-synkroniseringen, vil en ny relélogg bli generert og master-slave-synkroniseringen vil bli gjenopprettet.
Fra utdataene til "show slave status\G" finner du følgende informasjon:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos av master lest av slavebiblioteket: 950583017 // Posisjonsposisjonspunktet som er utført på slaven
Stopp slaven og sett synkroniseringen på nytt, med start fra binlog-filen slaven har lest og posisjonen som er utført.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos av master lest av slavebiblioteket: 950583017 // Posisjonsposisjonspunktet som er utført på slaven
Ofte stilt spørsmål tre
Fenomen
Gjenoppretting visning slave-status etter nedetid-feil:
Last_SQL_Error: Feil ved initialisering av reléloggposisjon: I/O-feil ved lesing av headeren fra den binære loggen
Last_SQL_Error: Feil ved initialisering av reléloggposisjon: Binlog har dårlig magisk tall; Det er ikke en binær loggfil som kan brukes av denne versjonen av MySQL
Årsaksanalyse
Nedetid, som strømbrudd, brenning av hovedkortet, osv., eller ulovlig nedstengning, som resulterer i korrupsjon av relé-bin-filen
Løsningsløsning
Samme spørsmål nummer to.
relay_log_recovery = 1 kan også sattes.
Når slaven går ned fra biblioteket, hvis reléloggen er korrupt og deler av reléloggen ikke blir behandlet, blir reléloggen automatisk forlatt, og loggen hentes tilbake fra masteren, noe som fullfører gjenopprettingen av reléloggen.
Ofte stilt spørsmål fire
Fenomen
Dukker opp når jeg bytter master til etter at en omstart fra bibliotekmaskinen går ned
Feil (kode 1201): Kunne ikke initialisere master info-strukturen; flere feilmeldinger finnes i MySQL-feilloggen
eller
FEIL 1872 (HY000): Slave klarte ikke å initialisere relélogginfostrukturen fra repositoriet
Årsaksanalyse
Nedetid, som strømbrudd, brennende hovedkort, osv., eller ulovlig nedstengning som kan skade master.info eller realy-log.info filer
Løsningsløsning
slave> tilbakestill slave alle, bytt master til
Forebyggende tiltak
Profilinnstillinger
relay_log_info_repository=tabell
master_info_repository=tabell
Lagringsmotoren i MySQL 5.6.5 mysql.slave_master_info og mysql.slave_relay_log_info er satt til MyISAM som standard, og du må endre den til lagringsmotoren i InnoDB
ENDRE TABELL mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabellen vil bli oppdatert etter sync_master_info hendelser.
mysql.slave_relay_log_info tabellen vil bli oppdatert for hver transaksjonscommit.
Ofte stilt spørsmål 5
Fenomen
Master slave binlog_format opprinnelig en setning, etter å ha endret hoveddatabasen binlog_format til rad, vises slavestatus fra biblioteket:
Last_Error: Feil under rad-utførelse: 'Kan ikke kjøre setning: umulig å skrive til binær logg siden setningen er i radformat og BINLOG_FORMAT = SETNING.'
Årsaksanalyse
Når hoveddatabasen binlog_format er rad, og slavebiblioteket binlog_format is-setningen, vil feilen ovenfor vises.
Men hovedbiblioteket binlog_format er statement, og slavebiblioteket binlog_format rad;
Eller hvis hoveddatabasen binlog_format er rad, vil feilen ikke bli rapportert hvis databasens binlog_format er blandet.
Hvis SQL-tråden din faktisk er konfigurert med
binlog_format=STATEMENT: Når den mottar en ROW-hendelse, stopper den. Den
grunnen er at den ikke vil kunne logge den ROW-hendelsen i STATEMENTformat (noen ganger kaller vi dette ROW-injeksjon, som enten er en
BINLOG-setningen eller en ROW-hendelse utført av slavens SQL-tråd)
Detaljert grunnreferanse:https://bugs.mysql.com/bug.php?id=69095
Løsningsløsning
SLAVE> STOPP SLAVE;
SLAVE> SETT GLOBAL binlog_format=BLANDET;
SLAVE> START SLAVE;
Ofte stilt spørsmål nummer 6
Fenomen
Feil ved synkronisering av mysql5.6 til mysql5.5
Last_IO_Error: Fikk fatal feil 1236 fra master ved lesing av data fra binær logg: 'Slave kan ikke håndtere replikasjonshendelser med sjekksummen som masteren er konfigurert til å logge; den første hendelsen 'mysql-bin.000001' på 4, den siste hendelsen lest fra 'mysql-bin.000001' på 120, siste byte lest fra 'mysql-bin.000001' på 120.'
Årsaksanalyse
For å løse problemet med at SQL-setningene som kjører på primærserveren er inkonsistente med SQL-setningene som kjører på serveren (kalt event corrupt) på grunn av programvare- og maskinvare- eller nettverksoverføringsfeil, legger MySQL 5.6 til funksjonen Replication Event Checksum. Når en hendelse skrives til den binære loggen, skrives sjekksummen også til den binære loggen, og etter at hendelsen er sendt til slaven gjennom nettverket, verifiseres den på slaven og skrives til slavens relélogg. Siden hendelser og sjekksummer loggføres ved hvert steg, kan vi raskt finne ut hva problemet er.
I mysql5.6.5 og senere versjoner binlog_checksum standardverdien crc32,
Standardverdien binlog_checksum forrige versjon var ingen
løsning
Slave> sett global binlog_checksum=ingen
Ofte stilte spørsmål 7
Fenomen
Når disken er full, rydd manuelt opp binlog-filen og filen mysql-bin.index
Vises binære logger er tomme, men masterstatusen er normal.
MySQL> vise binære logger; Tomt sett (0,00 sek)mysql> vis masterstatus;
+------------------+-----------+--------------+------------------+
| Fil | Posisjon | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Årsaksanalyse
Etter å ha sjekket filen mysql-bin.index, fant jeg den første tomme linjen.
I mysql-kildekoden rpl_master.cc:show_binlogs() finner 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 regnes som slutten av dokumentet
(Referanse.)https://yq.aliyun.com/articles/213657Artikkel)
Forebyggende tiltak
Ikke slett binlog manuelt, ikke rediger mysql-bin.index-filen manuelt, med mindre du vet hva du gjør, ellers kan det hende du legger ut miner for deg selv!
sammendrag
DBA-er må være oppmerksomme på forbedringene for binlogg i hver ny versjon av MySQL (som gtid-funksjonen lagt til i versjon 5.6, Enhanced Multi-threaded Slaves i versjon 5.7), og forstå betydningen av hver parameter i detalj, slik at de kan forstå hva de mener når de støter på feil og løse problemer enkelt.
|
Publisert på 25.09.2018 10:31:40
|
|
|
|
