Skip navigation links
MySQL 5.0 Reference Manual :: 6 Replicación en MySQL :: 6.10 Resolución de problemas de replicación
6.11 Reportar bugs de replicación »
Section Navigation      [Toggle]

6.10. Resolución de problemas de replicación

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 opciones log-bin y server-id .

  • ¿Está corriendo el esclavo? Use SHOW SLAVE STATUS para chequear si los valores Slave_IO_Running y Slave_SQL_Running son Yes. 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 columna State 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 dice Connecting 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:

    1. 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.

    2. 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.

    3. 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 usa AUTO_INCREMENT o LAST_INSERT_ID(). De otro modo, el valor debe ser 2. La razón para usar un valor de 2 para comandos que usen AUTO_INCREMENT or¡ LAST_INSERT_ID() es que toman dos eventos en el log binario del maestro.

    4. 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.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.