Error 1236 - "No se pudo encontrar el primer nombre de archivo de registro en el archivo de índice de registro binario"


10

Nuestra configuración:

  • Maestra: MariaDB 10.0.21
  • Esclavo: MariaDB 10.0.17

La replicación funcionaba bien hasta hace poco, momento en que las bases de datos del esclavo tuvieron que ser restauradas de un volcado. Realicé todos los pasos necesarios: volcar los DB del maestro, transferir el volcado al esclavo, descartar los viejos DB, ejecutar el volcado para restaurar los DB, ejecutar el CHANGE MASTERcomando apropiado y finalmente START SLAVE.

Estoy recibiendo el error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

El primer archivo de registro que el esclavo necesita del maestro es mysql-bin.000289. Puedo ver que esto está presente en el maestro: ingrese la descripción de la imagen aquí

También puedo ver que el índice de registro binario en el maestro parece tener una entrada para este archivo de registro: ingrese la descripción de la imagen aquí

Aún así, la replicación no funciona: sigo recibiendo el mismo error. Me he quedado sin ideas. ¿Qué debo comprobar a continuación?


Actualizado: Salida de SHOW SLAVE STATUS\Glo solicitado:

MariaDB [(none)]> SHOW SLAVE STATUS\G
--------------
SHOW SLAVE STATUS
--------------

*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: replication
                  Master_Port: 1234
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000289
          Read_Master_Log_Pos: 342
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000289
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxx_yyy,xxx_zzz
          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: 342
              Relay_Log_Space: 248
              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: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Información adicional solicitada:

root@master [818 18:54:22 /var/lib/mysql]# ls -l /var/lib/mysql/mysql-bin.000289
-rw-rw---- 1 mysql mysql 1074010194 May 19 03:28 /var/lib/mysql/mysql-bin.000289
root@master [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
root@master [821 18:56:52 /var/lib/mysql]# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6345382
Server version: 10.0.21-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |
| mysql-bin.000283 | 1073742000 |
| mysql-bin.000284 | 1074219591 |
| mysql-bin.000285 | 1074184547 |
| mysql-bin.000286 | 1074217812 |
| mysql-bin.000287 | 1022733058 |
| mysql-bin.000288 |     265069 |
| mysql-bin.000289 | 1074010194 |
| mysql-bin.000290 | 1074200346 |
| mysql-bin.000291 |  617421886 |
| mysql-bin.000292 |     265028 |
+------------------+------------+
14 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
root@master [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
root@master [822 18:58:13 /var/lib/mysql]# tail /tmp/somefile.txt 
# at 1074010124
#160519  3:28:59 server id 5  end_log_pos 1074010151    Xid = 417608063
COMMIT/*!*/;
# at 1074010151
#160519  3:28:59 server id 5  end_log_pos 1074010194    Rotate to mysql-bin.000290  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@master [823 18:58:31 /var/lib/mysql]# 

/etc/my.cnf.d/server.cnf (extracto):

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

Editar: Postion 342 parece existir:

root@master [826 12:15:33 /var/lib/mysql]# grep "end_log_pos 342 " /tmp/somefile.txt
#160517 14:43:13 server id 5  end_log_pos 342   Binlog checkpoint mysql-bin.000288

También tenga cuidado ya que su versión maestra es un poco más reciente que su versión esclava. Si bien la versión esclava puede ser superior (porque indudablemente comprenderá todos los comandos / funciones / características), si el Maestro es más reciente, podría invocar algo de lo que el Esclavo nunca ha oído hablar. Sospecho que no ocurriría en una diferencia de revisión tan pequeña, pero no se puede descartar y sin duda sería Arcano en extremo y difícil de encontrar. Además: la línea oficial es que el maestro más reciente no es compatible.
TheSatinKnight

Respuestas:


6

Parece que no te estás conectando con el maestro que crees que eres. Según sus registros binarios en el maestro que parece tener:

# 160519 3:28:59 ID de servidor 5

Pero según SHOW SLAVE STATUS vemos:

         Master_Server_Id: 3

Además, parece que se está conectando en localhost, pero ha dado a entender que su maestro / esclavo está en diferentes hosts:

              Master_Host: 127.0.0.1

1
Estamos usando el túnel SSH (con autossh ) para exponer el maestro remoto localmente en 127.0.0.1:3305. También noté el Master_Server_Id, pero pensé que era solo un remanente de hace mucho tiempo cuando estábamos usando un maestro diferente. Esperaba que el valor se SHOW SLAVE STATUSactualizara una vez que restableciéramos completamente la replicación. De todos modos, esta es una sugerencia increíble; ¡Comprobaré tres veces que, de hecho, nos estamos conectando con el maestro correcto!
rinogo

1
¡Muchas gracias por señalarme en la dirección correcta! De hecho, estábamos conectando con el maestro equivocado. Lo confirmé haciendo un telnet 127.0.0.1:3305: pude ver que la versión de MySQL informada coincidía con la versión del antiguo maestro. Creo que la raíz del problema probablemente se debió a algunas peculiaridades de DNS en nuestra red: parece que la conexión de autossh se estableció erróneamente en domain.com, a pesar de que se configuró para conectarse a db.domain.com. Muchas gracias de nuevo.
rinogo

8

Si todo lo demás falla, es posible que necesite restablecer el esclavo y reiniciar la replicación. Desde https://www.redips.net/mysql/replication-slave-relay-log-corrupted/ :

# First note current settings
mysql> show slave status\G
# then 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.XXX', master_log_pos=XXX;
# start slave
mysql> start slave;

1
El OP ha comentado que otra respuesta fue correcta (y se estaban conectando a la instancia incorrecta).
ypercubeᵀᴹ

3
@ yper-trollᵀᴹ: sí, pero la mitad del objetivo de Stackexchange es el archivo de las preguntas, que inevitablemente se ubican en la parte superior de las búsquedas de Google para otras personas con el mismo problema. Tuve exactamente el mismo problema, y ​​esta fue la solución para mí (especialmente porque literalmente pasé horas tratando de resolverlo, porque la mayoría de las otras páginas solo muestran las mismas respuestas). El hecho de que la otra respuesta "incorrecta" tenga 2 votos positivos es un testimonio de esto.
Andy Beverley

Sí, punto justo. Siempre y cuando esta (sugerencia) esté destinada a usarse cuando todo lo demás falle (y esté claramente marcado como tal), está bien. Es por eso que solo comenté y no voté en contra.
ypercubeᵀᴹ

1
Esta respuesta funcionó para mí cuando ninguno de los otros consejos se aplicaba. (Estaba trabajando en un binlog existente, actual, tenía el maestro configurado correctamente, etc.) Es una respuesta sólida y, francamente, RESET SLAVE; Opción debe mencionarse más prominentemente arriba.
JD Baldwin

3

El mensaje de error es la respuesta.

Mira el resultado de la SHOW BINARY LOGSconsulta:

+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |

No hay mysql-bin.000278 en la pantalla.

A menos que los registros binarios roten, el contenido de mysql-bin.index es incorrecto.

Compare el contenido de mysql-bin.indexcon los archivos binlogs ahora existentes y asegúrese de que coincidan. Puedes arreglar esto en el Master con

mysql> PURGE BINARY LOGS TO 'mysql-bin.000279';

luego ve al Esclavo y corre

mysql> STOP SLAVE; START SLAVE;

Darle una oportunidad !!!


Hola rolando ¡Muchas gracias por su ayuda! Lamentablemente, todavía estoy confundido. ¿Quiso decir en mysql-bin.000288lugar de mysql-bin.000278? Si es así, mysql-bin.000288parece existir. ¿Esto todavía solucionará el problema?
rinogo

PURGE BINARY LOGS TO 'mysql-bin.000279';me dio un error (como era de esperar), ya que el registro "279" ya no existía (había sido eliminado). PURGE BINARY LOGS TO 'mysql-bin.000288';ejecutó con éxito y eliminó todos los registros binarios hasta "288". Desafortunadamente, sigo recibiendo el error.
rinogo

Muchas gracias por sus sugerencias detalladas, Rolando! El problema terminó siendo que nos estábamos conectando al maestro incorrecto ( dba.stackexchange.com/a/140259/55530 ).
rinogo

2

Actualización: esta respuesta cubre la clasificación de error general. Para obtener una respuesta más específica sobre cómo manejar mejor la consulta exacta del OP, consulte otras respuestas a esta pregunta

Uno de los principales errores de replicación más críticos. Error fatal 1236. Puede ser provocado por múltiples razones, una de ellas es el título de esta pregunta.

Recibió el error grave 1236 del maestro al leer los datos del registro binario: 'No se pudo encontrar el primer nombre del archivo de registro en el archivo de índice del registro binario'

Este error ocurre cuando el servidor esclavo requiere un registro binario para la replicación que ya no existe en el servidor de la base de datos maestra.

Muchos escenarios pueden causar esto:

  • El servidor maestro expiró los registros binarios a través de la variable del sistema expire_logs_days(my.cnf si establece que los expire_logs_daysbinlog antiguos caduquen automáticamente y se eliminen; cuando MySQL abre un nuevo archivo binlog, comprueba los binlogs más antiguos y purga los que son más antiguos que el valor de expire_logs_days)
  • Alguien eliminó manualmente los registros binarios del maestro mediante un PURGE BINARY LOGScomando o un rm -fcomando
  • Tiene algunos cronjobque archivan registros binarios más antiguos para reclamar espacio en disco

Para resolver este problema, la única solución limpia que se me ocurre es volver a crear el servidor esclavo a partir de una copia de seguridad del servidor maestro o de otro esclavo en la topología de replicación.

Referencia: la replicación mysql tiene un error fatal

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.