¿Cómo cambiar un esclavo anterior de MySQL para que sea un maestro y eliminar la información del estado del esclavo?

10

Tengo una configuración maestro -> esclavo donde el maestro falló. He podido restablecer el viejo esclavo para que sea un maestro y el viejo maestro para que sea esclavo de él. Multa.

Lo que parece que no puedo hacer es eliminar la información maestra del viejo esclavo que ahora es el nuevo maestro. Veo:

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

He leído mucha documentación de MySQL pero todavía no he encontrado una manera de borrar la información del esclavo del nuevo maestro. He intentado:

  1. RESET SLAVEque no parece borrar esa configuración. [[En realidad, elimina el master.infoarchivo pero no la configuración de memoria. Vea abajo.]]
  2. CHANGE MASTER TO MASTER_HOST='' que solo escupe un error ya que fue desaprobado recientemente.
  3. Comprobando my.cnfcuál no tiene la información maestra ya que se agregaron mediante programación.
  4. RESET MASTERporque algunos documentos de mysql lo recomiendan. Eso solo restablece los registros de bin.
  5. Hurgando en las tablas internas de MySQL para ver si puedo encontrar los campos para borrar.

¿Cuál es la forma correcta de hacer esto en MySQL ~ 5.5.9? Gracias por cualquier ayuda.


Editar:

Resulta que RESET SLAVEelimina el master.infoarchivo como implica @RolandoMySQLDBA. Sin embargo, aún necesita reiniciar el servidor antes de eliminar la información del esclavo.

¿Hay alguna forma de eliminar esta información esclava sin tener que reiniciar mysqld?

Gray: así que deja de ser malvado
fuente
Relacionado con dba.stackexchange.com/questions/12092/…
Gray - SO deja de ser malvado

Respuestas:

10

En MySQL 5.5.16 y posterior, puede RESET SLAVE ALLhacer todo lo que RESET SLAVEhace y restablecer los parámetros de conexión desde la memoria, de esta manera no requiere un reinicio de mysqld.

Filipe Giusti
fuente
6

La forma más rápida y sucia de borrar la información del esclavo de una instancia de MySQL

  • Añadir skip-slave-starta /etc/my.cnf bajo[mysqld]
  • service mysql stop
  • rm -f /var/lib/mysql/master.info /var/lib/mysql/relay-*
  • service mysql start
  • Eliminar skip-slave-startde /etc/my.cnf

¡Eso debería hacerlo por ti!

Esto sería necesario porque de acuerdo con la documentación de MySQL sobreRESET SLAVE :

En MySQL 5.5 (a diferencia del caso en MySQL 5.1 y versiones anteriores), RESET SLAVE no cambia ningún parámetro de conexión de replicación como host maestro, puerto maestro, usuario maestro o contraseña maestra, que se retienen en la memoria. Esto significa que START SLAVE puede emitirse sin requerir una declaración CHANGE MASTER TO después de RESET SLAVE.

Por lo tanto, la información de replicación todavía está en la memoria. Un reinicio de mysql es el único camino a seguir.

RolandoMySQLDBA
fuente
Gracias @Rolando. +1 Vi eso pero no lo intenté. Estoy tratando de no tener que reiniciar mysqld para solucionar esto.
Gray - SO deja de ser malvado
Además, no veo ningún master.infoarchivo. ¿Eso siempre está ahí en un "maestro" o "esclavo"?
Gray - SO deja de ser malvado
master.info siempre está en Slave Server.
Abdul Manaf
5

RESET SLAVEseguido de un reinicio no borra la información del esclavo en lo que respecta a phpmyadmin. También necesitas configurar CHANGE MASTER TO MASTER_HOST=''.

Jack
fuente
3

Recomendaría mantener el comando skip-slave-start en su archivo de configuración ('en /etc/my.cnf') debajo de 'mysqld' para evitar la anulación de los datos maestro-esclavo. Para darle un ejemplo: cuando trabaje en un entorno de nube, digamos que un viejo maestro se bloquea y luego se reinicia con éxito cuando su proveedor soluciona cualquier problema: el viejo esclavo (ahora nuevo maestro) se replicará desde el viejo maestro, anulando los datos antes el DBA tiene la oportunidad de darse cuenta de esto.

Por cierto, esto también es relevante en un entorno no en la nube. Si, digamos, otro administrador saca el viejo maestro sin coordinarlo. Además, otro problema es por qué es una buena idea mantener el comando 'skip-slave-start' incluso si es un esclavo, sin replicación automática, lo que significa que tiene más control sobre la prevención de resultados impredecibles. :)

Lena Weber
fuente
Gracias por la respuesta @Lena. Es una buena idea. Lo miraré.
Gray - DEJA de ser malvado