您的位置:1010cc时时彩经典版 > 1010cc安卓版 > 1010cc时时彩经典版1236缘由和减轻办法,Mysql主从

1010cc时时彩经典版1236缘由和减轻办法,Mysql主从

发布时间:2019-12-01 14:17编辑:1010cc安卓版浏览(100)

    刚处理完“挖矿”事件,在做最后一个MySQL NBU备份的时候,发现从库有问题,好奇的是怎么主从状态异常没有告警呢?先不管这么多了,处理了这个问题再完善告警内容。

    主从复制:MySQL5.6开始主从复制有两种方式:基于日志(binlog);基于GTID(全局事务标示符);

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

    一、错误信息

    1》基于日志(binlog)主从复制原理:

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

    从库show slave status G看到的错误信息如下:

        Mysql的Replication是一个异步复制的过程,从一个Mysql instace(我们称成之为:Master)复制另外一个Mysqlinstance(我们称为slave),在Master与 slave     之间实现整个复制的过程是由**三个线程来完成的,其中两个线程(sql线程和IO线程)在Slave端,另外一个线程(IO线程0在Master端.)要实MysqlReplication
       首先必须打开Master端的Binary Log(就是打开bin-log功能)否则无法实现,整个的复制过程实际上就是Slave从Master端获取binlog日志然后再slave端顺序执    行日志中所有的记录及各种操作;


    Slave_IO_Running: No
    Slave_SQL_Running: Yes
    Last_IO_Errno: 1236
    Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.'
    

      Mysql复制基本过程如下:
        1> Slave上面的IO线程连接上Master,并且请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
        2>Master接收到来自Slave的IO线程请求后,通过负责复制的IO线程根据请求的信息指定日志指定位置后的日志信息,返回给Slave端的IO线程,返回的信                   息当中除了日志所有包含的信息外,还包括本次返回信息在Master段的Binary log(二进制)文件名称以及Binary log(二进制)的位置.
        3>Slave的IO 线程接收到master返回的信息后,将接收到的日志内容一次写入slave端的Relay log中继日志文件,(mysql-relay-bin.xx)的最末端,并且将                     读取到的Master端的bin-log的文件和位置记录,纪录到 master-info文件当中,以方便下一次读取的时候能够清楚的告诉Master 我需要从某个bin-lo
                       g的哪个位置开始往后的日志内容,请发给我;
        4>Slave的SQL线程检测到Relay Log中心增加了内容后,会马上解析Master 二进制日志文件中的内容执行里面的Query语句;**

    1. 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

    二、错误原因

                    1010cc时时彩经典版 1

    原因
       此类报错和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“。
    如何解决
     需要确保主备配置一样,然后尝试调大该参数的值。

    这里看到从库的io_thread已经终止,错误编号是1236,具体是由于读取主库的binlog日志位置(the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4)不对导致主从失败建立失败。

    2》主从环境

    1. set global max_allowed_packet =1*1024*1024*1024;
    2. stop slave;
    3. start slave

    三、解决方案

       Master IP: 192.168.1。106
         Slave IP: 192.168.1。110
            在Master和Slave上安装Mysql
    3》
    Master(主)操作

    另外,5.6 版本中的 slave_max_allowed_packet_size 参数控制slave 可以接收的最大的packet 大小,该值通常大于而且可以覆盖 max_allowed_packet 的配置, 进而减少由于上面的问题导致主从复制中断。

    2.2 slave 在主库找不到binlog文件
     

    1.检查从库状态以及读取、执行的binlog信息

        # : vim /etc/my.cnf
        #log_slave_updates 注释掉这行
        server-id=1 将id号改为1
        #mysql –uroot –p –h localhost
        mysql>grant replication slave on
    .* to 'admin'@'192.168.1.106' identified by '123456'; #给13slave进行授权复制
        mysql>flush tables with read lock;
        mysql>show master status;*

    1. Got fatal error 1236 from master when reading data from binary log:
    mysql> show slave status G
    *************************** 1. row ***************************
                   Slave_IO_State: 
                      Master_Host: xx.xx.xx.xx
                      Master_User: username
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mysql-bin.000081
              Read_Master_Log_Pos: 480141113
                   Relay_Log_File: mysql9017-relay-bin.000163
                    Relay_Log_Pos: 480141259
            Relay_Master_Log_File: mysql-bin.000081
                 Slave_IO_Running: No
                Slave_SQL_Running: Yes
                  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: 480141113
                  Relay_Log_Space: 480141462
                  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: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.'
                   Last_SQL_Errno: 0
                   Last_SQL_Error: 
      Replicate_Ignore_Server_Ids: 
                 Master_Server_Id: 17
    1 row in set (0.00 sec)
    

                     1010cc时时彩经典版 2

    原因
     该错误发生在从库的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 主库空间问题,日志被截断

    2.查看主库的binlog内容

                    mysql>unlock tables;

    1. 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

    [backup]# mysqlbinlog  mysql-bin.000081 >mysql-bin.log

    4》Slave(从)操作

    原因
     该错误和主库的空间问题和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初始化的位置开始

    1010cc时时彩经典版 3

      #:vim /etc/my.cnf
      server-id=2 #将server_id改为2
      #mysql –uroot –p –h localhost
      mysql>stop slave;
      mysql>change master to
      master_host='192.168.100.160',
      master_user='admin',
      master_password='123456',
      master_log_file='masterlog.000001',
      master_log_pos=120;
      mysql>start slave;
      mysql>show slave statusG;

    1. stop slave;
    2. change master to master_log_file='mysql-bin.006731', master_log_pos=4;
    3. start slave;

    看到主库binlog日志mysql-bin.000081最大的pos为480140557,但从库要读取的是'mysql-bin.000081' at 480141113,显然从库要读的pos值比主库本身存在的pos值大,导致读取不到,进而失败。

    ***           排错:
        如果show slave statusG;报错是因为没有找到正确的端口号,则可以在这个直接添加定义
        master_port=3306,

    2.4 主库异常断电,从库读取错误的position

    可通过下面语句查看binlog的pos信息和日志内容
    mysql> show binlog events in  'mysql-bin.000081' from 480140557 limit 10;       
    Empty set (0.04 sec)
    3.更改从库的同步位置,完成数据重新同步

      检查从服务器复制功能状态:  排错:
        如果show slave statusG;报错是因为没有找到正确的端口号,则可以在这个直接添加定义
        master_port=3306,

    1. 120611 20:39:38 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236) 
    2. 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: 1236
    3. 120611 20:39:38 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.000143', position 664526789

    本文由1010cc时时彩经典版发布于1010cc安卓版,转载请注明出处:1010cc时时彩经典版1236缘由和减轻办法,Mysql主从

    关键词: