Механизм координации бинарных логов репликации (Master Binlog Index)

Поток ввода-вывода репликации (Slave I/O Thread / Receiver Worker) подключается к Master-серверу как обычный клиент и запрашивает непрерывную передачу бинарных логов, начиная с определенного файла и смещения (MASTER_LOG_FILE / MASTER_LOG_POS) или диапазона транзакций Executed_Gtid_Set. Сервер-мастер сверяет запрошенную позицию со своим системным индексным файлом mysql-bin.index. Если запрошенный файл бинарного лога уже физически удален на мастере (например, по истечении binlog_expire_logs_seconds, командой PURGE BINARY LOGS или из-за нехватки диска), репликация немедленно останавливается:

«Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index' (или 'The slave is connecting to master with a GTID not recorded in master's binary log')»

Бизнес-риски

Полный разрыв репликации между серверами, потеря возможности восстановления данных методом Point-in-Time Recovery (PITR), потеря актуальности резервных нод.

Диагностическая таблица разновидностей ошибки 1236

Регламент восстановления репликации после ошибки 1236

Сценарий 1: Проверка доступных бинарных логов на Master-сервере

-- 1. Выполните запрос на Мастере для просмотра реально существующих логов:
SHOW BINARY LOGS;
-- Пример вывода:
-- mysql-bin.000150 | 1073741824
-- mysql-bin.000151 | 5420140

-- Самый старый доступный лог: mysql-bin.000150, позиция 4.

-- 2. Проверка статуса на Реплике:
SHOW SLAVE STATUS\G
-- Допустим, реплика ищет удаленный файл: mysql-bin.000148 (которого уже нет на мастере).

Сценарий 2: Перепривязка реплики на самый ранний доступный лог (Non-GTID)

Внимание: данный способ приведет к пропуску изменений, содержавшихся в удаленных логах. Рекомендуется только если потеря некритична или данные будут досинхронизированы через pt-table-sync:

-- На Slave-сервере:
STOP SLAVE;

-- Переключение на самый старый существующий файл лога мастера:
CHANGE MASTER TO 
    MASTER_LOG_FILE = 'mysql-bin.000150', 
    MASTER_LOG_POS = 4;

START SLAVE;
SHOW SLAVE STATUS\G

Сценарий 3: Переинициализация реплики с мастера через Percona XtraBackup (Zero-Downtime)

Если реплика критически отстала и пропущенные логи восстановить невозможно, выполните полную переинициализацию с актуальной позиции:

# 1. Снятие горячего бэкапа с мастера утилитой xtrabackup:
xtrabackup --backup --target-dir=/backup/xtra_master/ -u root -p

# 2. Подготовка бэкапа:
xtrabackup --prepare --target-dir=/backup/xtra_master/

# 3. Передача и развертывание на слейве с автоматическим сохранением точной позиции binlog/GTID в xtrabackup_info:
# xtrabackup --copy-back --target-dir=/backup/xtra_master/

Сценарий 4: Настройка безопасного срока хранения бинарных логов на мастере

Чтобы мастер больше никогда не удалял логи раньше, чем их вычитает реплика:

# В конфигурационном файле my.cnf на Мастере:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
# Хранить логи не менее 7 дней (в секундах: 7 * 86400 = 604800):
binlog_expire_logs_seconds = 604800
max_binlog_size = 1G

Типовые ошибки администраторов

• Ручное удаление файлов mysql-bin.* через rm: Файлы удаляются с диска, но остаются в индексе mysql-bin.index, что вызывает краш при попытке ротации логов. Удаляйте логи ТОЛЬКО через PURGE BINARY LOGS.
• Слишком короткий таймаут хранения binlog при медленном сетевом канале репликации: Если реплика отстает на сутки из-за медленного канала, а логи удаляются через 12 часов, репликация будет регулярно ломаться по ошибке 1236.