Природа ошибки поиска ключа в строковой репликации (Row-Based Replication)

При использовании строчного формата бинарных логов (binlog_format = ROW) мастер-сервер передает на реплику точные образы изменяемых строк (Before-Image и After-Image). Когда поток применения событий (Slave SQL Thread / Applier Worker) получает оператор UPDATE или DELETE, он выполняет поиск целевой строки на реплике по ее первичному ключу. Если строка с таким первичным ключом физически отсутствует на реплике (например, была удалена вручную локальным запросом или не доехала из-за ранее пропущенной транзакции), поток репликации аварийно останавливается:

«Last_SQL_Error: Could not execute Update_rows event on table db.orders; Could not find record in 'orders', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000124, end_log_pos 54821»

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

Остановка отставания реплики (Replication Lag растет бесконечно), потеря отказоустойчивости кластера высокой доступности (High Availability failover невозможен), чтение устаревших данных с read-реплик.

Сравнение форматов логирования в MySQL Replication

Регламент восстановления и повторной синхронизации реплики

Сценарий 1: Локализация недостающей записи через утилиту mysqlbinlog

Определите, какую именно строку искал SQL-тред репликации:

# 1. Проверьте параметры сбойного события в SHOW SLAVE STATUS\G:
# Last_IO_Error / Last_SQL_Error: mysql-bin.000124, end_log_pos 54821

# 2. Декодируйте бинарный лог на мастере вокруг указанной позиции:
sudo mysqlbinlog -v -v --base64-output=DECODE-ROWS \
  --start-position=54000 --stop-position=55000 /var/lib/mysql/mysql-bin.000124

# Вы увидите точные значения полей недостающей строки в секции ### WHERE: 
# ### @1=10542 (id)
# ### @2='ivan@example.com'

Сценарий 2: Синхронизация данных с помощью Percona Toolkit (pt-table-sync)

Самый надежный способ устранения рассинхронизации без ручных вставок:

# 1. Установите Percona Toolkit:
sudo apt install -y percona-toolkit

# 2. Проверьте отличия в таблице между мастером и репликой (Dry-run):
pt-table-sync --print --sync-to-master h=slave_host,D=my_database,t=orders -u root -p

# 3. Автоматически выполните синхронизацию недостающих строк:
pt-table-sync --execute --sync-to-master h=slave_host,D=my_database,t=orders -u root -p

# 4. Запустите поток репликации на слейве:
mysql -u root -p -e "START SLAVE; SHOW SLAVE STATUS\G"

Сценарий 3: Ручная вставка фиктивной строки и пропуск транзакции (Экстренно)

Если требуется срочно возобновить репликацию:

-- 1. На реплике создайте временную фиктивную строку с ID, который ищет мастер:
INSERT INTO `orders` (`id`, `user_id`, `amount`) VALUES (10542, 1, 0.00);

-- 2. Запустите репликацию:
START SLAVE;

-- 3. Убедитесь, что реплика успешно выполнила UPDATE/DELETE и продолжила работу:
SHOW SLAVE STATUS\G

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

• Прямая запись на Slave-сервер: Выполнение запросов INSERT/UPDATE/DELETE пользователями напрямую на реплике — главная причина ошибки 1032. Реплика ВСЕГДА должна быть переведена в режим read_only = 1 и super_read_only = 1.
• Игнорирование повторных ошибок: Пропуск ошибок «вслепую» приводит к тому, что через месяц база данных на слейве будет содержать совершенно другие данные, делая бэкапы с реплики бесполезными.