Первоначально Написано Мухаммедом Ирфаном
Репликация MySQL является основным процессом для поддержки нескольких копий данных, и репликация является очень важным аспектом в администрировании базы данных. Чтобы синхронизировать данные между ведущим и ведомым устройствами, вам необходимо обеспечить бесперебойную передачу данных, и для этого необходимо своевременно действовать в отношении ошибок репликации, чтобы продолжить синхронизацию данных. Здесь, в группе поддержки Percona , мы часто помогаем клиентам с проблемами, связанными с репликацией. В этом посте я расскажу о самой критической ошибке кода репликации 1236, а также о причинах и способах ее устранения. Ошибка репликации MySQL « Получена фатальная ошибка 1236 » может быть вызвана несколькими причинами, и я постараюсь охватить все из них.
Last_IO_Error: Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: «превышена запись в журнале событий max_allowed_packet; Увеличьте max_allowed_packet на мастере; первое событие «binlog.000201» на 5480571
Это типичная ошибка на подчиненном (ых) сервере (ах). Это отражает проблему, связанную с размером max_allowed_packet . max_allowed_packet ссылается на один оператор SQL, отправляемый на сервер MySQL как двоичное событие журнала от главного к подчиненному. Эта ошибка обычно возникает, когда у вас есть другой размер max_allowed_packet на главном и ведомом (то есть размер главного max_allowed_packet больше, чем на подчиненном сервере) . Когда главный сервер MySQL пытается отправить больший пакет, чем определено на подчиненном сервере, подчиненный сервер не может принять его и, следовательно, ошибку. Чтобы устранить эту проблему, убедитесь, что у max_allowed_packet одинаковое значение как для ведомого, так и для ведущего устройства. Вы можете прочитать больше о max_allowed_packet здесь .
Эта ошибка обычно возникает при обновлении огромного количества строк на ведущем устройстве, и она не вписывается в значение размера slave max_allowed_packet, потому что размер slave max_allowed_packet ниже, чем мастер. Обычно это происходит с запросами « LOAD DATA INFILE » или « INSERT .. SELECT ». По моему опыту, это также может быть вызвано логикой приложения, которая может генерировать огромную INSERT с ненужными данными. Примите во внимание, что одна новая переменная, представленная в MySQL 5.6.6 и более поздних версиях slave_max_allowed_packet_size, контролирует максимальный размер пакета для потоков репликации. Он переопределяет переменную max_allowed_packet на ведомом устройстве, и его значение по умолчанию составляет 1 ГБ. В этом посте, «Max_allowed_packet и повреждение двоичного журнала в MySQL», мой коллега Мигель Анхель Нието подробно объясняет эту ошибку.
Получил фатальную ошибку 1236 от мастера при чтении данных из двоичного журнала: «Не удалось найти первое имя файла журнала в двоичном файле индекса журнала»
Эта ошибка возникает, когда ведомому серверу требуется двоичный журнал для репликации, больше не существует на главном сервере базы данных. В одном из сценариев для этого ваш подчиненный сервер по какой-то причине останавливается на несколько часов / дней, и когда вы возобновляете репликацию на ведомом устройстве, происходит сбой с вышеуказанной ошибкой.
Когда вы исследуете, вы обнаружите, что главный сервер больше не запрашивает двоичные журналы, которые ведомому серверу нужно извлечь для синхронизации данных. Возможные причины этого включают двоичные журналы с истекшим сроком действия главного сервера через системную переменную expire_logs_days — или кто-то вручную удалял двоичные журналы из мастера с помощью команды PURGE BINARY LOGS или с помощью команды ‘rm -f’, или у вас может быть какой-то cronjob, который архивирует старые двоичные журналы в запрос места на диске и т. д. Итак, убедитесь, что на главном сервере всегда есть необходимые двоичные журналы, и вы можете обновить свои процедуры, чтобы сохранить двоичные журналы, необходимые для подчиненного сервера, путем мониторинга переменной « Relay_master_log_file » из SHOW SLAVE STATUSвывод. Более того, если вы установили expire_log_days в my.cnf, старые binlogs устаревают автоматически и удаляются. Это означает, что когда MySQL открывает новый файл binlog, он проверяет старые binlogs и удаляет все, которые старше, чем значение expire_logs_days (в днях). Percona Server добавил функцию для истечения срока действия журналов на основе общего количества файлов, используемых вместо возраста файлов binlog. Таким образом, в этой конфигурации, если вы получите всплеск трафика, это может привести к тому, что бинлоги исчезнут быстрее, чем вы ожидаете. Для получения дополнительной информации проверьте Ограничение количества файлов binlog .
Чтобы решить эту проблему, единственное чистое решение, которое я могу придумать, — это воссоздать подчиненный сервер из резервной копии главного сервера или из другого подчиненного в топологии репликации.
— Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: ‘binlog урезан в середине события; учитывать нехватку дискового пространства на мастере; первое событие ‘mysql-bin.000525’ в 175770780, последнее событие, прочитанное из ‘/data/mysql/repl/mysql-bin.000525’ в 175770780, последний байт, прочитанный из ‘/ data / mysql / repl / mysql- bin.000525 ‘на 175771648.’
Обычно это вызвано sync_binlog <> 1 на главном сервере, что означает, что двоичные события журнала могут не синхронизироваться на диске. Может быть зафиксированный оператор SQL или изменение строки (в зависимости от формата репликации) на главном сервере, который не сделал его ведомым, потому что событие урезано. Решением было бы переместить подчиненный поток в следующий доступный двоичный журнал и инициализировать подчиненный поток с первой доступной позицией в двоичном журнале, как показано ниже:
mysql>CHANGE MASTERTOMASTER_LOG_FILE='mysql-bin.000526',MASTER_LOG_POS=4;
— [ОШИБКА] Ведомый ввод / вывод: Получена фатальная ошибка 1236 от мастера при чтении данных из двоичного журнала: «Клиент запросил мастер начать репликацию с невозможной позиции; первое событие ‘mysql-bin.010711’ в 55212580, последнее событие, прочитанное из ‘/var/lib/mysql/log/mysql-bin.000711’ в 4, последний байт, прочитанный из ‘/ var / lib / mysql / log / mysql-bin.010711 ‘на 4.’, код ошибки: 1236
Я предвижу, что главный сервер вышел из строя или перезагружен и, следовательно, события двоичного журнала не синхронизированы на диске. Обычно это происходит, когда sync_binlog! = 1 на мастере. Вы можете исследовать это как проверку содержимого двоичного журнала, как показано ниже:
$mysqlbinlog--base64-output=decode-rows--verbose--verbose--start-position=55212580mysql-bin.010711
Вы найдете, что это последняя позиция двоичного журнала и конец двоичного файла журнала. Эту проблему обычно можно устранить, переместив подчиненное устройство в следующий двоичный журнал. В этом случае это будет:
mysql>CHANGE MASTER TOMASTER_LOG_FILE='mysql-bin.000712',MASTER_LOG_POS=4;
Это возобновит репликацию.
Чтобы избежать испорченных binlogs на ведущем устройстве, включение sync_binlog = 1 на главном помогает в большинстве случаев. sync_binlog = 1 будет синхронизировать двоичный журнал на диск после каждой фиксации. sync_binlog заставляет MySQL выполнять fsync в двоичном журнале в дополнение к fsync от InnoDB. Напомним, что это оказывает некоторое влияние на стоимость, поскольку он синхронизирует запись в двоичный журнал на диске после каждой фиксации. С другой стороны, накладные расходы sync_binlog = 1 могут быть очень минимальными или незначительными, если дисковая подсистема является SSD вместе с кэш-памятью с резервным питанием от батареи (BBU). Вы можете прочитать больше об этом здесь в руководстве.
sync_binlog — это динамическая опция, которую вы можете включить на лету. Вот как:
mysql-master>SET GLOBAL sync_binlog=1;
Чтобы сделать изменение постоянным при перезагрузке, вы можете добавить этот параметр в my.cnf .
В дополнение к этому, наряду с исправлениями репликации, всегда лучше убедиться, что ваша реплика находится в ведущем устройстве, и проверить данные между ведущим / ведомым устройствами. К счастью, в Percona Toolkit есть инструменты для этой цели: pt-table-checkum & pt-table-sync . Перед проверкой согласованности репликации обязательно проверьте среду репликации, а затем синхронизируйте все различия.