Как изменить MySQL предыдущего ведомого, чтобы быть ведущим и удалить информацию о статусе ведомого?

10

У меня есть конфигурация master -> slave, где master вышел из строя. Я был в состоянии вернуть старого раба, чтобы он был хозяином, а старого мастера - рабом. Хорошо.

Похоже, я не могу удалить основную информацию о старом-подчиненном, который теперь является новым-главным. Понимаю:

mysql> show slave status \G
*************************** 1. row ***************************
           Slave_IO_State: 
              Master_Host: 10.1.2.101
              Master_User: replicationSlave
              Master_Port: 3306
              ...
              Slave_IO_Running: No
              Slave_SQL_Running: No

Я прочитал много документации по MySQL, но до сих пор не нашел способа очистить ведомую информацию от нового мастера. Я пробовал:

  1. RESET SLAVEкоторый, кажется, не очищает эти настройки. [[На самом деле он удаляет master.infoфайл, но не настройки памяти. Увидеть ниже.]]
  2. CHANGE MASTER TO MASTER_HOST='' которая просто плюет на ошибку, так как она устарела недавно.
  3. Проверка того, у my.cnfкого нет основной информации, поскольку они были добавлены программно.
  4. RESET MASTERпотому что некоторые документы по MySQL рекомендовали это. Это только сбрасывает журналы бен.
  5. Изучение внутренних таблиц MySQL, чтобы увидеть, могу ли я найти поля для очистки.

Как правильно сделать это на MySQL ~ 5.5.9? Спасибо за любую помощь.


Редактировать:

Так что получается, что RESET SLAVEудаляет master.infoфайл, как подразумевается @RolandoMySQLDBA. Однако вам все равно нужно перезапустить сервер, прежде чем ведомая информация будет удалена.

Есть ли способ удалить эту ведомую информацию без перезапуска mysqld?

Серый - ТАК перестань быть злым
источник
Относится
Серый - ТАК перестань быть злым

Ответы:

10

В MySQL 5.5.16 и более поздних версиях вы можете использовать RESET SLAVE ALLвсе, что RESET SLAVEделает, и сбрасывать параметры соединения из памяти, таким образом, это не требует перезапуска mysqld.

Филипе Джусти
источник
6

Самый быстрый и самый грязный способ очистить ведомую информацию от экземпляра MySQL

  • Добавить skip-slave-startв /etc/my.cnf под[mysqld]
  • service mysql stop
  • rm -f /var/lib/mysql/master.info /var/lib/mysql/relay-*
  • service mysql start
  • Удалить skip-slave-startиз /etc/my.cnf

Это должно сделать это для вас!

Это было бы необходимо, потому что согласно документации MySQLRESET SLAVE :

В MySQL 5.5 (в отличие от случая в MySQL 5.1 и более ранних версиях) RESET SLAVE не изменяет никакие параметры подключения репликации, такие как главный хост, главный порт, главный пользователь или главный пароль, которые сохраняются в памяти. Это означает, что START SLAVE может быть выдан без запроса оператора CHANGE MASTER TO после RESET SLAVE.

Таким образом, информация о репликации все еще находится в памяти. Перезапуск MySQL - единственный путь.

RolandoMySQLDBA
источник
Спасибо @Rolando. +1 Я видел это, но не пробовал. Я пытаюсь не перезапускать mysqld, чтобы это исправить.
Серый - ТАК перестань быть злым
Кроме того, я не вижу никаких master.infoфайлов. Всегда ли это на «хозяине» или «рабе»?
Серый - ТАК перестань быть злым
master.info всегда на подчиненном сервере.
Абдул Манаф
5

RESET SLAVEпоследующий перезапуск не очищает информацию о ведомом устройстве, если это касается phpmyadmin. Вы также должны установить CHANGE MASTER TO MASTER_HOST=''.

Джек
источник
3

Я бы порекомендовал сохранить команду skip-slave-start в вашем конфигурационном файле ('in /etc/my.cnf') в вашем 'mysqld', чтобы избежать переопределения данных master-slave. Чтобы дать вам пример - при работе в облачной среде, скажем, старый мастер выходит из строя, а затем успешно перезапускается, когда ваш провайдер устраняет любую проблему - старый ведомый (теперь новый мастер) будет реплицироваться со старого мастера, переопределяя данные перед администратор базы данных имеет возможность понять это.

Кстати, это также актуально в не облачной среде. Если, скажем, другой администратор вызывает старого мастера без координации. Кроме того, еще одна проблема, почему рекомендуется поддерживать команду «skip-slave-start», даже если она является ведомой, - нет автоматической репликации, а это означает, что у вас больше контроля над предотвращением непредсказуемых результатов. :)

Лена Вебер
источник
Спасибо за ответ @ Лена. Это хорошая идея. Я посмотрю на это.
Серый - ТАК перестань быть злым