Имеем кластер MySQL из 2 нод в конфигурации Master-Slave. Как восстановить репликацию, если slave не работает?
Шаг 1
- Сбрасываем мастер, блокируем таблицы, базу переводим в ридонли и проверяем статус мастера.
RESET MASTER; FLUSH TABLES WITH READ LOCK; SET GLOBAL READ_ONLY = ON
- В это время ходим на слейв и стопаем его запросом:
STOP SLAVE;
- После выполнения этих команд база станет недоступна для пользователей. Теперь забираем свежий бэкап базы, где имя пользователя и имя базы меняем на свои:
mysqldump -u root -p mydb > mydb-dump.sql
- Затем смотрим статус мастера командой:
SHOW MASTER STATUS G;
Здесь нас интересуют значения File и Position, которые необходимо записать/запомнить/оставить открытое окно терминала с этими значениями – они понадобятся нам далее.
Шаг 2
- Перемещаемся на слейв и забираем бэкап с мастера, заливаем его в БД (где имя пользователя и имя базы меняем на свои):
mysql -u root mydb < mydb-dump.sql
- Далее заходим в mysql и восстанавливаем работу Slave ($host – IP/хостнейм мастера, а $mysql-bin и $pos – значения File и Position, которые мы берём с мастера соответственно):
CHANGE MASTER TO MASTER_HOST=$host, MASTER_LOG_FILE='$mysql-bin', MASTER_LOG_POS=$pos; START SLAVE;
- Затем проверяем статус мастера запросом:
SHOW SLAVE STATUS G;
Убедившись, что значения Slave_IO_Running и Slave_SQL_Running равны Yes, смотрим на значение Exec_Master_Log_Pos. В это время на мастере смотрим на значение Position в выводе запроса SHOW MASTER STATUS G;. Ждём, когда оба значения станут одинаковыми и перестанут обновляться.
Шаг 3
- Когда указанные значения синхронизировались, идём на мастер и вытаскиваем БД из режима read-only, а также разблокируем таблицы
SET GLOBAL READ_ONLY = OFF; UNLOCK TABLES;
- После этого необходимо убедиться, что значения Slave_IO_Running и Slave_SQL_Running на слейве равны Yes и ошибок репликации нет. В этом случае работа кластера восстановлена корректно.
Оказываем услуги обслуживания и настройки кластеров MySQL DevOps-аутсорсинга!
