Pregunta Diagnóstico de problemas de replicación Mysql


Tenemos un cliente de replicación mysql que se ejecuta en nuestro servidor de respaldo. Desde un corte de energía la semana pasada, se detuvo la replicación. Antes de esto estuvo funcionando ininterrumpidamente durante varios meses.

He intentado reiniciar el maestro y el esclavo, pero esto no ha ayudado. Puedo acceder al servidor maestro desde el esclavo, por lo que la red no es el problema.

¿Hay algo más que pueda hacer para tratar de diagnosticar cuál es el problema?

mysql> show slave status\G;
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: master
                Master_User: username
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.000060
        Read_Master_Log_Pos: 46277494
             Relay_Log_File: mysqld-relay-bin.000348
              Relay_Log_Pos: 98
      Relay_Master_Log_File: mysql-bin.000060
           Slave_IO_Running: No
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 46277494
            Relay_Log_Space: 98
            Until_Condition: None
             Until_Log_File:
              Until_Log_Pos: 0
         Master_SSL_Allowed: No
         Master_SSL_CA_File:
         Master_SSL_CA_Path:
            Master_SSL_Cert:
          Master_SSL_Cipher:
             Master_SSL_Key:
      Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

ERROR:
No query specified


mysql> show master status\G;
*************************** 1. row ***************************
            File: mysql-bin.000069
        Position: 851796
    Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

ERROR:
No query specified

Actualización: los errores se estaban introduciendo en daemon.log, no en mysql.err, lo que explicaría por qué no podía encontrarlos. El problema parece ser que el maestro dice que el registro no está disponible, lo que no tiene mucho sentido, porque ese registro (y el anterior) todavía están disponibles en el maestro.

090710  9:17:35 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000060' at position 46277494, relay log './mysqld-relay-bin.000350' position: 98
090710  9:17:35 [Note] Slave I/O thread: connected to master 'username@master:3306',  replication started in log 'mysql-bin.000060' at position 46277494
090710  9:17:35 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090710  9:17:35 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090710  9:17:35 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000060', position 46277494

4
2017-07-10 03:11


origen


Solo para tu información, no necesitas usar un punto y coma al terminar con \ G. Es por eso que tiene errores extraños "No se especificó la consulta" en su salida. - Dan Carley


Respuestas:


Bienvenido al maravilloso mundo de la replicación de MySQL. No he abordado tu problema en particular, pero sí he encontrado muchos otros problemas extraños y la solución más cercana es volver a sincronizar con el maestro como si fuera un esclavo nuevo y terminar con él.


6
2017-07-10 08:30



Sí, eso es lo que siempre he hecho en el pasado ... pensé que vería si realmente pudiera resolver el problema esta vez;) - theotherreceive
La vida es demasiado corta para preocuparse exactamente por qué MySQL ha decidido arruinar tu fin de semana en este momento en particular. Sólo tienes que patearlo y volver a la película. - womble♦
Sí, al final tuve que ceder y hacer esto. - theotherreceive
Hice este problema en el pasado. Después de meditar demasiado y de una cantidad de café casi ilegal, también decidí darle una patada y volver a la película. Si uno termina en el Infierno y se convierte en un DBA allí, probablemente será un Especialista en Soluciones de Replicación de MySQL. Eso es lo que la replicación de MySQL puede chupar CUANDO decide patear a tus tuercas. - Janne Pikkarainen


Debería examinar el registro de errores del esclavo, ya que suele ser bastante explícito sobre cuál es el problema.

Debes tener los registros de errores de mysql vinculados a tu sistema de monitoreo, de lo contrario tus esclavos no tienen ningún valor.

Además, debes tener un monitor que verifique el estado del esclavo.

Y para que sea de alguna utilidad, también querrá comprobar la sincronización de los esclavos de vez en cuando, quizás utilizando algo como mk-table-checksum; Lo ideal es vincular los resultados de eso a su sistema de monitoreo también.


2
2017-07-10 03:27



No hay nada registrado, a menos que me falte una configuración para activar un mayor registro. - theotherreceive


Muchas personas configuran skip-slave-start para asegurarse de que todo está bien si un esclavo deja de replicarse antes de iniciarlo. Intente ejecutar 'iniciar esclavo' y ver si algo cambia o si algo se registra. Además, es extraño que el proceso SlaveSQL se esté ejecutando y el SlaveIO no. Es posible que los registros de retransmisión locales en el esclavo se hayan dañado, aunque debería ser informado en los registros. Puede intentar bajar Mysql y luego eliminar los registros de retransmisión.


2
2017-07-10 03:56



Intenté 'detener esclavo' y 'iniciar esclavo', probablemente debería haberlo aclarado en mi pregunta. Intenté tu sugerencia de borrar los registros de retransmisión, pero después de eso se negó a iniciar el esclavo esclavo nuevamente. Aunque todavía no parece estar registrando ningún error. - theotherreceive
hmmm estoy empezando a quedarme sin ideas. Un par de otras cosas simples para mirar. Asegúrese de que su disco no esté lleno. Asegúrese de que ./mysql/ es propiedad de mysql: mysql (o lo que sea que esté en su sistema). Compruebe mysqld.err y no solo mysql.log si aún no lo ha hecho. La mayoría de ellos son simples, pero deberían eliminar cualquier rareza general. - kashani
Tenga mucho cuidado al borrar los registros de retransmisión. Si ha estado fuera de sincronía con el maestro durante un tiempo prolongado, existe la posibilidad de que el maestro ya no tenga los registros binarios relacionados con la información de retransmisión eliminada. Vuelva a comprobar primero. - Dan Carley


Como ha mencionado womble, olvídate de la solución de problemas de errores de replicación. Lo que más me preocupa de este enfoque es que podría lograr que la replicación se reinicie de nuevo y piense que todo está bien, pero ¿y si algunas partes de su base de datos aún no están sincronizadas?

Lo mejor es destruir la base de datos esclava y reiniciar la replicación desde una instantánea del maestro. No debería ser tan disruptivo como podría pensar:

http://www.neotitans.com/resources/mysql/quick-replication-error-recovery-via-snapshots.html


2
2017-08-02 09:25





Desde el informe anterior encontré el problema, esta configuración debe estar configurada en (Slave_IO_Running): sí, pero en el informe anterior se muestra Slave_IO_Running: No.

Eso está causando el problema, si esta variable lee 'No', entonces el hilo IO se detuvo. así que ya no hay replicación. Tendrá que consultar Last_SQL_Errno y Last_SQL_Err para obtener más información sobre la causa. Un número de error de 0 y el mensaje de la cadena vacía significan "sin error". El Last_SQL_Error aparece en el registro de errores del esclavo.

Para solucionar este problema, detener el esclavo

Luego establece:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

Esto le indica al esclavo que omita una consulta (que es la no válida que hizo que la replicación se detuviera). Si desea omitir dos consultas, debe usar SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; en cambio y así sucesivamente.

Luego reinicie el esclavo y verifique los registros. Esperando que esto solucione el problema ...


1
2017-09-16 12:43