☰

Diagnóstico de problemas de replicación de MySQL

tag-icon • tag-icon mysql mysql-replication
Diagnóstico de problemas de replicación de MySQL

Tenemos un cliente de replicación MySQL ejecutándose en nuestro servidor de respaldo. Desde un corte de energía la semana pasada, dejó de replicarse. Antes de esto estuvo funcionando ininterrumpidamente durante varios meses.

Intenté reiniciar tanto el maestro como el esclavo, pero esto no ayudó. 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 intentar 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 iban a daemon.log, no a mysql.err, lo que explicaría por qué no pude encontrarlos. El problema parece ser que el maestro dice que el registro no está disponible, lo cual 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

Respuesta1

Bienvenido al maravilloso mundo de la replicación de MySQL. No he abordado tu problema particular, pero sí he encontrado muchos otros problemas extraños y la solución aproximada es simplemente resincronizar desde el maestro como si fuera un esclavo nuevo y terminar de una vez.

Respuesta2

Deberías examinar el registro de errores del esclavo; normalmente es bastante explícito acerca de cuál es el problema.

Debería tener los registros de errores de MySQL vinculados a su sistema de monitoreo; de lo contrario, sus esclavos son potencialmente inútiles.

Además, debería tener un monitor que compruebe el estado del esclavo.

Y para que sea de alguna utilidad, también querrás verificar la sincronización de los esclavos de vez en cuando, tal vez usando algo como mk-table-checksum; Lo ideal sería vincular los resultados de eso también con su sistema de monitoreo.

Respuesta3

Mucha gente configura skip-slave-start para asegurarse de que todo esté bien si un esclavo deja de replicarse antes de iniciarlo. Intente ejecutar 'iniciar esclavo' y vea si algo cambia o si se registra algo. Además, es extraño que el proceso SlaveSQL se esté ejecutando y SlaveIO no. Es posible que los registros de retransmisión local en el esclavo se hayan dañado.deberíaser reportado en los registros. Puede intentar desactivar Mysql y luego eliminar los registros de retransmisión.

Respuesta4

En el informe anterior encontré el problema, este campo debe configurarse en (Slave_IO_Running): sí, pero en el informe anterior se muestra Slave_IO_Running: No.

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

Para solucionar este problema, detenga el esclavo.

Luego establezca:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

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

Luego reinicie el esclavo y verifique los registros. Con la esperanza de que esto solucione el problema...

información relacionada