Errore 1236 - "Impossibile trovare il primo nome del file di registro nel file indice del registro binario"

La nostra configurazione:

• Master: MariaDB 10.0.21
• Schiavo: MariaDB 10.0.17

La replica funzionava bene fino a poco tempo fa a quel punto i DB dello slave dovevano essere ripristinati da una discarica. Ho eseguito tutti i passaggi necessari: scaricare i DB del master, trasferire il dump allo slave, rilasciare i vecchi DB, eseguire il dump per ripristinare i DB, eseguire il CHANGE MASTERcomando appropriato e infine START SLAVE.

Ricevo l'errore: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

Il primo file di registro di cui lo slave ha bisogno dal master è mysql-bin.000289. Vedo che questo è presente sul master:

Posso anche vedere che l'indice del registro binario sul master sembra avere una voce per questo file di registro:

La replica non funziona, continuo a ricevere lo stesso errore. Sono a corto di idee: cosa devo controllare dopo?

Aggiornato: output di SHOW SLAVE STATUS\Gcome richiesto:

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)

Ulteriori informazioni richieste:

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 (estratto):

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

Modifica: la posizione 342 sembra esistere:

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

Sembra che tu non ti stia collegando al master che pensi di essere. Per i tuoi registri binari sul master sembra che tu abbia:

# 160519 3:28:59 ID server 5

Ma per SHOW SLAVE STATUS vediamo:

         Master_Server_Id: 3

Inoltre, sembra che ti stia connettendo su localhost, ma hai implicato che il tuo master / slave si trova su host diversi:

              Master_Host: 127.0.0.1

Se tutto il resto fallisce, è possibile che sia necessario ripristinare lo slave e riavviare la replica. Da 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;

Il messaggio di errore è la risposta.

Guarda l'output della SHOW BINARY LOGSquery:

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

Non c'è mysql-bin.000278 sul display.

A meno che i registri binari non vengano ruotati, il contenuto di mysql-bin.index è errato.

Si prega di confrontare il contenuto di mysql-bin.indexcon i file binlogs attualmente esistenti e assicurarsi che corrispondano. Puoi sistemarlo sul Master con

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

poi vai allo schiavo e corri

mysql> STOP SLAVE; START SLAVE;

Provaci !!!

Aggiornamento: questa risposta copre la classificazione generale dell'errore. Per una risposta più specifica su come gestire al meglio la query esatta del PO, consultare le altre risposte a questa domanda

Uno dei principali errori di replica più critici Errore irreversibile 1236 Può essere innescato da molteplici motivi, uno dei quali è il titolo di questa domanda.

Errore irreversibile 1236 dal master durante la lettura dei dati dal registro binario: "Impossibile trovare il primo nome del file di registro nel file indice del registro binario"

Questo errore si verifica quando il server slave ha richiesto il registro binario per la replica non esiste più sul server del database master.

Così tanti scenari possono causare questo:

• Il server master è scaduto dai registri binari tramite la variabile di sistema expire_logs_days(my.cnf se si impostano expire_logs_daysbinlog vecchi scadono automaticamente e vengono rimossi; Quando MySQL apre un nuovo file binlog, controlla i binlog più vecchi e cancella quelli che sono più vecchi del valore di expire_logs_days)
• Qualcuno ha eliminato manualmente i registri binari dal master tramite PURGE BINARY LOGScomando o rm -fcomando
• Ne hai alcuni cronjobche archiviano vecchi registri binari per rivendicare spazio su disco

Per risolvere questo problema, l'unica soluzione pulita che mi viene in mente è quella di ricreare il server slave da un backup del server master o da un altro slave nella topologia di replica.

Riferimento: la replica mysql ha avuto un errore fatale