В архитектурите с висока наличност на MySQL основното възпроизвеждане на бази данни е много често срещан тип.
Когато основната база данни спре, можете да ъпгрейднете подчинена база данни като нова първична, за да гарантирате наличността на услугите. В същото време QPS на целия клъстер може да се подобри чрез разширяване на подчинената библиотека.
При архитектурата за репликация на master-slave, MySQL използва binlog, за да постигне консистентност между master-slave данни.
Както е показано на горната фигура, репликацията на MySQL master-slave основно включва следните стъпки
1. Овладява записването на промените в двоичния лог
2. Подчинението io_thread поиска binlog на основната библиотека и записва получения binlog log в релейния лог
3. Роб sql_thread повтори събития в релейния лог
Освен че е връзка за репликация на MySQL master-slave, binlog служи и за други цели. Като какво:
1. Използвайте инструмента mysqlbinlog, за да анализирате binlog файла и да извършите възстановяване на база данни в момента.
2. Ретроспекция на базата данни, базирана на събития от binlog (MariaDB може директно да използва mysqlbinlog за ретроспекция)
3. Отвореният онлайн инструмент за смяна на таблици gh-ost на Github също е реализиран чрез binlog
4. Можете също постепенно да се абонирате и консумирате, като анализирате бинлогове
Binlog е много полезен, но е неизбежно да срещнете някои проблеми в ежедневната работа и поддръжка. Ето някои грешки, свързани с бинлог.
Един от често задаваните въпроси
Феномен
MySqlBinLog5.5 анализира MySql5.7 binlog файла
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.
Анализ на причините
MySQL 5.6 и други по-високи версии на binlog файлове са добавили нови събития в binlog, като GTID събития.
MySqlBinLog в MySQL5.5 не разпознава такива събития в бинлог.
Заобиколно решение
Използвайте по-високата версия на mysqlbinlog, за да разрешите binlog-а, генериран от по-долната версия на mysql
Често задаван въпрос втори
Феномен
Появява се здрав mysql сървър, показващ статуса на роб,
Last_SQL_Error:Грешка при четене на релейния лог: Не можех да разчленя запис на събитието в релейния лог.
Възможните причини са: бинарният лог на главния файл е повреден (можете да проверите това, като стартирате 'mysqlbinlog' върху бинарния лог),
Релейният лог на подчинения е повреден (можеш да провериш това, като стартираш 'mysqlbinlog' в релейния лог),
мрежов проблем или бъг в MySQL кода на мастъра или роба.
Ако искате да проверите бинарния лог на главния или релейния лог на подчинения,
Ще можете да знаете имената им, като издадете "ПОКАЖИ РОБСКИ СТАТУС" на този роб.
Анализ на причините
Записите в релейния лог не могат да бъдат прочетени поради грешки в бинлог в главната библиотека, грешки в релейния лог в подчинената библиотека или мрежови проблеми и бъгове. Обикновено се причинява от мрежова повреда или прекомерен натиск върху подчинената библиотека, което води до неправилен формат на релейния лог.
Заобиколно решение
След намиране на текущата точка на синхронизация и нулиране на синхронизацията между главния и подчинен, ще се генерира нов релейен лог и синхронизацията между главния и подчинен ще бъде възстановена.
От изхода на "show slave status\G" намерете следната информация:
Relay_Master_Log_File: mysql-bin.002540 // The binlogExec_Master_Log_Pos of master, прочетена от slave библиотеката: 950583017 // Позицията на позиция, която е изпълнена върху slave
Спри подчинения и настрой синхронизацията отново, започвайки от binlog файла, който подчинението е прочел, и от позицията, която е изпълнена.
Relay_Master_Log_File: mysql-bin.002540 // The binlogExec_Master_Log_Pos of master, прочетена от slave библиотеката: 950583017 // Позицията на позиция, която е изпълнена върху slave
Често задавана трета тема
Феномен
Възстановяване на статуса на показване на роб след грешка при прекъсване:
Last_SQL_Error: Грешка при инициализация на релейния лог: Грешка при четене на заглавието от двоичния лог
Last_SQL_Error: Грешка при инициализиране на позицията на релейния лог: Binlog има лошо магическо число; Това не е двоичен лог файл, който може да се използва от тази версия на MySQL
Анализ на причините
Прекъсване, като прекъсване на захранването, изгаряне на дънната платка и др., или незаконно изключване, което води до повреда на relay-bin файла
Заобиколно решение
Същият въпрос две.
relay_log_recovery = 1 също може да се зададе.
Когато подчинението се изключи от библиотеката, ако релейният лог е повреден и част от релейния лог не бъде обработен, релейният лог автоматично се изоставя и той се възстановява от главния лог, с което възстановяването на релейния лог завършва.
Често задавани въпроси четири
Феномен
Появява се при смяна на master на след като рестарт от библиотечната машина не работи
Грешка (Код 1201): Не можа да се инициализира основната информационна структура; още съобщения за грешки могат да се намерят в лога на грешките MySQL
или
ГРЕШКА 1872 (HY000): Slave не успя да инициализира структурата на релейния лог от хранилището
Анализ на причините
Прекъсване, като прекъсване на захранването, изгаряне на дънната платка и др., или незаконно изключване, което може да повреди master.info или realy-log.info файлове
Заобиколно решение
Роб> рестартирай Slave All, смени master на
Превантивни мерки
Настройки на профила
relay_log_info_repository=таблица
master_info_repository=таблица
Двигателят за съхранение на MySQL 5.6.5 mysql.slave_master_info и mysql.slave_relay_log_info по подразбиране е настроен на MyISAM и трябва да го смените на storage engine на InnoDB
ALTER ТАБЛИЦА mysql.slave_master_info ENGINE=InnoDB;
ALTER ТАБЛИЦА mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info таблица ще бъде актуализирана след sync_master_info събития.
mysql.slave_relay_log_info таблица ще се обновява с всяко транзакционно потвърждение.
Често задавани въпроси 5
Феномен
Master slave първоначално binlog_format оператор, след като се промени основната база данни binlog_format на ред, от библиотеката се появява статусът на slave:
Last_Error: Грешка при изпълнение на ред събитие: 'Не може да се изпълни изявление: невъзможно е да се запише в двоичен лог, тъй като операторът е в ред формат и BINLOG_FORMAT = STATEMENT.'
Анализ на причините
Когато основната база данни binlog_format е ред, а слейв библиотеката binlog_format е оператор, горната грешка ще се появи.
Но основната библиотечна binlog_format е декларация, а робската библиотека binlog_format ред;
Или ако основната binlog_format база данни е ред, грешката няма да бъде докладвана, ако binlog_format на базата данни е смесена.
Ако вашата SQL нишка наистина е конфигурирана с
binlog_format=STATEMENT, след като получи ROW събитие, ще спре. The
причината е, че няма да може да регистрира това събитие ROW във формат STATEMENT (понякога наричаме това ROW injection, което е или
BINLOG оператор или ROW събитие, изпълнено от SQL нишката на подчинения)
Подробна причина:https://bugs.mysql.com/bug.php?id=69095
Заобиколно решение
РОБ> СПРИ РОБ;
SLAVE> SET GLOBAL binlog_format=MIXED;
РОБСТВО> ЗАПОЧНИ РОБСТВО;
Често задавани въпроси номер 6
Феномен
Грешка при синхронизиране на mysql5.6 с mysql5.5
Last_IO_Error: Получих фатална грешка 1236 от master при четене на данни от двоичен лог: 'Slave не може да обработва репликационни събития с контролната сума, която master е конфигуриран да логира; Първото събитие 'mysql-bin.000001' в 4, последното събитие се четеше от 'mysql-bin.000001' на 120, последният байт прочете от 'mysql-bin.000001' на 120.'
Анализ на причините
За да се реши проблемът, че SQL операторите, работещи на основния сървър, са несъвместими със SQL операторите, работещи на сървъра (наречени event corrupt) поради софтуерни и хардуерни или мрежови грешки при предаване, MySQL 5.6 добавя функцията Replication Event Checksum. Когато събитие се записва в двоичния лог, контролната сума също се записва в бинарния лог, а след като събитието бъде прехвърлено към подчинения през мрежата, то се проверява на подчинения и се записва в релейния лог на подчинения. Тъй като събитията и контролните суми се записват на всяка стъпка, можем бързо да разберем какъв е проблемът.
В mysql5.6.5 и по-късни версии binlog_checksum стандартната стойност е crc32,
По подразбиране стойността binlog_checksum предишната версия беше "никаква"
решение
Slave> set global binlog_checksum=none
Често задавани въпроси 7
Феномен
След като дискът се напълни, ръчно почистете binlog файла и mysql-bin.index файла
Бинарните логове на шоуто са празни, но статусът на шоу мастер е нормален.
mysql> показва двоични логове; Празен набор (0.00 сек)mysql> статус на шоу мастер;
+------------------+-----------+--------------+------------------+
| Файл | Позиция | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Анализ на причините
След като проверих файла mysql-bin.index, намерих първия празен ред.
В изходния код на mysql rpl_master.cc:show_binlogs() ще намерите следния код:
/* The file ends with EOF or empty line */
докато ((дължина=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Празните редове се считат за край на документа
(Референция.)https://yq.aliyun.com/articles/213657Статия)
Превантивни мерки
Не изтривай ръчно binlog, не редактирай ръчно mysql-bin.index файла, освен ако не знаеш какво правиш, иначе може да си поставяш мини!
резюме
DBA трябва да обръщат внимание на подобренията при бинлогване във всяка нова версия на MySQL (като функцията gtid, добавена във версия 5.6, Enhanced Multi-threaded Slaves във версия 5.7), и да разбират значението на всеки параметър в детайли, за да могат да разберат какво означава при грешки и лесно да решават проблемите.
|
Публикувано в 25.09.2018 г. 10:31:40 ч.
|
|
|
|
