W architekturach wysokiej dostępności MySQL replikacja pierwotnej bazy danych jest bardzo powszechnym typem.
Gdy baza podstawowa przestanie działać, możesz zaktualizować bazę danych slave jako nową bazę podstawową, aby zapewnić dostępność usług. Jednocześnie QPS całego klastra można ulepszyć poprzez rozszerzenie biblioteki podrzędnej.
W architekturze replikacji master-slave, MySQL wykorzystuje binlog do osiągnięcia spójności danych master-slave.
Jak pokazano na powyższym rysunku, replikacja MySQL master-slave składa się głównie z następujących kroków
1. Główny rejestruje zmiany w dzienniku binarnym
2. io_thread podrzędny żądać binlogu głównej biblioteki i zapisywać powstały logowy binlog do dziennika przekaźnika
3. Niewolnik sql_thread powtórzyć wydarzenia w dzienniku przekaźnika
Oprócz służenia do replikacji MySQL master-slave, binlog pełni także inne funkcje. Na przykład co:
1. Użyj narzędzia mysqlbinlog do analizy pliku binlog w celu przeprowadzenia odzyskiwania bazy danych w określonym momencie.
2. Retrospekcja bazy danych oparta na zdarzeniach binlogu (MariaDB może bezpośrednio użyć mysqlbinlog do flashbacku)
3. Otwartoźródłowe narzędzie do zmiany tabel online gh-ost na Githubie jest również implementowane przez binlog
4. Możesz także stopniowo subskrybować i konsumować, analizując binlogi
Binlog jest bardzo przydatny, ale nieuniknione jest, że napotkasz pewne problemy w codziennym procesie obsługi i konserwacji. Oto kilka błędów związanych z binlogiem.
Jedno z najczęściej zadawanych pytań
Zjawisko
mysqlbinlog5.5 parsuje plik binlog mysql5.7
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 przyczyn
MySQL 5.6 i inne wyższe wersje plików binlog dodały nowe zdarzenia binlog, takie jak zdarzenia GTID.
mysqlbinlog w mysql5.5 nie rozpoznaje takich zdarzeń binlog.
Obejście
Użyj wyższej wersji mysqlbinlog, aby rozwiązać binlog generowany przez niższą wersję mysql
Najczęściej zadawane pytanie drugie
Zjawisko
Zdrowy serwer MySQL pokazuje status slave
Last_SQL_Error: Niepowodzenie odczytu dziennika przekaźnika: Nie udało się przeparsować wpisu zdarzenia dziennika przekaźnika.
Możliwe przyczyny to: uszkodzony jest binarny log mastera (można to sprawdzić, uruchamiając 'mysqlbinlog' na logu binarnym),
Log przekaźnika podrzędnego jest uszkodzony (można to sprawdzić, uruchamiając 'mysqlbinlog' na dzienniku przekaźnika),
problem sieciowy lub błąd w kodzie MySQL mastera lub slave'a.
Jeśli chcesz sprawdzić dziennik binarny mastera lub relay slave'a,
Będziesz mógł poznać ich imiona, nadając temu niewolnikowi napis 'POKAŻ STATUS NIEWOLNIKA'.
Analiza przyczyn
Wpisy w dzienniku przekaźnika nie mogą być odczytywane z powodu błędów binlogowych w bibliotece głównej, błędów dziennika przekaźników w bibliotece podrzędnej lub problemów i błędów sieciowych. Zazwyczaj jest spowodowany awarią sieci lub nadmiernym obciążeniem biblioteki slave, co skutkuje nieprawidłowym formatem dziennika przekaźnikowego.
Obejście
Po znalezieniu aktualnego punktu synchronizacji i zresetowaniu synchronizacji master-slave, zostanie wygenerowany nowy dziennik przekaźnika, a synchronizacja master-slave zostanie przywrócona.
Z wyjścia "show slave status\G" znajdziesz następujące informacje:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera odczytanego przez bibliotekę slave: 950583017 // Punkt pozycji pozycji wykonany na slave
Zatrzymaj podrzędnego i ustaw synchronizację ponownie, zaczynając od pliku binlogu, który podwładny odczytał, oraz pozycji wykonanej.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera odczytanego przez bibliotekę slave: 950583017 // Punkt pozycji pozycji wykonany na slave
Najczęściej zadawane pytanie trzecie
Zjawisko
Przywrócenie statusu pokazu niewolnika po błędzie przestoju:
Last_SQL_Error: Błąd inicjalizujący pozycję logu przekaźnika: Błąd I/O odczytujący nagłówek z dziennika binarnego
Last_SQL_Error: Błąd inicjalizacji pozycji dziennika przekaźnika: Binlog ma złą liczbę magiczną; To nie jest plik dziennika binarnego, który może być używany przez tę wersję MySQL
Analiza przyczyn
Przestoje, takie jak awaria zasilania, spalenie płyty głównej itp., lub nielegalne wyłączenie, skutkujące uszkodzeniem pliku przekaźnikowego pojemnika
Obejście
To samo pytanie drugie.
relay_log_recovery = 1 również można ustawić.
Gdy podrzędny przechodzi z biblioteki, jeśli dziennik przekaźnika zostanie uszkodzony i część dziennika nie zostanie przetworzona, dziennik przekaźnika jest automatycznie porzucany, a dziennik pobierany jest ponownie z głównego rejestru, kończąc proces odzyskiwania dziennika przekaźnika.
Najczęściej zadawane pytanie czwarte
Zjawisko
Pojawia się po zmianie master na po restarcie z komputera bibliotecznego, który pada
Błąd (Kod 1201): Nie udało się zainicjować struktury informacji głównego; więcej komunikatów o błędach można znaleźć w dzienniku błędów MySQL
lub
BŁĄD 1872 (HY000): Operator nie zdołał zaikalizować struktury informacji dziennika przekaźnika z repozytorium
Analiza przyczyn
Przestoje, takie jak awaria zasilania, spalenie płyty głównej itp., lub nielegalne wyłączenie, powodujące uszkodzenia plików master.info lub realy-log.info
Obejście
Niewolnik> resetuj niewolnika wszystko, zmień gospodarza na
Środki zapobiegawcze
Ustawienia profilu
relay_log_info_repository=Tabela
master_info_repository=tabela
Silnik pamięci masowej MySQL 5.6.5 mysql.slave_master_info i mysql.slave_relay_log_info jest domyślnie ustawiony na MyISAM i musisz zmienić go na silnik pamięci masowej InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabela zostanie zaktualizowana po sync_master_info wydarzeniach.
mysql.slave_relay_log_info tabela będzie aktualizowana przy każdym zatwierdzeniu transakcji.
Najczęściej zadawane pytanie 5
Zjawisko
Początkowo element główny niemocnego binlog_format instrukcją, po zmianie binlog_format głównej bazy danych na wiersz, z biblioteki pojawia się status slave:
Last_Error: Błąd wykonującego zdarzenie wiersza: 'Nie można wykonać instrukcji: niemożliwe do zapisania do logu binarnego, ponieważ instrukcja jest w formacie wiersza, a BINLOG_FORMAT = INSTRUKCJA.'
Analiza przyczyn
Gdy główny binlog_format bazy danych to wiersz, a biblioteka podrzędna binlog_format to instrukcja, pojawi się powyższy błąd.
Ale główna biblioteka binlog_format to wypowiedź, a biblioteka niewolników binlog_format rzędzie;
Albo jeśli główny binlog_format bazy danych to wiersz, błąd nie zostanie zgłoszony, jeśli binlog_format bazy danych jest mieszane.
Jeśli Twój wątek SQL faktycznie jest skonfigurowany z
binlog_format=OŚWIADCZENIE po otrzymaniu zdarzenia ROW, zatrzyma się. The
powodem jest to, że nie byłby w stanie zarejestrować tego zdarzenia ROW w formacie STATEMENTu (czasem nazywamy to wstrzykiwaniem ROW, co jest albo
Instrukcja BINLOG lub zdarzenie ROW wykonywane przez wątek SQL slave)
Szczegółowy powód:https://bugs.mysql.com/bug.php?id=69095
Obejście
NIEWOLNIK> ZATRZYMAJ NIEWOLNIKA;
SLAVE> ZBIÓR GLOBALNY binlog_format=MIESZANE;
NIEWOLNIK> NIEWOLNIK STARTOWY;
Najczęściej zadawane pytanie numer 6
Zjawisko
Błąd przy synchronizacji mysql5.6 z mysql5.5
Last_IO_Error: Otrzymałem fatalny błąd 1236 od mastera podczas odczytu danych z dziennika binarnego: 'Slave nie może obsłużyć zdarzeń replikacyjnych z sumą kontrolną, że master jest skonfigurowany do logowania; Pierwsze zdarzenie 'mysql-bin.000001' przy 4, ostatnie zdarzenie odczytane z 'mysql-bin.000001' przy 120, ostatni bajt odczytany z 'mysql-bin.000001' przy 120.'
Analiza przyczyn
Aby rozwiązać problem, że instrukcje SQL uruchamiane na serwerze podstawowym są niespójne z instrukcjami SQL działającymi na serwerze (tzw. uszkodzone zdarzenia) z powodu błędów transmisji oprogramowania i sprzętu lub sieci, MySQL 5.6 dodaje funkcję sumy kontrolnej Zdarzenia Replikacji. Gdy zdarzenie jest zapisywane do logu binarnego, suma kontrolna jest również zapisywana do logu binarnego, a po przesłaniu zdarzenia do slave'a przez sieć, jest ono weryfikowane na slave i zapisywane do dziennika przekaźnika slave'a. Ponieważ zdarzenia i sumy kontrolne są rejestrowane na każdym etapie, możemy szybko ustalić, gdzie leży problem.
W wersjach mysql5.6.5 i nowszych binlog_checksum domyślną wartością jest crc32,
Domyślna wartość binlog_checksum poprzedniej wersji to brak
rozwiązanie
Slave> zestaw globalny binlog_checksum=brak
Najczęściej zadawane pytanie 7
Zjawisko
Gdy dysk jest pełny, ręcznie wyczyść plik binlog oraz plik mysql-bin.index
Pokazuj dzienniki binarne są puste, ale status mastera pokazuj jest normalny.
mysql> pokaż logi binarne; Pusty zestaw (0,00 sek)mysql> pokaż status mastera;
+------------------+-----------+--------------+------------------+
| Plik | Pozycja | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analiza przyczyn
Po sprawdzeniu pliku mysql-bin.index znalazłem pierwszą pustą linię.
W kodzie źródłowym mysql rpl_master.cc:show_binlogs() znajdziesz następujący kod:
/* The file ends with EOF or empty line */
podczas gdy (length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Puste linie są uznawane za koniec dokumentu
(Źródło.)https://yq.aliyun.com/articles/213657Artykuł)
Środki zapobiegawcze
Nie usuwaj ręcznie binloga, nie edytuj ręcznie pliku mysql-bin.index, chyba że wiesz, co robisz, bo inaczej możesz sobie zadawać miny!
streszczenie
DBA muszą zwracać uwagę na ulepszenia binlogowania w każdej nowej wersji MySQL (takie jak funkcja gtid dodana w wersji 5.6, Enhanced Multi-threaded Slaves w wersji 5.7) oraz szczegółowo rozumieć znaczenie każdego parametru, aby wiedzieć, co oznaczają, gdy napotykają błędy i łatwo rozwiązywać problemy.
|
Opublikowano 25.09.2018 10:31:40
|
|
|
|
