Erro 1236 - "Não foi possível encontrar o primeiro nome do arquivo de log no arquivo de índice binário de log"


10

Nossa configuração:

  • Mestre: MariaDB 10.0.21
  • Escravo: MariaDB 10.0.17

A replicação estava funcionando bem até recentemente, quando os DBs do escravo precisavam ser restaurados de um despejo. Executei todas as etapas necessárias: Despejar os bancos de dados do mestre, transferir o despejo para o escravo, soltar os bancos de dados antigos, executar o despejo para restaurar os bancos de dados, executar o CHANGE MASTERcomando apropriado e finalmente START SLAVE.

Estou recebendo o erro: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

O primeiro arquivo de log que o escravo precisa do mestre é mysql-bin.000289. Eu posso ver que isso está presente no mestre: insira a descrição da imagem aqui

Também posso ver que o índice de log binário no mestre parece ter uma entrada para este arquivo de log: insira a descrição da imagem aqui

Ainda a replicação não está funcionando - continuo recebendo o mesmo erro. Estou sem ideias - o que devo verificar a seguir?


Atualizado: Saída SHOW SLAVE STATUS\Gconforme 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)

Informações adicionais solicitadas:

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

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

Editar: a posição 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

Também tenha cuidado, pois sua versão mestre é um pouco mais recente que a sua versão escrava. Embora a versão escrava possa ser mais alta (porque, sem dúvida, ela entenderá todos os comandos / funções / características), se o Mestre for mais recente, poderá invocar algo que o Escravo nunca ouviu falar. Suspeito que isso não ocorra em uma diferença de revisão tão pequena, mas não pode ser descartada e, sem dúvida, seria Arcano ao extremo e difícil de encontrar. Além disso: a linha oficial é que o mestre mais recente não é suportado.
TheSatinKnight

Respostas:


6

Você parece não estar se conectando ao mestre que pensa que é. Por seus logs binários no mestre, você parece ter:

# 160519 3:28:59 ID do servidor 5

Mas por SHOW SLAVE STATUS, vemos:

         Master_Server_Id: 3

Além disso, você parece estar se conectando no host local, mas sugeriu que seu mestre / escravo está em hosts diferentes:

              Master_Host: 127.0.0.1

11
Estamos usando o tunelamento SSH (com autossh ) para expor o mestre remoto localmente em 127.0.0.1:3305. Notei o Master_Server_Id também, mas achei que isso era apenas um remanescente de muito tempo atrás, quando estávamos usando um mestre diferente. Eu esperava que o valor fosse SHOW SLAVE STATUSatualizado assim que restabelecermos totalmente a replicação. Independentemente disso, essa é uma sugestão impressionante; Vou verificar três vezes se realmente estamos nos conectando com o mestre certo!
Rinogo 02/06

11
Muito obrigado por me apontar na direção certa! Estávamos, de fato, nos conectando com o mestre errado. Eu o confirmei fazendo telnet 127.0.0.1:3305- eu pude ver que a versão reportada do MySQL correspondia à versão do antigo mestre. Acho que a raiz do problema provavelmente ocorreu devido a algumas peculiaridades de DNS em nossa rede - parece que a conexão autossh foi estabelecida erroneamente no domain.com, mesmo que tenha sido configurada para conectar-se ao db.domain.com. Muito obrigado mais uma vez.
rinogo 02/06

8

Se tudo mais falhar, talvez seja necessário redefinir o escravo e reiniciar a replicação. De 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;

11
O OP comentou que outra resposta estava correta (e eles estavam se conectando à instância errada).
ypercubeᵀᴹ

3
@ yper-trollᵀᴹ - sim, mas metade do objetivo do Stackexchange é o arquivo de perguntas, que inevitavelmente chegam ao topo do Google e buscam outras pessoas com o mesmo problema. Eu mesmo tive o mesmo problema, e essa foi a solução para mim (especialmente porque eu literalmente passei horas tentando resolvê-lo, porque a maioria das outras páginas mostra apenas as mesmas respostas). O fato de a outra resposta "errada" ter 2 votos positivos é uma prova disso.
Andy Beverley

Sim, ponto justo. Contanto que essa sugestão seja usada quando tudo mais falhar (e claramente marcado como tal), tudo bem. É por isso que eu apenas comentei e não votei mal.
ypercubeᵀᴹ

11
Essa resposta funcionou para mim quando nenhum dos outros conselhos foi aplicado. (Eu estava trabalhando em um binlog atual, existente, com o mestre configurado corretamente etc.) É uma resposta sólida e, francamente, o RESET SLAVE; A opção deve ser mencionada com mais destaque acima.
JD Baldwin

3

A mensagem de erro é a resposta.

Veja a saída da SHOW BINARY LOGSconsulta:

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

Não há mysql-bin.000278 no display.

A menos que os logs binários girem, o conteúdo do mysql-bin.index está errado.

Por favor, compare o conteúdo dos mysql-bin.indexarquivos binlogs agora existentes e verifique se eles correspondem. Você pode corrigir isso no Master com

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

então vá para o escravo e corra

mysql> STOP SLAVE; START SLAVE;

De uma chance !!!


Oi Rolando! Muito obrigado pela sua ajuda! Infelizmente, ainda estou confuso. Você quis dizer em mysql-bin.000288vez de mysql-bin.000278? Se sim, mysql-bin.000288parece existir. Isso ainda resolverá o problema?
Rinogo 23/05

PURGE BINARY LOGS TO 'mysql-bin.000279';me deu um erro (como era de se esperar), já que o log "279" não existia mais (havia sido girado para fora). PURGE BINARY LOGS TO 'mysql-bin.000288';executado com sucesso e excluiu todos os logs binários até "288". Infelizmente, ainda estou recebendo o erro.
Rinogo 25/05

Muito obrigado por suas sugestões detalhadas, Rolando! O problema acabou sendo que estávamos conectando ao mestre errado ( dba.stackexchange.com/a/140259/55530 ).
rinogo 02/06

2

Atualização: Esta resposta cobre a classificação geral de erros. Para obter uma resposta mais específica sobre como lidar melhor com a consulta exata do OP, consulte outras respostas a esta pergunta

Um dos principais erros de replicação mais críticos. Erro fatal 1236. Pode ser disparado por vários motivos, um deles é o título desta pergunta.

Erro fatal 1236 do mestre ao ler dados do log binário: 'Não foi possível encontrar o primeiro nome do arquivo de log no arquivo de índice de log binário'

Este erro ocorre quando o servidor escravo necessário para o log binário de replicação não existe mais no servidor de banco de dados mestre.

Muitos cenários podem causar isso:

  • O servidor mestre expirou os logs binários via variável de sistema expire_logs_days(my.cnf, se você definir expire_logs_daysbinlogs antigos, expira automaticamente e é removido; quando o MySQL abre um novo arquivo de log de binlog, ele verifica os binlogs mais antigos e elimina todos os que forem mais antigos que o valor expire_logs_days)
  • Alguém excluiu manualmente os logs binários do mestre via PURGE BINARY LOGScomando ou via rm -fcomando
  • Você tem alguns cronjobque arquivam logs binários mais antigos para reivindicar espaço em disco

Para resolver esse problema, a única solução limpa em que posso pensar é recriar o servidor escravo a partir de um backup do servidor mestre ou de outro escravo na topologia de replicação.

Referência: replicação mysql obteve erro fatal

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.