În arhitecturile MySQL de înaltă disponibilitate, replicarea principală a bazei de date este un tip foarte comun.
Când baza de date principală cade, poți actualiza o bază de date slave ca nouă bază de date primară pentru a asigura disponibilitatea serviciilor. În același timp, QPS-ul întregului cluster poate fi îmbunătățit prin extinderea bibliotecii slave.
În arhitectura de replicare master-slave, MySQL folosește binlog pentru a obține consistența datelor master-slave.
Așa cum se arată în figura de mai sus, replicarea MySQL master-slave are în principal următorii pași
1. Master înregistrează modificările jurnalului binar
2. Slave-ul io_thread solicita binlog-ul bibliotecii principale și scrie binlog-ul rezultat în relay log
3. Evenimentele de refacere a sclavilor sql_thread în jurnalul de releu
Pe lângă faptul că este un link pentru replicarea master-slave MySQL, binlog servește și altor scopuri. De exemplu:
1. Folosiți instrumentul mysqlbinlog pentru a analiza fișierul binlog și a efectua recuperarea bazei de date la un moment dat.
2. Flashback al bazei de date bazat pe evenimente binlog (MariaDB poate folosi direct mysqlbinlog pentru flashback)
3. Instrumentul open-source online de schimbare a tabelelor de pe Github, gh-ost, este de asemenea implementat prin binlog
4. Poți, de asemenea, să te abonezi și să consumi incremental prin analizarea binlogurilor
Binlog este foarte util, dar este inevitabil să întâmpini unele probleme în procesul zilnic de operare și mentenanță. Iată câteva erori legate de binlog.
Una dintre întrebările frecvente
Fenomen
mysqlbinlog5.5 analizează fișierul binlog mysql5.7 apare
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.
Analiza cauzei
MySQL 5.6 și alte versiuni superioare ale fișierelor binlog au adăugat evenimente binlog noi, cum ar fi evenimentele GTID.
mysqlbinlog din mysql5.5 nu recunoaște astfel de evenimente binlog.
Soluție alternativă
Folosește versiunea superioară a mysqlbinlog pentru a rezolva binlog-ul generat de versiunea inferioară a mysql
Întrebarea frecventă a doua
Fenomen
Un server mysql sănătos arată starea de sclav
Last_SQL_Error:Eșec la citirea jurnalului de releu: Nu s-a putut analiza introducerea evenimentului jurnalului releului.
Motivele posibile sunt: logul binar al masterului este corupt (poți verifica asta rulând 'mysqlbinlog' pe logul binar),
Jurnalul de releu al sclavului este corupt (poți verifica asta rulând 'mysqlbinlog' pe jurnalul de releu),
o problemă de rețea sau un bug în codul MySQL al maestrului sau sclavului.
Dacă vrei să verifici jurnalul binar al masterului sau jurnalul releului slave,
veți putea ști numele lor emitând "ARATĂ STATUTUL DE SCLAV" pe acest sclav.
Analiza cauzei
Intrările din jurnalul de releu nu pot fi citite din cauza erorilor binlog din biblioteca principală, erori din jurnalul de releu din biblioteca slave sau probleme și erori de rețea. Este de obicei cauzată de o defecțiune a rețelei sau de o presiune excesivă asupra bibliotecii slave, rezultând un format incorect al jurnalului de releu.
Soluție alternativă
După găsirea momentului de sincronizare curent și resetarea sincronizării master-slave, va fi generat un nou jurnal de releu, iar sincronizarea master-slave va fi restaurată.
Din rezultatul "afișează starea sclavului\G", găsiți următoarele informații:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos de master citit de biblioteca slave: 950583017 // Punctul de poziție care a fost executat pe slave
Oprește slave-ul și setează din nou sincronizarea începând cu fișierul binlog pe care slave-ul l-a citit și poziția executată.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos de master citit de biblioteca slave: 950583017 // Punctul de poziție care a fost executat pe slave
Întrebarea frecventă trei
Fenomen
Restaurarea stării de sclav afișați după eroarea perioadei de nefuncționare:
Last_SQL_Error: Eroare la inițializarea poziției jurnalului releului: eroare I/O la citirea antetului din jurnalul binar
Last_SQL_Error: Eroare la inițializarea poziției jurnalului releului: Binlog are un număr magic slab; Nu este un fișier de jurnal binar care să poată fi folosit de această versiune de MySQL
Analiza cauzei
Perioadele de nefuncționare, cum ar fi întreruperea curentului, arderea plăcii de bază etc., sau oprirea ilegală, ceea ce duce la coruperea fișierului de releu
Soluție alternativă
Aceeași întrebare a doua.
relay_log_recovery = 1 poate fi de asemenea setat.
Când sclavul se oprește din bibliotecă, dacă jurnalul de releu este corupt și o parte din jurnalul de releu nu este procesată, jurnalul de releu este automat abandonat, iar jurnalul este recuperat din nou de la master, completând astfel recuperarea jurnalului de releu.
Întrebarea frecventă a patru
Fenomen
Apare când schimbi masterul în după ce o repornire de pe calculatorul bibliotecii se oprește
Eroare (Cod 1201): Nu s-a putut inițializa structura principală de informații; mai multe mesaje de eroare pot fi găsite în jurnalul de eroare MySQL
sau
EROARE 1872 (HY000): Slave nu a reușit să inițieze structura de informații a jurnalului releului din depozit
Analiza cauzei
Perioadele de nefuncționare, cum ar fi întreruperea curentului, arderea plăcii de bază etc., sau oprirea ilegală, cauzând daune fișierelor master.info sau realy-log.info
Soluție alternativă
slave> reset slave all, schimbă master în
Măsuri preventive
Setări de profil
relay_log_info_repository=tabel
master_info_repository=tabel
Motorul de stocare al MySQL 5.6.5 mysql.slave_master_info și mysql.slave_relay_log_info este setat implicit pe MyISAM și trebuie să-l schimbi pe motorul de stocare al InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabelul va fi actualizat după sync_master_info evenimente.
mysql.slave_relay_log_info tabelul va fi actualizat odată cu fiecare commit de tranzacție.
Întrebarea frecventă 5
Fenomen
Master slave binlog_format inițial o afirmație, după schimbarea bazei de date principale binlog_format la row, arată starea sclavului din bibliotecă:
Last_Error: Eroare la executarea evenimentului de rând: 'Nu se poate executa instrucțiunea: imposibil de scris în jurnal binar deoarece instrucțiunea este în format de rând și BINLOG_FORMAT = STATEMENT.'
Analiza cauzei
Când baza principală de date binlog_format este row, iar sclavul bibliotecii binlog_format este statement, eroarea de mai sus va apărea.
Dar biblioteca principală binlog_format este statement, iar biblioteca de sclavi binlog_format rând;
Sau dacă binlog_format principală de bază de date este row, eroarea nu va fi raportată dacă binlog_format bazei de date este amestecată.
Dacă thread-ul tău SQL este într-adevăr configurat cu
binlog_format=STATEMENT odată ce primește un eveniment ROW, se va opri. The
motivul este că nu ar putea înregistra acel eveniment ROW în formatul STATEMENTformat (uneori numim asta injecție ROW, care este fie un
instrucțiune BINLOG sau un eveniment ROW executat de firul SQL al sclavului)
Referință detaliată pentru motiv:https://bugs.mysql.com/bug.php?id=69095
Soluție alternativă
SLAVE> SLAVE STOP;
SLAVE> SET GLOBAL binlog_format=MIXTED;
SLAVE> SLAVE START;
Întrebarea frecventă numărul 6
Fenomen
Eroare la sincronizarea mysql5.6 cu mysql5.5
Last_IO_Error: Am primit eroarea fatală 1236 de la master când citesc date din jurnalul binar: "Slave nu poate gestiona evenimentele de replicare cu suma de control pe care masterul este configurat să o logheze; Primul eveniment 'mysql-bin.000001' la 4, ultimul eveniment citit din 'mysql-bin.000001' la 120, ultimul octet citit din 'mysql-bin.000001' la 120.'
Analiza cauzei
Pentru a rezolva problema conform căreia instrucțiunile SQL care rulează pe serverul principal sunt inconsistente cu instrucțiunile SQL care rulează pe server (numit event corrupt) din cauza erorilor software și hardware sau de transmisie în rețea, MySQL 5.6 adaugă funcția Replication Event Checksum. Când un eveniment este scris în jurnalul binar, suma de verificare este scrisă și în jurnalul binar, iar după ce evenimentul este transmis către slave prin rețea, este verificat pe slave și scris în jurnalul de releu al sclavului. Deoarece evenimentele și sumele de verificare sunt înregistrate la fiecare pas, putem identifica rapid care este problema.
În mysql5.6.5 și versiunile ulterioare binlog_checksum valoarea implicită este crc32,
Valoarea implicită binlog_checksum versiunea anterioară era niciunul
soluție
Slave> set global binlog_checksum=none
Întrebarea frecventă 7
Fenomen
După ce discul este plin, curăță manual fișierul binlog și fișierul mysql-bin.index
Jurnalele binare de afișare sunt goale, dar starea de afișare a masterului este normală.
mysql> afișează loguri binare; Set gol (0,00 sec)mysql> afișează starea masterului;
+------------------+-----------+--------------+------------------+
| Fișier | Poziție | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analiza cauzei
După ce am verificat fișierul mysql-bin.index, am găsit prima linie goală.
În codul sursă mysql rpl_master.cc:show_binlogs() vei găsi următorul cod:
/* The file ends with EOF or empty line */
în timp ce ((lungime=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Liniile goale sunt considerate sfârșitul documentului
(Referință.)https://yq.aliyun.com/articles/213657Articol)
Măsuri preventive
Nu șterge manual binlog-ul, nu edita manual fișierul mysql-bin.index, decât dacă știi ce faci, altfel s-ar putea să faci mine singur!
rezumat
DBA-urile trebuie să fie atenți la îmbunătățirile pentru binlog în fiecare versiune nouă de MySQL (cum ar fi funcția gtid adăugată în versiunea 5.6, Enhanced Multi-threaded Slaves în versiunea 5.7) și să înțeleagă în detaliu semnificația fiecărui parametru, astfel încât să poată ști ce înseamnă atunci când întâlnesc erori și rezolvă problemele cu ușurință.
|
Postat pe 25.09.2018 10:31:40
|
|
|
|
