19.5.4 Troubleshooting Replication — MySQL 8.4

19.5.4 Устранение неполадок репликации

Если вы выполнили инструкции, но ваша настройка репликации не работает, в первую очередь необходимо проверить журнал ошибок на наличие сообщений. Многие пользователи теряют время, не сделав этого достаточно быстро после обнаружения проблем.

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

Убедитесь, что на источнике включен бинарный лог, выполнив SHOW BINARY LOG STATUS оператор. Бинарный лог включен по умолчанию. Если бинарный лог включен, Position не равно нулю. Если бинарный лог не включен, проверьте, что вы не запускаете источник с настройками, которые отключают бинарный лог, например, с опцией --skip-log-bin.
Убедитесь, что системная переменная server_id была установлена во время запуска на источнике и реплике и что значение идентификатора уникально на каждом сервере.
Убедитесь, что реплика запущена. Используйте SHOW REPLICA STATUS, чтобы проверить, что значения Replica_IO_Running и Replica_SQL_Running оба равны Yes. Если нет, проверьте опции, которые использовались при запуске сервера реплики. Например, --skip-replica-start предотвращает запуск потоков репликации до тех пор, пока вы не выполните START REPLICA оператор.
Если реплика запущена, проверьте, установлено ли соединение с источником. Используйте SHOW PROCESSLIST, найдите потоки ввода-вывода (приемник) и SQL (применитель) и проверьте столбец State, чтобы увидеть, что они отображают. См. Раздел 19.2.3, «Потоки репликации». Если состояние потока приемника говорит Connecting to master, проверьте следующее:
- Проверьте привилегии пользователя репликации на источнике.
- Проверьте, правилен ли имя хоста источника и используете ли вы правильный порт для подключения к источнику. Порт, используемый для репликации, такой же, как и используемый для сетевого взаимодействия с клиентом (по умолчанию 3306). Для имени хоста убедитесь, что оно разрешается в правильный IP-адрес.
- Проверьте конфигурационный файл, чтобы увидеть, включена ли системная переменная skip_networking на источнике или реплике для отключения сетевого взаимодействия. Если это так, прокомментируйте или удалите настройку.
- Если у источника есть брандмауэр или конфигурация фильтрации IP, убедитесь, что сетевой порт, используемый MySQL, не фильтруется.
- Проверьте, можете ли вы подключиться к источнику, используя ping или traceroute/tracert для достижения хоста.
Если реплика работала ранее, но остановилась, причина обычно заключается в том, что какой-то оператор, который успешно выполнился на источнике, потерпел неудачу на реплике. Этого никогда не должно происходить, если вы создали надлежащий снимок источника и не изменяли данные на реплике за пределами потоков репликации. Если реплика неожиданно останавливается, это ошибка, или вы столкнулись с одним из известных ограничений репликации, описанных в Разделе 19.5.1, «Возможности и проблемы репликации». Если это ошибка, см. Раздел 19.5.5, «Как сообщать об ошибках или проблемах с репликацией» для получения инструкций по их сообщению.
Если оператор, который успешно выполнился на источнике, отказывается выполняться на реплике, попробуйте следующую процедуру, если полная ресинхронизация базы данных путем удаления баз данных реплики и копирования нового снимка с источника невозможна:
1. Определите, отличается ли затронутая таблица на реплике от таблицы на источнике. Попробуйте понять, как это произошло. Затем сделайте таблицу реплики идентичной таблице источника и выполните START REPLICA.
2. Если предыдущий шаг не работает или не применим, попробуйте понять, безопасно ли выполнить обновление вручную (при необходимости), а затем пропустить следующий оператор с источника.
3. Если вы решили, что реплика может пропустить следующий оператор с источника, выполните следующие операторы:
```
mysql> SET GLOBAL sql_replica_skip_counter = N;
mysql> START REPLICA;
```
  Значение N должно быть 1, если следующий оператор с источника не использует AUTO_INCREMENT или LAST_INSERT_ID(). В противном случае значение должно быть 2. Причина использования значения 2 для операторов, которые используют AUTO_INCREMENT или LAST_INSERT_ID(), заключается в том, что они занимают два события в бинарном логе источника.
4. Если вы уверены, что реплика изначально была идеально синхронизирована с источником и никто не обновлял вовлеченные таблицы за пределами потоков репликации, то, вероятно, расхождение является результатом ошибки. Если вы используете последнюю версию MySQL, пожалуйста, сообщите о проблеме. Если вы используете более старую версию, попробуйте обновить до последней производственной версии, чтобы определить, сохраняется ли проблема.