La replicación de MySQL falla con el error "No se pudo analizar la entrada del evento de registro de retransmisión".

Question

He buscado a fondo en google una solución definitiva o un conjunto de pasos para resolver este problema, pero parece que no hay muchos resultados de alta calidad, y no he encontrado la pregunta sobre el desbordamiento de la pila. Estamos tratando de configurar la replicación de MySQL usando un esclavo. El esclavo parece estar replicando bien y se produce el siguiente error:

No se pudo analizar la entrada del evento de registro de retransmisión. Las posibles razones son: el registro binario del maestro está dañado (puede verificarlo ejecutando 'mysqlbinlog' en el registro binario), el registro de retransmisión del esclavo está dañado (puede verificarlo ejecutando 'mysqlbinlog' en el registro de retransmisión), un problema de red, o un error en el código MySQL del maestro o esclavo. Si desea verificar el registro binario del maestro o el registro de retransmisión del esclavo, podrá conocer sus nombres emitiendo 'SHOW SLAVE STATUS' en este esclavo.

Con el fin de beneficiar a la gran cantidad de personas que inevitablemente tropezar con esta pregunta de una búsqueda, sería de gran ayuda si alguien que responde proporciona una visión general de lo que podría ir mal y los pasos a seguir para resolver este problema, pero también proporcionaré más detalles a continuación relacionados con mi situación particular con la esperanza de que alguien pueda ayudarme a resolverlo.

---

El volcado que se importaron en el esclavo para ponerlo en marcha se ha creado usando el siguiente comando en el maestro:

mysqldump --opt --allow-keywords -q -uroot -ppassword dbname > E:\Backups\dbname.sql 

La secuencia de comandos que realiza esta copia de seguridad también registra la posición de registro binario actual del maestro . A continuación, tomó los siguientes pasos para iniciar la replicación en el esclavo:

1. STOP SLAVE; 
2. DROP DATABASE dbname; 
3. SOURCE dbname.sql; 
    (... waited a few hours for the 10gb dump to import) 
4. RESET SLAVE; 
5. CHANGE MASTER TO MASTER_HOST='[masterhostname]', MASTER_USER='[slaveusername]', MASTER_PASSWORD='[slaveuserpassword]', MASTER_PORT=[port], MASTER_LOG_FILE='[masterlogfile]', MASTER_LOG_POS=[masterlogposition]; 
6. START SLAVE; 

Después de un día de la replicación funciona bien, no logró de nuevo a las 3:43 AM. Lo primero que apareció en el registro de errores de MySQL fue el error anterior. Entonces apareció otro error genérico después con la misma marca de tiempo:

Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log '[masterlogfile]' position [masterlogpos] 

Para obtener más información de registro, que había establecido una secuencia de comandos por lotes para ejecutar "SHOW SLAVE STATUS" y "espectáculo lleno PROCESSLIST" cada hora. Éstos son los resultados antes y después del fracaso:

--Monitoring: 3:00:00.15 

Slave Status: 
*************************** 1. row *************************** 
      Slave_IO_State: Waiting for master to send event 
       Master_Host: 192.168.xxx.xxx 
       Master_User: slave_user 
       Master_Port: xxxx 
       Connect_Retry: 60 
      Master_Log_File: mysql-bin.000xxx 
     Read_Master_Log_Pos: 316611912 
      Relay_Log_File: dbname-relay-bin.00000x 
       Relay_Log_Pos: 404287513 
     Relay_Master_Log_File: mysql-bin.000xxx 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: Yes 
      Replicate_Do_DB: dbname 
     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: 316611912 
      Relay_Log_Space: 404287513 
      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: 0 

*************************** 1. row *************************** 
    Id: 98 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 60547 
    State: Waiting for master to send event 
    Info: NULL 
*************************** 2. row *************************** 
    Id: 99 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 5 
    State: Has read all relay log; waiting for the slave I/O thread to update it 
    Info: NULL 
*************************** 3. row *************************** 
    Id: 119 
    User: root 
    Host: localhost:xxxx 
    db: NULL 
Command: Query 
    Time: 0 
    State: NULL 
    Info: SHOW FULL PROCESSLIST 

--Monitoring: 4:00:02.71 

Slave Status: 
*************************** 1. row *************************** 
      Slave_IO_State: Waiting for master to send event 
       Master_Host: 192.168.xxx.xxx 
       Master_User: slave_user 
       Master_Port: xxxx 
       Connect_Retry: 60 
      Master_Log_File: mysql-bin.000xxx 
     Read_Master_Log_Pos: 324365637 
      Relay_Log_File: dbname-relay-bin.00000x 
       Relay_Log_Pos: 410327741 
     Relay_Master_Log_File: mysql-bin.000xxx 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: No 
      Replicate_Do_DB: dbname 
     Replicate_Ignore_DB: 
     Replicate_Do_Table: 
    Replicate_Ignore_Table: 
    Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
       Last_Errno: 0 
       Last_Error: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. 
       Skip_Counter: 0 
     Exec_Master_Log_Pos: 322652140 
      Relay_Log_Space: 412041238 
      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 *************************** 
    Id: 98 
    User: system user 
    Host: 
    db: NULL 
Command: Connect 
    Time: 64149 
    State: Waiting for master to send event 
    Info: NULL 
*************************** 2. row *************************** 
    Id: 122 
    User: root 
    Host: localhost:3029 
    db: NULL 
Command: Query 
    Time: 0 
    State: NULL 
    Info: SHOW FULL PROCESSLIST 

me trataron siguiendo las instrucciones del error y corrieron mysqlbinlog el log retardado del esclavo con un start_position miles de declaraciones antes, y stop_position miles de declaraciones después de que el punto de falla, y redirigió el resultado a un archivo de texto. No vi ningún error de corrupción en la línea de comandos o en el archivo de registro. Esto es lo que dice el archivo de registro alrededor del punto de fallo:

... 
# at 410327570 
#120816 3:43:26 server id 1 log_pos 322651969 Intvar 
SET INSERT_ID=3842697; 
# at 410327598 
#120816 3:43:26 server id 1 log_pos 322651997 Query thread_id=762340 exec_time=0 error_code=0 
SET TIMESTAMP=1345113806 
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation"); 
# at 410327741 
#120816 3:44:26 server id 1 log_pos 322754486 Intvar 
SET INSERT_ID=3842701; 
# at 410327769 
#120816 3:43:26 server id 1 log_pos 322754514 Query thread_id=762340 exec_time=0 error_code=0 
SET TIMESTAMP=1345113866; 
insert into LOGTABLENAME (UpdateDate, Description) values (now(), "Invalid floating point operation"); 
# at 410327912 
... 

interesante que se tala una operación de punto flotante no válida en ese momento, pero no estoy seguro de cómo eso podría causar la replicación de romper en esa posición. Ejecuté mysqlbinlog en el registro binario del maestro encontrado en SHOW SLAVE STATUS desde arriba, y no vi ningún error en la línea de comandos (pero no tuve la oportunidad de abrir el archivo de registro de 100mb que se generó porque no quería atiborrarme abajo del servidor de producción).

Así que ahora mismo no sé qué más probar. Básicamente, solo estoy buscando información sobre lo que podría estar yendo mal o alguna sugerencia sobre qué pasos dar a continuación. ¡Gracias!

Answer 1

No estoy seguro de cuál es la causa principal.Sin embargo, para recuperarse de esta situación, que te gustaría instruir a MySQL para borrar todos los relé-bin-logs más allá del punto siguiente

• Relay_Master_Log_File: mysql-bin.000xxx
• Exec_Master_Log_Pos: 322652140

de la siguiente manera:

STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000xxx', MASTER_LOG_POS = 322652140; START SLAVE;

NOTA: Para los lectores, no se confundan con Relay_Master_Log_File, NO es lo mismo que Read_Master_Log_Pos. Y no confundas Exec_Master_Log_Pos con Read_Master_Log_Pos. Read_ * es una estrategia de lectura anticipada que MySQL hace para descargar los registros del bin de replicación desde el maestro antes de la implementación real de la replicación que se ejecuta localmente.