I MySQL-arkitekturer med hög tillgänglighet är primär databasreplikering en mycket vanlig typ.
När primärdatabasen går ner kan du uppgradera en slavdatabas till en ny primär databas för att säkerställa tillgängligheten av tjänster. Samtidigt kan QPS:erna för hela klustret förbättras genom att utöka slavbiblioteket.
Under master-slave-replikationsarkitekturen använder MySQL binlog för att uppnå master-slave-datakonsistens.
Som visas i figuren ovan har MySQL master-slave-replikering huvudsakligen följande steg
1. master loggar ändringarna i den binära loggen
2. Slaven io_thread begära binloggen för huvudbiblioteket och skriva den resulterande binlogloggen till reläloggen
3. Slava sql_thread göra om händelser i reläloggen
Förutom att vara en länk för MySQL master-slave-replikering tjänar binlog även andra funktioner. Som vad:
1. Använd verktyget mysqlbinlog för att tolka binlog-filen för att utföra punkt-i-tid-databasåterställning.
2. Flashback av databasen baserat på binlog-händelser (MariaDB kan direkt använda mysqlbinlog för flashback)
3. Githubs öppna onlineverktyg för tabelländring gh-ost är också implementerat via binlog
4. Du kan också inkrementvis prenumerera och konsumera genom att tolka binloggar
Binlog är så användbart, men det är oundvikligt att du kommer att stöta på vissa problem i den dagliga driften och underhållet. Här är några binlog-relaterade fel.
En av de vanligaste frågorna
Fenomen
MySQLBINLOG5.5 tolkar MySQL5.7 Binlog-filen visas
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.
Orsaksanalys
MySQL 5.6 och andra högre versioner av binlogfiler har lagt till nya binlog-händelser, såsom GTID-händelser.
MySQLBinlog i MySQL5.5 känner inte igen sådana Binlog-händelser.
Lösningslösning
Använd den högre versionen av mysqlbinlog för att lösa binloggen som genereras av den lägre versionen av mysql
Ofta ställd fråga två
Fenomen
En frisk mysql-server visar slavstatus visas
Last_SQL_Error:Reläloggläsningsfel: Kunde inte tolka relälogghändelseposten.
De möjliga orsakerna är: masterns binära logg är korrupt (du kan kontrollera detta genom att köra 'mysqlbinlog' på den binära loggen).
Slavens relälogg är korrupt (du kan kontrollera detta genom att köra 'mysqlbinlog' på reläloggen).
ett nätverksproblem eller en bugg i masterns eller slavens MySQL-kod.
Om du vill kontrollera masterns binära logg eller slavars relälogg,
du kommer att kunna känna till deras namn genom att skriva 'VISA SLLAVSTATUS' på denna slav.
Orsaksanalys
Posterna i reläloggen kan inte läsas på grund av binlogfel i masterbiblioteket, reläloggfel i slavbiblioteket eller nätverksproblem och buggar. Det orsakas vanligtvis av ett nätverksfel eller överdriven belastning på slavbiblioteket, vilket resulterar i ett felaktigt reläloggformat.
Lösningslösning
Efter att den aktuella synkroniseringstidpunkten har hittats och master-slave-synkroniseringen återställts, genereras en ny relälogg och master-slave-synkroniseringen återställs.
Från utdata från "visa slavestatus\G" hittar du följande information:
Relay_Master_Log_File: mysql-bin.002540 // Masterns binlogExec_Master_Log_Pos läst av slave-biblioteket: 950583017 // Positionspositionspunkten som har körts på slaven
Stoppa slaven och ställ in synkroniseringen igen, med start från binlogfilen som slaven har läst och positionen som har exekverats.
Relay_Master_Log_File: mysql-bin.002540 // Masterns binlogExec_Master_Log_Pos läst av slave-biblioteket: 950583017 // Positionspositionspunkten som har körts på slaven
Ofta ställd fråga tre
Fenomen
Återställ visa slavstatus efter driftstopp:
Last_SQL_Error: Fel initialiserar relälogens position: I/O-fel vid läsning av headern från den binära loggen
Last_SQL_Error: Fel initialisering av reläloggposition: Binlog har ett felaktigt magiskt nummer; Det är inte en binär loggfil som kan användas av denna version av MySQL
Orsaksanalys
Driftstopp, som strömavbrott, att moderkortet brinner osv., eller olaglig avstängning, vilket leder till korruption av relä-bin-filen
Lösningslösning
Samma fråga två.
relay_log_recovery = 1 kan också sättas.
När slaven går ner från biblioteket, om reläloggen är korrupt och en del av reläloggen inte bearbetas, överges reläloggen automatiskt och loggen hämtas från mastern, vilket fullbordar återställningen av reläloggen.
Ofta ställd fråga fyra
Fenomen
Visas när man byter master till efter en omstart från biblioteksmaskinen som går ner
Fel (kod 1201): Kunde inte initiera master info-strukturen; fler felmeddelanden finns i MySQL-felloggen
eller
FEL 1872 (HY000): Slaven misslyckades med att initiera relälogginformationsstrukturen från arkivet
Orsaksanalys
Driftstopp, såsom strömavbrott, brinnande moderkort, etc., eller olaglig avstängning som orsakar skador på master.info eller realy-log.info filer
Lösningslösning
slav> återställ slav alla, byt master till
Förebyggande åtgärder
Profilinställningar
relay_log_info_repository=tabell
master_info_repository=bord
Lagringsmotorn i MySQL 5.6.5 mysql.slave_master_info och mysql.slave_relay_log_info är inställd på MyISAM som standard, och du behöver byta till lagringsmotorn i InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabell kommer att uppdateras efter sync_master_info evenemang.
mysql.slave_relay_log_info tabell uppdateras med varje transaktionscommit.
Ofta ställd fråga 5
Fenomen
Master slave binlog_format ursprungligen ett uttalande, efter att ha ändrat huvuddatabasen binlog_format till rad, visas slavstatus från biblioteket:
Last_Error: Fel som kör radhändelse: 'Kan inte köra satsen: omöjligt att skriva till binär logg eftersom satsen är i radformat och BINLOG_FORMAT = SATS.'
Orsaksanalys
När huvuddatabasen binlog_format är rad, och slavbiblioteket binlog_format is-satsen kommer ovanstående fel.
Men huvudbiblioteket binlog_format är uttalande, och slavbiblioteket binlog_format raden;
Eller om huvuddatabasen binlog_format är rad, rapporteras inte felet om databasen binlog_format är blandad.
Om din SQL-tråd faktiskt är konfigurerad med
binlog_format=STATEMENT när den tar emot en ROW-händelse kommer den att stanna. The
anledningen är att den inte skulle kunna logga den ROW-händelsen i STATEMENTformat (ibland kallar vi detta ROW-injektion, vilket antingen är en
BINLOG-satsen eller en ROW-händelse som körs av slavens SQL-tråd)
Detaljerad anledningsreferens:https://bugs.mysql.com/bug.php?id=69095
Lösningslösning
SLAV > STOPPA SLAVE;
SLAVE> SET GLOBAL binlog_format=MIXED;
SLAV > BÖRJA SLAVE;
Ofta ställd fråga nummer 6
Fenomen
Fel vid synkronisering av mysql5.6 till mysql5.5
Last_IO_Error: Fick fatal error 1236 från master när jag läste data från binär logg: 'Slave kan inte hantera replikeringshändelser med kontrollsumman som mastern är konfigurerad att logga; Den första händelsen 'MySQL-bin.000001' vid 4, den sista händelsen läst från 'MySQL-bin.000001' vid 120, sista byten läst från 'MySQL-bin.000001' vid 120.'
Orsaksanalys
För att lösa problemet att SQL-satserna som körs på primärservern är inkonsekventa med SQL-satserna som körs på servern (kallat event corrupt) på grund av mjukvaru- och hårdvaru- eller nätverksöverföringsfel, lägger MySQL 5.6 till funktionen Replication Event Checksum. När en händelse skrivs till den binära loggen skrivs kontrollsumman också till den binära loggen, och efter att händelsen har överförts till slaven via nätverket verifieras den på slaven och skrivs till slavens relälogg. Eftersom händelser och kontrollsummor loggas vid varje steg kan vi snabbt lista ut vad problemet är.
I mysql5.6.5 och senare versioner binlog_checksum är standardvärdet crc32,
Standardvärdet binlog_checksum tidigare versionen var inget
lösning
Slave> set global binlog_checksum=none
Ofta ställd fråga 7
Fenomen
När disken är full, rensa manuellt binlog-filen och filen mysql-bin.index
Visa-binära loggar är tomma, men visa-masterstatusen är normal.
MySQL> visa binära loggar; Tom mängd (0,00 sek)mysql> visa masterstatus;
+------------------+-----------+--------------+------------------+
| Fil | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Orsaksanalys
Efter att ha kollat filen mysql-bin.index hittade jag den första tomma raden.
I mysql-källkoden rpl_master.cc:show_binlogs() hittar du följande kod:
/* The file ends with EOF or empty line */
medan ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Tomma rader anses vara slutet på dokumentet
(Referens.)https://yq.aliyun.com/articles/213657Artikel)
Förebyggande åtgärder
Radera inte binlog manuellt, redigera inte manuellt filen mysql-bin.index, om du inte vet vad du gör, annars kan du lägga minor åt dig själv!
sammanfattning
DBA:er behöver vara uppmärksamma på förbättringarna av binlog i varje ny version av MySQL (såsom gtid-funktionen som lades till i version 5.6, Enhanced Multi-threaded Slaves i version 5.7), och förstå betydelsen av varje parameter i detalj, så att de kan veta vad de menar när de stöter på fel och enkelt lösa problem.
|
Publicerad på 2018-09-25 10:31:40
|
|
|
|
