MySQL: Реплика MySQL перестала применять события после сбоя

#Как проявляется проблема и где искать причину

После аварии источник MySQL может быть доступен, но реплика перестаёт применять изменения. Нужно отделить обрыв связи от ошибки SQL-потока и выяснить точный номер события, а не пропускать его автоматически.

#Пошаговая диагностика и устранение

1. 1. Убедитесь, что работаете именно на репликеПодключитесь к MySQL на реплике с учётной записью мониторинга. Проверьте сервер, версию и роль инстанса, чтобы не выполнять дальнейшие действия на источнике по ошибке.
2. mysql-клиент, чтение; идентификатор источника должен отличаться

   SQLКомандаКопировать всёВыделить

   mysql-клиент, чтение; идентификатор источника должен отличаться.

   SELECT @@hostname, @@server_uuid, VERSION();

1. 2. Получите состояние потоковДля MySQL 8.0.22+ и 8.4 выполните SHOW REPLICA STATUS\G в клиенте mysql; в более старых версиях возможен SHOW SLAVE STATUS\G. Найдите Replica_IO_Running, Replica_SQL_Running, Last_IO_Error и Last_SQL_Error.

   SQLКомандаКопировать всёВыделить

   Именно mysql CLI поддерживает разделитель \G; нужны права REPLICATION CLIENT.

   SHOW REPLICA STATUS\G

1. 3. Отличите проблему сети от примененияЕсли поток IO не получает данные, проверьте имя источника, доступность порта и авторизацию репликации по политике безопасности. Если IO=Yes, SQL=No, не тратьте время на DNS: прочитайте код Last_SQL_Errno и текст ошибки.

1. 4. Для параллельной репликации откройте ошибки исполнителейНа MySQL 8.0+ проверьте performance_schema.replication_applier_status_by_worker. Сопоставьте CHANNEL_NAME, WORKER_ID, LAST_ERROR_NUMBER и LAST_ERROR_MESSAGE; у каждого канала/потока может быть отдельная причина.
2. Чтение, требуется доступ к performance_schema; формат зависит от версии

   SQLКомандаКопировать всёВыделить

   Чтение, требуется доступ к performance_schema; формат зависит от версии.

   SELECT CHANNEL_NAME, WORKER_ID, LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE FROM performance_schema.replication_applier_status_by_worker;

1. 5. Сохраните состояние и резервную копиюПеред изменениями сохраните вывод статуса в закрытый журнал, снимок данных реплики согласованным способом и настройки GTID. Не копируйте пароль подключения, полученный из секретного хранилища. Определите, может ли реплика безопасно отставать во время диагностики.

1. 6. Исправьте конкретную первопричину в тестеПри ошибке отсутствующей таблицы/уникального ключа сравните схему и данные реплики с источником; при повреждении relay log — уточните стратегию восстановления из нового согласованного снимка. Не удаляйте строку вручную и не пропускайте транзакцию без подтверждения DBA.

1. 7. Возобновите применение только после решенияАдминистратор после исправления причины может выполнить START REPLICA, если состояние и координаты корректны. Нельзя запускать вслепую, когда данные разошлись или источник перезаписывался.

   SQLС осторожностьюКопировать всёВыделить

   Только DBA после проверки целостности; запускает потоки репликации.

   START REPLICA;

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

1. 8. Убедитесь, что данные действительно синхронизируютсяПовторите SHOW REPLICA STATUS, убедитесь, что потоки Yes, ошибок нет, а контрольная транзакция с источника появляется на реплике. Seconds_Behind_Source само по себе не гарантирует равенство данных.

#Как проверить результат

Реплика получает и применяет новые транзакции без ошибок; контрольные записи совпадают с источником, известное отставание уменьшается.

#Если исправление не помогло

Если источник и реплика расходятся по ключам/GTID, требуется согласованная пересборка реплики; не маскируйте расхождение пропуском событий.