您当前的位置： 首页 >  sql

MySQL主从复制报错：Got fatal error 1236 from master when reading data from

发布时间：2019-07-22 15:21:19 ，浏览量：0

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

备库检查报错： 

(root@localhost) [sys]> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: repl
                  Master_Port: 3316
                Connect_Retry: 60
              Master_Log_File: rhel6lhr-bin.000003
          Read_Master_Log_Pos: 154
               Relay_Log_File: rhel6lhr-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: rhel6lhr-bin.000003
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          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: 154
              Relay_Log_Space: 154
              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: 57193316
                  Master_UUID: 1dc4b050-ac4d-11e9-ab99-000c29d51a2a
             Master_Info_File: /usr/local/mysql57/mysql5719/data57193317/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 190722 15:06:09
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version:

 解决：

在 source 那边，执行： 

flush logs;
show master status;File

在 target 端，执行： 

stop slave ;
CHANGE MASTER TO MASTER_LOG_FILE='testdbbinlog.000008',MASTER_LOG_POS=107;
start slave ;
show slave status \G

 

一切正常。

【MySQL】Got fatal error 1236原因和解决方法

一 前言   MySQL 的主从复制作为一项高可用特性，用于将主库的数据同步到从库，在维护主从复制数据库集群的时候，作为专职的MySQL DBA，笔者相信大多数人都会遇到 “ Got fatal error 1236 from master when reading data from binary log ” 这类的报错/报警。本文整理了常见的几种 error 1236 报错，并给出相应的解决方法，有所不足之处， 当然也希望各位读者朋友指正。

二 常见的error 1236 报错 2.1 logevent超过 max_allowed_packet 大小 

Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the start event position from 'mysql-bin.006730' at 290066246, the last event was read from '/u01/my3309/log/mysql-bin.006730
【 原因 】    此类报错和max_allowed_packet相关。首先max_allowed_packet控制着主从复制过程中，一个语句产生的二进制binlog event大小，它的值必须是1024的倍数 。出现此类错误的常见原因是  1 该参数在主备库的配置大小不一样，主库的配置值大于从库的配置值。 从主库传递到备库的binlog event大小超过了主库或者备库的max_allowed_packet大小。  2 主库有大量数据写入时，比如在主库上执行 laod data，insert into .... select 语句，产生大事务。 当主库向从库传递一个比从库的max_allowed_packet 大的packet ，从库接收该packet失败，并报 “log event entry exceeded max_allowed_packet“。 【 如何解决 】  需要确保主备配置一样，然后尝试调大该参数的值。 

set global max_allowed_packet =1*1024*1024*1024;
 stop slave;start slave
另外，5.6 版本中的  slave_max_allowed_packet_size  参数控制slave 可以接收的最大的packet 大小，该值通常大于而且可以覆盖 max_allowed_packet 的配置, 进而减少由于上面的问题导致主从复制中断。 2.2 slave 在主库找不到binlog文件   

Got fatal error 1236 from master when reading data from binary log:
【 原因 】  该错误发生在从库的io进程从主库拉取日志时，发现主库的mysql_bin.index文件中第一个文件不存在。出现此类报错可能是由于你的slave 由于某种原因停止了好长一段是时间，当你重启slave 复制的时候，在主库上找不到相应的binlog ,会报此类错误。或者是由于某些设置主库上的binlog被删除了，导致从库获取不到对应的binglog file。 【 如何解决 】  1 为了避免数据丢失，需要重新搭建slave 。  2 注意主库binlog的清理策略，选择基于时间过期的删除方式还是基于空间利用率的删除方式。   不要使用rm -fr 命令删除binlog file，这样不会同步修改mysql_bin.index 记录的binlog 条目。在删除binlog的时候确保主库保留了从库 show slave status 的Relay_Master_Log_File对应的binlog file。 2.3 主库空间问题， 日志被截断 

Got fatal error 1236 from master when reading data from binary log: 'binlog truncated in the middle of event; consider out of disk space on master; the start event position from 'mysql-bin.006730' at 290066434, the last event was read from '/u01/my3309/log/mysql-bin.006730
【 原因 】  该错误和主库的空间问题和sync_binlog配置有关，当主库 sync_binlog=N不等于1且磁盘空间满时,MySQL每写N次binary log，系统才会同步到磁盘，但是由于存储日志的磁盘空间满而导致MySQL 没有将日志完全写入磁盘，binlog event被截断。slave 读取该binlog file时就会报错"binlog truncated in the middle of event;"  当sync_binlog 的默认值是0，像操作系统刷其他文件的机制一样，MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。  当sync_binlog =N (N>0) ，MySQL 在每写 N次 二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。 【 如何解决 】  在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始 

stop slave;
 change master to master_log_file='mysql-bin.006731', master_log_pos=4;start slave;
2.4 主库异常断电,从库读取错误的position 

120611 20:39:38 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 
 120611 20:39:38 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236120611 20:39:38 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000143', position 664526789
【原因】  该问题也是和sync_binlog=N不等于1有关，多出现在主机异常crash ，比如磁盘损坏，raid 卡损坏，或者主机异常掉电导致binlog 未及时同步到磁盘。从库读取了主库binlog file中的不存在的binlog position ，一般比binlogfile 的end position 的值还要大。 【 如何解决 】 1 在从库重新指向到主库下一个可用的binlog file 并且从binlog file初始化的位置开始 

stop slave;
 change master to master_log_file='mysql-bin.000144', master_log_pos=4;start slave;
2 主备库设置 sync_binlog=1，但是设置为1的时候，会带来性能下降。 

About Me

........................................................................................................................

● 本文作者：小麦苗，部分内容整理自网络，若有侵权请联系小麦苗删除

● 本文在itpub、博客园、CSDN和个人微 信公众号（ xiaomaimiaolhr ）上有同步更新

● 本文itpub地址： http://blog.itpub.net/26736162

● 本文博客园地址： http://www.cnblogs.com/lhrbest

● 本文CSDN地址： https://blog.csdn.net/lihuarongaini

● 本文pdf版、个人简介及小麦苗云盘地址： http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答： http://blog.itpub.net/26736162/viewspace-2134706/

● DBA宝典今日头条号地址： http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群号： 230161599 （满） 、618766405

● 微 信群：可加我微 信，我拉大家进群，非诚勿扰

● 联系我请加QQ好友 （ 646634621 ） ，注明添加缘由

● 于 2019-07-01 06:00 ~ 2019-07-31 24:00 在西安完成

● 最新修改时间：2019-07-01 06:00 ~ 2019-07-31 24:00

● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解

● 版权所有，欢迎分享本文，转载请保留出处

........................................................................................................................

● 小麦苗的微店 ： https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

● 小麦苗出版的数据库类丛书 ： http://blog.itpub.net/26736162/viewspace-2142121/

● 小麦苗OCP、OCM、高可用网络班 ： http://blog.itpub.net/26736162/viewspace-2148098/

● 小麦苗腾讯课堂主页 ： https://lhr.ke.qq.com/

........................................................................................................................

使用 微 信客户端 扫描下面的二维码来关注小麦苗的微 信公众号（ xiaomaimiaolhr ）及QQ群（DBA宝典）、添加小麦苗微 信， 学习最实用的数据库技术。

........................................................................................................................

欢迎与我联系

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2651325/，如需转载，请注明出处，否则将追究法律责任。

关注
打赏
1688896170
查看更多评论

暂无认证

  • 0浏览

    0关注

    107766博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

[ 申请 ]友情链接：

快连vpn 快连 快连vpn 搜外友链 笔趣阁 爱思助手 ClashX教程 绘画宝宝 配音宝宝
立即登录/注册

微信扫码登录

0.0766s