In MySQL high-availability architecturen is primaire databasereplicatie een zeer gebruikelijk type.
Wanneer de primaire database uitvalt, kun je een slave-database upgraden als een nieuwe primaire database om de beschikbaarheid van de service te waarborgen. Tegelijkertijd kan de QPS van het gehele cluster worden verbeterd door de slave-bibliotheek uit te breiden.
Onder de master-slave replicatiearchitectuur gebruikt MySQL binlog om consistentie tussen master-slave data te bereiken.
Zoals te zien is in de bovenstaande figuur, heeft MySQL master-slave replicatie voornamelijk de volgende stappen
1. Master logt de wijzigingen in het binaire logboek
2. De slave io_thread de binlog van de hoofdbibliotheek aanvragen en het resulterende binloglog naar het relaislog schrijven
3. Slave sql_thread gebeurtenissen in het relaislogboek opnieuw doen
Naast het zijn van een link voor MySQL master-slave replicatie, dient binlog ook andere doelen. Zoals wat:
1. Gebruik de mysqlbinlog-tool om het binlog-bestand te parsen en point-in-time databaseherstel uit te voeren.
2. Flashback van de database gebaseerd op binlog-gebeurtenissen (MariaDB kan mysqlbinlog direct gebruiken voor flashbacks)
3. Github's open-source online tabelwijzigingstool gh-ost is ook geïmplementeerd via binlog
4. Je kunt ook incrementeel abonneren en consumeren door binlogs te parsen
BLogg is zo handig, maar het is onvermijdelijk dat je problemen zult tegenkomen in het dagelijkse bedrijfs- en onderhoudsproces. Hier zijn enkele fouten gerelateerd aan binlog.
Een van de veelgestelde vragen
Fenomeen
mysqlbinlog5.5 parseert het mysql5.7 binlog-bestand 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.
Oorzaakanalyse
MySQL 5.6 en andere hogere versies van binlogbestanden hebben nieuwe binlog-gebeurtenissen toegevoegd, zoals GTID-gebeurtenissen.
MySQLBinlog in MySQL5.5 herkent dergelijke Binlog-gebeurtenissen niet.
Workaround
Gebruik de hogere versie van mysqlbinlog om de binlog die door de lagere versie van MySQL wordt gegenereerd op te lossen
Veelgestelde vraag twee
Fenomeen
Een gezonde mysql-server toont slave-status verschijnt
Last_SQL_Error:Relay-log leesfout: Kon de relayloggebeurtenis-invoer niet parsen.
De mogelijke redenen zijn: het binaire log van de master is beschadigd (je kunt dit controleren door 'mysqlbinlog' op het binaire logboek te draaien),
Het relaislogboek van de slave is beschadigd (je kunt dit controleren door 'mysqlbinlog' op het relaislogboek te draaien),
een netwerkprobleem, of een bug in de MySQL-code van de master of slaaf.
Als je het binaire log van de master of het slave-relaislogboek wilt controleren,
je kunt hun namen kennen door 'SHOW SLAVE STATUS' op deze slaaf te zetten.
Oorzaakanalyse
De vermeldingen in het relaislogboek kunnen niet worden gelezen vanwege binlogfouten in de masterbibliotheek, relaylogfouten in de slave-bibliotheek, of netwerkproblemen en bugs. Dit wordt meestal veroorzaakt door een netwerkstoring of overmatige druk op de slave-bibliotheek, wat resulteert in een onjuist relay-log-formaat.
Workaround
Na het vinden van het huidige synchronisatietijdpunt en het resetten van de master-slave synchronisatie, wordt een nieuw relaislog gegenereerd en wordt de master-slave synchronisatie hersteld.
Uit de output van "show slave status\G" vind je de volgende informatie:
Relay_Master_Log_File: mysql-bin.002540 // De binlogExec_Master_Log_Pos van de master gelezen door de slave-bibliotheek: 950583017 // Het positiepositiepunt dat op de slave is uitgevoerd
Stop de slave en stel de synchronisatie opnieuw in, beginnend vanaf het binlog-bestand dat de slave heeft gelezen en de positie die is uitgevoerd.
Relay_Master_Log_File: mysql-bin.002540 // De binlogExec_Master_Log_Pos van de master gelezen door de slave-bibliotheek: 950583017 // Het positiepositiepunt dat op de slave is uitgevoerd
Veelgestelde vraag drie
Fenomeen
Restore show slave status na downtime fout:
Last_SQL_Error: Fout bij initialisatie van de positie van relaislogs: I/O-fout bij het lezen van de header uit het binaire logboek
Last_SQL_Error: Fout initialiseren van relaislogpositie: Binlog heeft een slecht magisch getal; Het is geen binair logbestand dat door deze versie van MySQL gebruikt kan worden
Oorzaakanalyse
Uitvaltijd, zoals stroomuitval, doorbrandend moederbord, enzovoort, of illegale uitschakeling, wat resulteert in corruptie van het relais-binbestand
Workaround
Zelfde vraag twee.
relay_log_recovery = 1 kan ook worden ingesteld.
Wanneer de slave uit de bibliotheek wordt gehaald, en het relais-log is beschadigd en een deel van het relais-log niet wordt verwerkt, wordt het relais-log automatisch verlaten en wordt het logboek teruggehaald van de master, waarmee het herstel van het relais-log wordt voltooid.
Veelgestelde vraag vier
Fenomeen
Verschijnt wanneer de master wordt gewijzigd naar na een herstart vanaf de bibliotheekmachine die uitvalt
Fout (Code 1201): Kon de master info-structuur niet initialiseren; meer foutmeldingen zijn te vinden in het MySQL-foutlogboek
of
FOUT 1872 (HY000): Slave slaagde er niet in de relay log info-structuur te initialiseren vanuit de repository
Oorzaakanalyse
Uitvaltijd, zoals stroomuitval, doorbrandend moederbord, enzovoort, of illegale uitschakeling die schade veroorzaakt aan master.info of realy-log.info bestanden
Workaround
Slave> Slave alles resetten, master veranderen naar
Preventieve maatregelen
Profielinstellingen
relay_log_info_repository=tabel
master_info_repository=tabel
De opslagengine van MySQL 5.6.5 mysql.slave_master_info en mysql.slave_relay_log_info staat standaard op MyISAM, en je moet deze veranderen naar de opslagengine van InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabel wordt bijgewerkt na sync_master_info gebeurtenissen.
mysql.slave_relay_log_info tabel wordt bijgewerkt bij elke transactiecommit.
Veelgestelde vraag 5
Fenomeen
De master slave binlog_format oorspronkelijk een statement, na het wijzigen van de hoofddatabase binlog_format naar rij, verschijnt de slave-status uit de bibliotheek:
Last_Error: Fout bij uitvoerende rijgebeurtenis: 'Kan niet uitvoeren statement: onmogelijk te schrijven naar binaire log omdat de instructie in rijformaat is en BINLOG_FORMAT = STATEMENT.'
Oorzaakanalyse
Wanneer de hoofddatabase binlog_format rij is, en de slave-bibliotheek binlog_format is-instructie, zal bovenstaande fout verschijnen.
Maar de hoofdbibliotheek binlog_format is statement, en de slavenbibliotheek binlog_format rij;
Of als de hoofddatabase binlog_format rij is, wordt de fout niet gerapporteerd als de database binlog_format gemengd is.
Als je SQL-thread inderdaad is geconfigureerd met
binlog_format=STATEMENT zodra het een ROW-event ontvangt, stopt het. De
de reden is dat het dat ROW-event niet in STATEMENTformat kan loggen (soms noemen we dit ROW-injectie, wat ofwel een
BINLOG-instructie of een ROW-gebeurtenis uitgevoerd door de SQL-thread van de slave)
Gedetailleerde redenenverwijzing:https://bugs.mysql.com/bug.php?id=69095
Workaround
SLAVE> STOP SLAVE;
SLAVE> SET GLOBAL binlog_format=GEMENGD;
SLAVE> BEGIN SLAVE;
Veelgestelde vraag nummer 6
Fenomeen
Fout bij het synchroniseren van mysql5.6 met mysql5.5
Last_IO_Error: Kreeg fatale fout 1236 van master bij het lezen van data uit binaire log: 'Slave kan replicatie-evenementen niet verwerken met de checksum die master is ingesteld om te loggen; Het eerste event 'MySQL-bin.000001' op 4, het laatste event gelezen van 'MySQL-bin.000001' op 120, de laatste byte gelezen van 'MySQL-bin.000001' op 120.'
Oorzaakanalyse
Om het probleem op te lossen dat de SQL-instructies die op de primaire server draaien niet consistent zijn met de SQL-instructies op de server (event corrupt genoemd) door software- en hardware- of netwerktransmissiefouten, voegt MySQL 5.6 de Replication Event Checksum-functie toe. Wanneer een gebeurtenis naar het binaire logboek wordt geschreven, wordt de checksum ook naar het binaire logboek geschreven, en nadat het event via het netwerk naar de slave is verzonden, wordt het geverifieerd op de slave en geschreven naar het relaislogboek van de slave. Omdat gebeurtenissen en checksums bij elke stap worden geregistreerd, kunnen we snel achterhalen wat het probleem is.
In mysql5.6.5 en latere versies binlog_checksum is de standaardwaarde crc32,
De standaardwaarde binlog_checksum vorige versie was nul
oplossing
Slave> verzamelde globale binlog_checksum=geen
Veelgestelde vraag 7
Fenomeen
Nadat de schijf vol is, ruim je handmatig het binlog-bestand en het mysql-bin.index-bestand op
Toon binaire logs zijn leeg, maar de master status is normaal.
MySQL> toon binaire logs; Lege set (0,00 sec)mysql> toon masterstatus;
+------------------+-----------+--------------+------------------+
| Bestand | Positie | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Oorzaakanalyse
Na het controleren van het mysql-bin.index-bestand vond ik de eerste lege regel.
In de mysql-broncode rpl_master.cc:show_binlogs() vindt u de volgende code:
/* The file ends with EOF or empty line */
terwijl ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Lege regels worden beschouwd als het einde van het document
(Referentie.)https://yq.aliyun.com/articles/213657Artikel)
Preventieve maatregelen
Verwijder binlog niet handmatig, bewerk het mysql-bin.index-bestand niet handmatig, tenzij je weet wat je doet, anders leg je misschien mijn voor jezelf op!
samenvatting
DBA's moeten letten op de verbeteringen van binlog in elke nieuwe versie van MySQL (zoals de gtid-functie toegevoegd in versie 5.6, Enhanced Multi-threaded Slaves in versie 5.7), en de betekenis van elke parameter in detail begrijpen, zodat ze kunnen weten wat ze bedoelen bij fouten en problemen gemakkelijk kunnen oplossen.
|
Geplaatst op 25-09-2018 10:31:40
|
|
|
|
