错误1236-“在二进制日志索引文件中找不到第一个日志文件名”

10

我们的设置：

  • 大师：MariaDB 10.0.21
  • 从站：MariaDB 10.0.17

复制工作一直很好，直到最近，此时必须从转储中还原从数据库。我执行了所有必要的步骤：转储主数据库，将转储转移到从数据库，删除旧数据库，执行转储以还原数据库，执行适当的CHANGE MASTER命令，最后执行START SLAVE。

我收到错误： Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

从属服务器需要主服务器提供的第一个日志文件是mysql-bin.000289。我可以看到这存在于主服务器上： 在此处输入图片说明

我还可以看到，主数据库上的二进制日志索引似乎包含此日志文件的条目： 在此处输入图片说明

复制仍然无法正常进行-我一直收到相同的错误。我没有主意-接下来应该检查什么？

更新：SHOW SLAVE STATUS\G根据要求输出：

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)

其他要求的信息：

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 （摘抄）：

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

编辑：位置342确实存在：

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
mysql  replication  mariadb 
— 里诺戈
source
另外请注意，您的主版本比从版本要新一些。从属版本可能更高（因为它无疑会理解所有命令/功能/功能），但如果主版本较新，则它可以调用从属从未听说过的东西。我怀疑它不会在这么小的修订版本差异中发生，但不能排除它，并且在极端情况下也很难找到奥术。另外：官方说法是不支持更新的master。
— TheSatinKnight

Answers:

6

您似乎没有连接到自己认为的主机。根据您在主数据库上的二进制日志，您似乎拥有：

＃160519 3:28:59 服务器ID 5

但是根据“显示从站状态”，我们看到：

         Master_Server_Id: 3

此外，您似乎在localhost上进行连接，但是您暗示您的主/从主机位于不同的主机上：

              Master_Host: 127.0.0.1
— 安德鲁
source
1
我们正在使用SSH隧道（带有autossh）在本地公开远程主机127.0.0.1:3305。我也注意到了Master_Server_Id，但是我发现这只是很久以前的残骸，当时我们使用的是另一个master。我期望SHOW SLAVE STATUS一旦我们完全重新建立复制就可以更新其中的值。无论如何，这是一个很棒的建议。我将三重确认我们确实正在连接到正确的主机！
— rinogo '16
1
非常感谢您为我指明了正确的方向！实际上，我们正在连接到错误的主机。我通过执行以下操作确认了这一点telnet 127.0.0.1:3305-我可以看到报告的MySQL版本与旧版本的MySQL版本匹配。我认为问题的根源很可能是由于我们网络上的某些DNS怪癖-似乎autossh连接被错误地建立到domain.com，即使它被配置为连接到db.domain.com。再次非常感谢。
— rinogo '16
8

如果所有其他方法均失败，则可能会发现您需要重置从属服务器并重新启动复制。从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;
— 安迪·贝弗利（Andy Beverley）
source
1
OP认为另一个答案是正确的（他们正在连接到错误的实例）。
— ypercubeᵀᴹ
3
@yper-trollᵀᴹ-是的，但是Stackexchange的一半是问题的存档，这些问题不可避免地排在Google搜索其他遇到相同问题的人的顶部。我自己也遇到了完全相同的问题，这对我来说就是解决方案（尤其是我花了数小时试图解决这个问题，因为大多数其他页面仅显示相同的其他答案）。另一个“错误”答案有2个赞成票的事实证明了这一点。
— 安迪·贝弗利
是的，很公平。只要在所有其他方法都失败（并明确标记为失败）时使用此（建议），就可以了。这就是为什么我只发表评论而不是不赞成投票的原因。
— ypercubeᵀᴹ
1
当没有其他建议适用时，此答案对我有用。（我正在研究一个现有的当前binlog，已经正确配置了master，等等。）这是一个合理的答案，坦率地说是RESET SLAVE；选项应该在上面更加突出地提及。
— JD鲍德温
3

错误消息就是答案。

查看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.000278。

除非二进制日志轮换，否则mysql-bin.index的内容是错误的。

请比较的内容mysql-bin.index与现有的binlog文件，并确保它们匹配。您可以使用

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

然后去奴隶跑

mysql> STOP SLAVE; START SLAVE;

试试看 ！！！

— 罗兰多·MySQLDBA
source
嗨，罗兰多！非常感谢你的帮助！不幸的是，我仍然感到困惑。您是mysql-bin.000288不是要说mysql-bin.000278？如果是这样，mysql-bin.000288似乎确实存在。这样还能解决问题吗？
— rinogo '16
PURGE BINARY LOGS TO 'mysql-bin.000279';给我一个错误（出乎意料的是），因为日志“ 279”已不存在（已转出）。PURGE BINARY LOGS TO 'mysql-bin.000288';执行成功，并删除所有二进制日志，最多可删除“ 288”。不幸的是，我仍然遇到错误。
— rinogo '16
非常感谢您的详细建议，Rolando！问题最终导致我们连接到错误的主服务器（dba.stackexchange.com/a/140259/55530）。
— rinogo '16
2

更新：此答案涵盖了常规错误分类。有关如何最好地处理OP的确切查询的更具体的答案，请参阅此问题的其他答案

最严重的严重复制错误之一发生了致命错误1236 可以由多种原因触发，其中一个是此问题的标题。

从二进制日志读取数据时，主机出现致命错误1236：“在二进制日志索引文件中找不到第一个日志文件名”

当从属服务器需要复制的二进制日志在主数据库服务器上不再存在时，会发生此错误。

太多的情况可能导致此：

  • 主服务器通过系统变量过期的二进制日志expire_logs_days（如果您设置了expire_logs_days旧的二进制日志， my.cnf 会自动过期并被删除；当MySQL打开一个新的二进制日志文件时，它将检查较旧的二进制日志，并清除所有超过expire_logs_days值的二进制日志）
  • 有人通过PURGE BINARY LOGS命令或rm -f命令从主机手动删除了二进制日志
  • 您有一些cronjob可以归档较旧的二进制日志以声明磁盘空间的文件

为了解决此问题，我能想到的唯一干净的解决方案是从主服务器备份或复制拓扑中的其他从服务器重新创建从服务器。

参考：mysql复制出现致命错误

— 阿努瓦尔
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.