В архитектурах высокой доступности MySQL первичная репликация баз данных является очень распространённым типом.
Когда первичная база данных выходит из строя, вы можете обновить ведомую базу данных как новую первичную, чтобы обеспечить доступность сервиса. В то же время QPS всего кластера можно улучшить, расширяя ведомую библиотеку.
В архитектуре репликации мастер-слейв MySQL использует binlog для достижения согласованности данных мастер-слейв.
Как показано на рисунке выше, мастер-слейв репликация MySQL в основном состоит из следующих шагов
1. Мастер логирует изменения в бинарном журнале
2. Подчинённый io_thread запросить бинлог основной библиотеки и записать полученный журнал бинлога в релейный лог
3. Рабство sql_thread повторение событий в журнале ретрансляции
Помимо того, что binlog служит связью для репликации мастер-слейв MySQL, он также выполняет другие функции. Как что:
1. Используйте инструмент mysqlbinlog для разбора файла binlog и выполнения восстановления базы данных в точке времени.
2. Флэшбэк базы данных на основе событий binlog (MariaDB может напрямую использовать mysqlbinlog для флэшбэка)
3. Открытый инструмент для изменения таблиц на Github gh-ost также реализован через binlog
4. Вы также можете постепенно подписываться и потреблять, анализируя бинлоги
BinLog очень полезен, но неизбежно вы столкнётесь с проблемами в повседневной работе и обслуживании. Вот некоторые ошибки, связанные с бинлогом.
Один из часто задаваемых вопросов
Явление
MySqlBinLog5.5 анализирует файл 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.
Анализ причин
MySQL 5.6 и другие более высокие версии файлов бинлога добавили новые события бинлога, такие как события GTID.
MySqlBinLog в MySQL5.5 не распознаёт такие события бинлога.
Обходной путь
Используйте более высокую версию mysqlbinlog для разрешения бинлога, сгенерированного нижней версией mysql
Часто задаваемый вопрос второй
Явление
Появляется здоровый mysql-сервер, показывающий статус slave
Last_SQL_Error:Неудача чтения журнала релей: не удалось разобрать запись события в журнале ретрансляции.
Возможные причины: бинарный лог мастера повреждён (это можно проверить, запустив 'mysqlbinlog' в бинарном журнале),
Журнал реле ведомого повреждён (это можно проверить, запустив 'mysqlbinlog' в журнале ретрансляции),
сетевая проблема или ошибка в коде MySQL мастера или слейва.
Если хотите проверить бинарный журнал мастера или реле слейва,
вы сможете узнать их имена, выдав «ПОКАЗАТЬ СТАТУС РАБА» для этого раба.
Анализ причин
Записи в журнале реле нельзя прочитать из-за ошибок бинлога в главной библиотеке, ошибок журнала реле в ведомой библиотеке или сетевых проблем и ошибок. Обычно это вызвано сбоями сети или чрезмерной нагрузкой на ведомую библиотеку, что приводит к неправильному формату релейного журнала.
Обходной путь
После обнаружения текущей точки времени синхронизации и сброса синхронизации мастер-слейв будет сгенерирован новый релейный журнал, и синхронизация мастер-слейв будет восстановлена.
Из вывода «show slave status\G» найдите следующую информацию:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos мастера, читаемая ведомой библиотекой: 950583017 // Точка позиции, выполненная на ведомом
Остановите слейв и снова настройте синхронизацию, начиная с файла бинлога, который ведой прочитал, и запущенной позиции.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos мастера, читаемая ведомой библиотекой: 950583017 // Точка позиции, выполненная на ведомом
Часто задаваемый вопрос третий
Явление
Восстановление статуса показа ведомого после ошибки простоя:
Last_SQL_Error: Ошибка инициализации релейного лога: ошибка чтения заголовка из бинарного лога
Last_SQL_Error: Ошибка при инициализации положения релейного лога: В Binlog ошибочно магическое число; Это не бинарный файл журнала, который может использоваться этой версией MySQL
Анализ причин
Простои, такие как отключение питания, сгорание материнской платы и т.д., или незаконное отключение, приводящее к повреждению файла relay-bin-а
Обходной путь
Тот же вопрос второй.
relay_log_recovery = 1 также может быть установлено.
Когда ведомый файл выходит из библиотеки, если релей-лог повреждён и часть релейного журнала не обрабатывается, релейный журнал автоматически оборвается, и он заново забирается из мастера, завершая восстановление релейного журнала.
Часто задаваемый вопрос четвёртый
Явление
Появляется при переключении мастера на после перезагрузки из библиотеки
Ошибка (код 1201): Не удалось инициализировать структуру главной информации; больше сообщений об ошибках можно найти в журнале ошибок MySQL
или
ОШИБКА 1872 (HY000): Подчинённый не смог инициализировать структуру релейных логов из репозитория
Анализ причин
Простои, такие как отключение питания, сгорание материнской платы и т.д., или незаконное отключение, повреждающее master.info или realy-log.info файлы
Обходной путь
Slave> reset slave all, change master на
Профилактические меры
Настройки профиля
relay_log_info_repository=таблица
master_info_repository=таблица
Движок хранения MySQL 5.6.5 mysql.slave_master_info и mysql.slave_relay_log_info по умолчанию установлен на MyISAM, и его нужно изменить на движок хранения InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info таблица будет обновляться после sync_master_info событий.
mysql.slave_relay_log_info таблица будет обновляться с каждым коммитом транзакции.
Часто задаваемый вопрос 5
Явление
Мастер-подчинённый изначально binlog_format оператор, после изменения основной базы данных binlog_format на строку, появляется статус подчинённого появления из библиотеки:
Last_Error: Ошибка при выполнении строки: «Нельзя выполнить оператор: невозможно записать в бинарный лог, так как оператор находится в строчном формате и BINLOG_FORMAT = ОПЕРАТОР.»
Анализ причин
Когда основная база данных binlog_format строка, а оператор ведомой библиотеки binlog_format is, появится вышеописанная ошибка.
Но основная библиотечная binlog_format — утверждение, а библиотека рабов binlog_format ряд;
Или если основная binlog_format базы данных — строка, ошибка не будет сообщена, если binlog_format базы данных смешан.
Если ваш SQL thread действительно настроен с
binlog_format=STATEMENT, как только получит событие ROW, оно останавливается. The
причина в том, что он не сможет зарегистрировать это событие ROW в формате STATEMENT (иногда мы называем это инъекцией ROW, что либо является
оператор 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 от мастера при чтении данных из бинарного журнала: «Слейв не может обрабатывать события репликации с контрольной суммой, которую мастер настроен на лог; Первое событие '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 */
тогда как ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Пустые строки считаются концом документа
(Ссылка.)https://yq.aliyun.com/articles/213657Статья)
Профилактические меры
Не удаляйте бинлог вручную, не редактируйте файл mysql-bin.index вручную, если только не знаете, что делаете, иначе можете сами себе навредить!
сводка
DBA должны обращать внимание на улучшения бинлогирования в каждой новой версии MySQL (например, функция gtid, добавленная в версии 5.6, улучшенные многопоточные подчинённые в версии 5.7), а также подробно понимать значение каждого параметра, чтобы понимать, что они имеют в виду при ошибках, и легко решать задачи.
|
Опубликовано 25.09.2018 10:31:40
|
|
|
|
