Nelle architetture ad alta disponibilità MySQL, la replica primaria di database è un tipo molto comune.
Quando il database primario si disattiva, puoi aggiornare un database slave come nuovo database primario per garantire la disponibilità del servizio. Allo stesso tempo, il QPS dell'intero cluster può essere migliorato estendendo la libreria degli slave.
Nell'architettura di replicazione master-slave, MySQL utilizza binlog per ottenere coerenza dei dati master-slave.
Come mostrato nella figura sopra, la replica master-slave di MySQL prevede principalmente i seguenti passaggi
1. il master registra le modifiche al log binario
2. Lo slave io_thread richiedere il binlog della libreria principale e scrivere il binlog risultante nel relay log
3. Eventi di ripetizione sql_thread schiavo nel registro del rilancio
Oltre a essere un collegamento per la replica master-slave di MySQL, binlog serve anche ad altri scopi. Come cosa:
1. Utilizzare lo strumento mysqlbinlog per analizzare il file binlog e effettuare il recupero puntuale del database.
2. Flashback del database basato su eventi binlog (MariaDB può usare direttamente mysqlbinlog per il flashback)
3. Lo strumento open source online di modifica tabelle gh-ost di Github è implementato anche tramite binlog
4. Puoi anche iscriverti e consumare incrementalmente analizzando i binlog
Binlog è molto utile, ma è inevitabile che incontri qualche problema nel processo quotidiano di gestione e manutenzione. Ecco alcuni errori legati ai binlog.
Una delle domande più frequenti
Fenomeno
MySQLBINLOG5.5 analizza il file binlog MySQL5.7 Compare
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.
Analisi della causa
MySQL 5.6 e altre versioni superiori dei file binlog hanno aggiunto nuovi eventi binlog, come gli eventi GTID.
MySQLBINlog in MySQL5.5 non riconosce tali eventi binlog.
Soluzione alternativa
Usa la versione superiore di mysqlbinlog per risolvere il binlog generato dalla versione inferiore di mysql
Domanda frequente due
Fenomeno
Appare uno stato di schiavo sano per server mysql
Last_SQL_Error: Errore della lettura del log del relè: Non è stato possibile analizzare l'ingresso dell'evento del log del relay.
Le possibili ragioni sono: il log binario del master è corrotto (puoi verificarlo eseguendo 'mysqlbinlog' sul log binario),
Il registro del relè dello schiavo è corrotto (puoi verificarlo eseguendo 'mysqlbinlog' sul registro del relè),
un problema di rete, o un bug nel codice MySQL del master o dello schiavo.
Se vuoi controllare il log binario del master o il log relè dello slave,
potrai conoscere i loro nomi emettendo 'MOSTRA LO STATUS DI SCHIAVO' su questo schiavo.
Analisi della causa
Le voci nel registro del relè non possono essere lette a causa di errori binlog nella libreria master, errori nel log di relay nella libreria slave, o problemi e bug di rete. Di solito è causato da un guasto di rete o da una pressione eccessiva sulla libreria slave, che porta a un formato errato del relay log.
Soluzione alternativa
Dopo aver trovato il momento di sincronizzazione attuale e reimpostato la sincronizzazione master-slave, verrà generato un nuovo log di relay e verrà ripristinata la sincronizzazione master-slave.
Dall'output di "mostra lo stato dello schiavo\G", trova le seguenti informazioni:
Relay_Master_Log_File: mysql-bin.002540 // Il binlogExec_Master_Log_Pos del master letto dalla libreria slave: 950583017 // Il punto di posizione che è stato eseguito sullo slave
Ferma lo slave e imposta di nuovo la sincronizzazione partendo dal file binlog che lo slave ha letto e dalla posizione eseguita.
Relay_Master_Log_File: mysql-bin.002540 // Il binlogExec_Master_Log_Pos del master letto dalla libreria slave: 950583017 // Il punto di posizione che è stato eseguito sullo slave
Domanda frequente tre
Fenomeno
Ripristina lo stato dello slave dopo errore di downtime:
Last_SQL_Error: Errore che inizializza la posizione del log del relè: errore I/O nella lettura dell'intestazione dal log binario
Last_SQL_Error: Errore nell'inizializzazione della posizione del log del relè: Binlog ha un numero magico scarso; Non è un file di log binario che può essere usato da questa versione di MySQL
Analisi della causa
Inattività, come interruzione di corrente, bruciatura della scheda madre, ecc., o spegnimento illegale, che comportano la corruzione del file del relay bin
Soluzione alternativa
Stessa domanda due.
relay_log_recovery = 1 può essere impostato anch'esso.
Quando lo slave si disattiva dalla libreria, se il relay-log è corrotto e parte del relay log non viene elaborata, il relay log viene automaticamente abbandonato e il log viene recuperato dal master, completando il recupero del relay log.
Domanda frequente quattro
Fenomeno
Appare quando si cambia master a dopo che un riavvio dalla macchina della libreria si sente
Errore (Codice 1201): Non è stato possibile inizializzare la struttura informativa master; altri messaggi di errore si trovano nel registro errore di MySQL
o
ERRORE 1872 (HY000): Slave non è riuscito a inizializzare la struttura delle informazioni del log del relay dal repository
Analisi della causa
Inattività, come interruzioni di corrente, bruciore della scheda madre, ecc., o spegnimento illegale, che danneggiano master.info o realy-log.info file
Soluzione alternativa
slave> reset slave all, cambia master in
Misure preventive
Impostazioni del profilo
relay_log_info_repository=tabella
master_info_repository=tabella
Il motore di archiviazione di MySQL 5.6.5 mysql.slave_master_info e mysql.slave_relay_log_info è impostato di default su MyISAM e devi cambiarlo al motore di archiviazione di InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabella verrà aggiornata dopo sync_master_info eventi.
mysql.slave_relay_log_info tabella verrà aggiornata con ogni commit di transazione.
Domanda frequente 5
Fenomeno
Lo slave master binlog_format originariamente un'affermazione, dopo aver cambiato il database principale binlog_format a riga, mostra lo stato dello schiavo che appare dalla libreria:
Last_Error: Errore nell'esecuzione dell'evento di riga: 'Non è possibile eseguire l'istruzione: impossibile scrivere nel log binario poiché l'istruzione è in formato riga e BINLOG_FORMAT = ISTRUZIONE.'
Analisi della causa
Quando la binlog_format principale del database è la riga e la libreria slave binlog_format è un'istruzione, apparirà l'errore sopra.
Ma la biblioteca principale binlog_format è la dichiarazione, e la biblioteca degli schiavi binlog_format fila;
Oppure, se il binlog_format principale del database è una riga, l'errore non verrà segnalato se il binlog_format del database è misto.
Se il tuo thread SQL è effettivamente configurato con
binlog_format=STATEMENT una volta ricevuto un evento ROW, si ferma. Le
la ragione è che non sarebbe in grado di registrare quell'evento ROW in formato STATEMENTformat (a volte ci riferiamo a questo come ROW injection, che è o un
istruzione BINLOG o un evento ROW eseguito dal thread SQL dello schiavo)
Riferimento dettagliato per motivi:https://bugs.mysql.com/bug.php?id=69095
Soluzione alternativa
SCHIAVIO> SCHIAVO DI FERMO;
SCHIAVO> IMPOSTATO GLOBALE binlog_format=MISTO;
SCHIAVIO> SCHIAVO DI PARTENZA;
Domanda frequente numero 6
Fenomeno
Errore durante la sincronizzazione di mysql5.6 con mysql5.5
Last_IO_Error: Ho ricevuto l'errore fatale 1236 dal master durante la lettura dei dati dal log binario: 'Slave non può gestire gli eventi di replica con il checksum che il master è configurato per logare; il primo evento 'mysql-bin.000001' alle 4, l'ultimo evento l'ultimo l'evento è stato letto da 'mysql-bin.000001' a 120, l'ultimo byte letto da 'mysql-bin.000001' a 120.'
Analisi della causa
Per risolvere il problema che le istruzioni SQL in esecuzione sul server primario sono incoerenti con quelle che girano sul server (chiamato event corrupt) a causa di errori software e hardware o di trasmissione di rete, MySQL 5.6 aggiunge la funzione di checksum degli eventi di replica. Quando un evento viene scritto nel log binario, il checksum viene scritto anche nel log binario e, dopo che l'evento viene trasmesso allo slave attraverso la rete, viene verificato sullo slave e scritto nel log del relè dello slave. Poiché eventi e checksum vengono registrati ad ogni passaggio, possiamo rapidamente capire qual è il problema.
In mysql5.6.5 e versioni successive binlog_checksum il valore predefinito è crc32,
Il valore predefinito binlog_checksum versione precedente era nessuno
soluzione
Slave> impostato globale binlog_checksum=nessuno
Domanda frequente 7
Fenomeno
Dopo che il disco è pieno, pulisci manualmente il file binlog e il file mysql-bin.index
I log binari di mostra sono vuoti, ma lo stato di mostra il master è normale.
mysql> mostra i log binari; Set vuoto (0,00 sec)mysql> mostra lo stato master;
+------------------+-----------+--------------+------------------+
| File | Posizione | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analisi della causa
Dopo aver controllato il file mysql-bin.index, ho trovato la prima riga vuota.
Nel codice sorgente di mysql rpl_master.cc:show_binlogs() troverai il seguente codice:
/* The file ends with EOF or empty line */
mentre ((lunghezza=my_b_gets(index_file, fname, dimensione(fname))) > 1)
Le righe bianche sono considerate la fine del documento
(Riferimento.)https://yq.aliyun.com/articles/213657Articolo)
Misure preventive
Non cancellare manualmente binlog, non modificare manualmente il file mysql-bin.index, a meno che tu non sappia cosa stai facendo, altrimenti potresti piazzare miniere da solo!
sommario
I DBA devono prestare attenzione ai miglioramenti del binlog in ogni nuova versione di MySQL (come la funzione gtid aggiunta nella versione 5.6, gli Enhanced Multi-threaded Slaves nella versione 5.7) e comprendere in dettaglio il significato di ogni parametro, così da poter capire cosa intendono quando incontrano errori e risolvono facilmente i problemi.
|
Pubblicato su 25/09/2018 10:31:40
|
|
|
|
