6.10. Resolución de problemas de replicación

MySQL 5.0

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 . Si lo está, no es cero. Si no, verifique que está ejecutando el maestro con las opciones y .

  • ¿Está corriendo el esclavo? Use para chequear si los valores y son . 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 , encuentre los flujos de entrada/salida y SQL y chequee su columna 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 , 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 .

    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 = ;
      mysql> START SLAVE;
      

      El valor de debe ser 1 si el siguiente comando del maestro no usa o . De otro modo, el valor debe ser 2. La razón para usar un valor de 2 para comandos que usen or¡ 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.