El registro de retransmisión de MySQL está dañado, ¿cómo lo soluciono? Intenté pero fallé

Un relé MySQL v5.1.61 se corrompió cuando la máquina se apagó repentinamente. Traté de arreglarlo pero no funcionó.
- ¿Cómo lo soluciono? ¿Hice algo mal?

Hasta donde he leído, los registros corruptos de retransmisión de MySQL se arreglan fácilmente:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

donde Relay_Master_Log_Filey Exec_Master_Log_Posestán listados por:
mysql> show slave status;

Sin embargo, cuando lo hice change master status ..., recibí un error de violación de clave principal. ¿Cómo es eso posible? ¿El procedimiento anterior no es correcto o, por ejemplo, falta algún +1?

_{(Por ahora simplemente he reimportado un --master-data mysqldump del maestro al esclavo, y esto resolvió el problema. Sin embargo, en el futuro, hacer eso podría no ser apropiado).}

Aquí sigue detalles sobre mi problema particular:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: 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: 66395191
              Relay_Log_Space: 36559177
              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
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: 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.

Y esto es lo que hice:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Y esto es lo que sucedió, un error de PK:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

Creo que seguí el procedimiento recomendado (vea los enlaces a continuación), aún hubo un error de PK :-(? Http://bugs.mysql.com/bug.php?id=26489 , busque "Soluciones". Http: //mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

Error: Last_SQL_Errno: 1594 Last_SQL_Error: error de lectura del registro de retransmisión: no se pudo analizar la entrada del evento de registro de retransmisión.

Este error significa que el archivo de registro maestro está dañado o el archivo de registro de retransmisión está dañado.

• Antes de hacer nada, haga una copia de seguridad de todas sus bases de datos, registros, servidores de imágenes, repítalas varias veces y continúe bajo su propio riesgo.

Primero ejecute "mostrar estado esclavo \ G" en el esclavo y observe:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

Primero queremos asegurarnos de que el archivo de registro maestro esté intacto, así que salte al servidor maestro y busque el archivo Relay_Master_Log_File (check / var / log / mysql) y ejecute el siguiente comando:

mysqlbinlog mysql-bin.000026

El registro se mostrará pero esperamos que no vea ningún mensaje de error. Si ve mensajes de error, los registros maestros están dañados y es probable que deba volver a crear una imagen.

Luego ejecute el mismo comando en el registro de retransmisión esclavo (a menudo en / var / lib / mysql)

mysqlbinlog mysqld-relay-bin.000056

Es probable que vea algunos errores que muestran la corrupción que ha detenido la replicación, como esta:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

Si ve algún error, entonces el registro está bien en el maestro y solo el registro de retransmisión del esclavo está dañado. Estas son buenas noticias, podemos reiniciar el esclavo y decirle los detalles del maestro y desde dónde continuar. Si no ve ningún error, deje de leer ahora, tiene un problema diferente.

Si el registro del relé esclavo tiene errores, ejecute los siguientes comandos para restablecer el esclavo y los registros corruptos se vuelven a conectar al maestro, obtenga los registros correctos y comience a esclavizar nuevamente. Tenga en cuenta que MASTER_LOG_POS es el Exec_Master_Log_Pos, y MASTER_LOG_FILE es el Relay_Master_Log_File( NO el primero, que coincide con los registros de retransmisión que se han recuperado y deben desecharse) desde el primer comando.

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

[Arreglando la replicación de MySQL después de que el registro de retransmisión de los esclavos estuviera dañado]

La replicación de MySQL en esclavo (versión 5.XX) se ha detenido. Slave_IO_Running se marcó como Sí, pero Slave_SQL_Running como No. El esclavo de detención / arranque simple no ayudó, por lo que se necesitaba un análisis más detallado del problema. Parecía que el registro de retransmisión del esclavo actual estaba dañado porque las pruebas con "mysqlbinlog" imprimieron un error. Por lo tanto, la solución fue descartar los binlogs del relé actual y apuntar el esclavo a la última posición del binlog maestro.

Para corregir el error, los archivos binlog actuales en el esclavo deben descartarse y establecer una nueva posición. Antes de establecer una nueva posición de binlog, es importante recordar los valores Relay_Master_Log_File y Exec_Master_Log_Pos del servidor esclavo dañado usando el comando SHOW SLAVE STATUS \ G :

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

OK, con estos valores, se puede establecer una nueva posición de binlog:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

Sólo tener en cuenta que reset slaveva a eliminar master.info, relay-log.infoy todos los archivos de registro del relé, así que no es necesario para las sobras limpias en /var/lib/mysqlel directorio.

Sé que ha pasado más de un año, pero esto es lo que puede haber sucedido con este problema en particular.

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Parece que eso debería haberlo solucionado porque eliminó el registro de retransmisión corrupto.

Entonces, recibiste un error PK 1062. ¿Por qué?

Hay un error sobresaliente ( http://bugs.mysql.com/bug.php?id=60847 ) que todavía está activo en MySQL 5.5

Aunque el error se relaciona con el uso de mysql --single-transaction --flush-logs, existe una peculiaridad relacionada.

He visto esa peculiaridad en algunos servidores EC2 que se ejecutan como esclavos para un cliente la semana pasada en MySQL 5.5.15

En el Master, había un extraño INSERT extendido de múltiples filas donde cada tupla que se insertaba era un SELECT. Lo que sucedió fue que el LAST_INSERT_ID en el registro de retransmisión, que forma el siguiente incremento automático para asignar, ya estaba en uso en el Esclavo debido a las inserciones de varias filas de antemano.

El INSERT serializado en el registro de retransmisión parecía

INSERT INTO tablname (column,column) VALUES (value,value,...)

La lista de columnas no incluía la clave primaria numérica. Cuando volvió el error 1062, usaría la misma consulta en la que falló, ejecutaría la consulta manualmente. No alcanzó el error 1062. Luego, ejecuté los comandos habituales de omisión de esclavos:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

Entonces, la replicación se puso al día.

Mi consejo sería serializar adecuadamente sus INSERTs en el Master porque esta situación similar a un error es realmente evitable.

Lo has hecho bien (como ya se dijo).

El único problema es con el archivo master.info (contiene información sobre la posición en mysql-bin.log del maestro) porque este archivo no se sincroniza con el disco después de cada consulta procesada.

Por lo tanto, su información sobre las posiciones en el registro del maestro está desactualizada y está procesando consultas ya procesadas que deben omitirse SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;.

Desafortunadamente, si usa algunas consultas como UPDATE table SET counter=counter+1 WHERE id = 12345y el uso de binlog_format=STATEMENTsus bases de datos puede no estar sincronizado, creo.

Puede decirle al servidor MySQL que sincronice master.info después de cada evento configurando la variable sync_master_info, pero probablemente tendrá enormes consecuencias de rendimiento.