Si ha seguido las instrucciones, y su configuración de replicación no funciona, chequee lo siguiente:
-
Chequee el log de errores en busca de mensajes. Muchos usuarios han perdido tiempo por no hacer esto lo primero tras encontrar problemas.
-
¿Está logueando el maestro en el log binario? Chequee con
SHOW MASTER STATUS
. Si lo está,Position
no es cero. Si no, verifique que está ejecutando el maestro con las opcioneslog-bin
yserver-id
. -
¿Está corriendo el esclavo? Use
SHOW SLAVE STATUS
para chequear si los valoresSlave_IO_Running
ySlave_SQL_Running
sonYes
. Si no , verfique las opciones que se usaron para arrancar el esclavo. -
Si el esclavo está corriendo, ¿estableció una conexión con el maestro? Use
SHOW PROCESSLIST
, encuentre los flujos de entrada/salida y SQL y chequee su columnaState
para ver qué muestran .Consulte Sección 6.3, “Detalles de la implementación de la replicación”. Si el estado flujo de entrada/salida diceConnecting to master
, verifique los permisos para los usuarios de replicación en el maestro, nombre de equeipo, la configuración del DNS, si el maestro está corriendo y si se puede acceder desde el esclavo. -
Si el esclavo estaba corriendo préviamente pero ha parado, la razón habitual es que algunos comandos que se han ejectuado en el maestro han fallado en el esclavo. Esto nunca debe ocurrir si ha tomado muestras de datos apropiadas del maestro, y no ha modificado los datos en el esclavo fuera del flujo del esclavo. Si lo ha hecho, es un bug o ha encontrado una de las limitaciones de replicación descritas en Sección 6.7, “Características de la replicación y problemas conocidos”. Si es un bug, consulte Sección 6.11, “Reportar bugs de replicación” para instrucciones de cómo reportarlo.
-
Si un comando que ha tenido exito en el maestro no se ejecuta en el esclavo, y no es posible resincronizar la base de datos completa (esto es, borrar la base de datos del esclavo y copiar una nueva muestra del maestro), pruebe lo siguiente:
-
Determine si la tabla del esclavo es distinta a la del maestro. Trate de entender cómo ha ocurrido. Luego haga que la tabla del esclavo sea idéntica a la del maestro y ejecute
START SLAVE
. -
Si el paso precedente no funciona o no se aplica, trate de entender si sería seguro hacer una actualización manual (si es necesario) y luego ignorar el siguiente comando del maestro.
-
Si decide que puede evitar el siguiente comando del maestro, ejecute los siguientes comandos:
mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER =
n
; mysql> START SLAVE;El valor de
n
debe ser 1 si el siguiente comando del maestro no usaAUTO_INCREMENT
oLAST_INSERT_ID()
. De otro modo, el valor debe ser 2. La razón para usar un valor de 2 para comandos que usenAUTO_INCREMENT
or¡LAST_INSERT_ID()
es que toman dos eventos en el log binario del maestro. -
Si está seguro que el esclavo arrancó perfectamente sincronizado con el maestro, y que nadie ha actualizado las tablas involucradas fuera del flujo esclavo, entonces presumiblemente la discrepancia es producto de un bug. Si está ejecutando la versión más reciente, reporte el problema. Si está ejecutando una versión antigua de MySQL, trate de actualizar a la última versión.
-