16.4.4 Troubleshooting Replication — MySQL 5.7

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

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

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

Убедитесь, что на источнике включен двоичный лог, выполнив оператор SHOW MASTER STATUS. Если ведение лога включено, Position не равно нулю. Если двоичный лог не включен, убедитесь, что сервер источника запущен с опцией --log-bin.
Убедитесь, что системная переменная server_id была установлена при запуске как на источнике, так и на реплике, и что значение идентификатора уникально на каждом сервере.
Убедитесь, что реплика запущена. Используйте SHOW SLAVE STATUS для проверки, являются ли значения Slave_IO_Running и Slave_SQL_Running равными Yes. Если нет, проверьте опции, которые использовались при запуске сервера реплики. Например, --skip-slave-start препятствует запуску потоков реплики до тех пор, пока не будет выполнен оператор START SLAVE.
Если реплика запущена, проверьте, установила ли она соединение с источником. Используйте SHOW PROCESSLIST, найдите потоки ввода-вывода и SQL, и проверьте их столбец State, чтобы увидеть, что они отображают. См. Раздел 16.2.3, «Потоки репликации». Если состояние потока ввода-вывода репликации указывает на Connecting to master, проверьте следующее:
- Проверьте права пользователя, используемого для репликации на источнике.
- Проверьте, правильное ли имя хоста источника и используете ли вы правильный порт для подключения к источнику. Порт, используемый для репликации, такой же, как используется для клиентского сетевого взаимодействия (по умолчанию — 3306). Для имени хоста убедитесь, что оно разрешается в правильный IP-адрес.
- Проверьте конфигурационный файл, чтобы убедиться, что системная переменная skip_networking не была включена на источнике или реплике для отключения сетевого взаимодействия. Если это так, прокомментируйте или удалите настройку.
- Если на источнике есть брандмауэр или конфигурация фильтрации IP-адресов, убедитесь, что сетевой порт, используемый для MySQL, не отфильтрован.
- Проверьте, можете ли вы подключиться к источнику, используя ping или traceroute/tracert для достижения хоста.
Если реплика работала ранее, но остановилась, причина обычно заключается в том, что какое-то утверждение, успешно выполненное на источнике, не удалось на реплике. Этого никогда не должно происходить, если вы сделали правильный снимок источника и не изменяли данные на реплике вне потоков репликации. Если реплика неожиданно останавливается, это ошибка, или вы столкнулись с одним из известных ограничений репликации, описанных в Разделе 16.4.1, «Функции и проблемы репликации». Если это ошибка, см. Раздел 16.4.5, «Как сообщать об ошибках или проблемах с репликацией», чтобы узнать, как её сообщить.
Если утверждение, успешно выполненное на источнике, отказывается выполняться на реплике, попробуйте следующую процедуру, если не представляется возможным выполнить полную ресинхронизацию базы данных, удалив базы данных реплики и скопировав новый снимок с источника:
1. Определите, отличается ли затронутая таблица на реплике от таблицы на источнике. Попробуйте понять, как это произошло. Затем сделайте таблицу реплики идентичной таблице источника и выполните START SLAVE.
2. Если предыдущий шаг не сработал или не применим, попробуйте понять, безопасно ли выполнить обновление вручную (если необходимо) и затем пропустить следующее утверждение с источника.
3. Если вы решили, что реплика может пропустить следующее утверждение с источника, выполните следующие операторы:
```
mysql> SET GLOBAL sql_slave_skip_counter = N;
mysql> START SLAVE;
```
  Значение N должно быть 1, если следующее утверждение с источника не использует AUTO_INCREMENT или LAST_INSERT_ID(). В противном случае значение должно быть 2. Причина использования значения 2 для операторов, использующих AUTO_INCREMENT или LAST_INSERT_ID(), заключается в том, что они используют два события в двоичном журнале источника.
  
  См. также Раздел 13.4.2.4, «Синтаксис SET GLOBAL sql_slave_skip_counter».
4. Если вы уверены, что реплика изначально была полностью синхронизирована с источником и никто не обновлял вовлеченные таблицы вне потоков репликации, то, вероятно, расхождение является результатом ошибки. Если вы используете последнюю версию MySQL, сообщите об этой проблеме. Если вы используете более старую версию, попробуйте обновить до последней версии производственного выпуска, чтобы определить, сохраняется ли проблема.