mysql 案例 ~ mysql主从复制错误问题

简介 mysql主从不一样步的几种状况

一  具体状况
   1 主库有memory引擎的内存表
      分析 因为memory表的数据存放在内存中,一旦主库数据丢失,从库可能就会发生数据复制异常
   2 从库有super权限的用户进行数据操做
      分析 5.7以前,哪怕设置从库只读,有super权限的用户仍是能够进行数据修改,一旦在从库进行操做,那么主从数据必将不一致,发生数据复制异常
   3 因为binlog格式非row的问题
     分析 对于binlog格式非row的状况下,可能某些函数和机制都会形成主从同步异常
   4 因为配置文件不一致致使的问题
      1 server_id配置一致
      2 sql_mode 配置不一致
      3 主从信息保存在文件中,而非table级别
      4 设置了table/db过滤规则
  5 因为主库开启了某种特性形成的问题
     分析 常见于event事件
二 解决办法
  方案1
  改造memory内存表要么去掉,要么改为innodb引擎
  方案2
  设置从库只读,不容许研发人员操做从库,不提供super帐号
  方案3
  设置binlog为统一row格式
  方案4
  保证主从的配置文件大致一致,防止出现问题
  方案5
  1 对于已经存在的主从， 新创建events没有影响。从别的主库同步过来的event， 自己不会执行。
   2 对于新创建的主从，若是有events ，那么须要在从库上把event_scheduler设置为off.不然自己还会执行一遍
三 修复主从不一致的方法
  1 跳过主从不一致错误(不推荐),可能致使一系列重复问题
  2 利用备份重作从库
  3 利用binlog2sql/pt等开源工具对不一致的数据进行修复

四 常见 错误补充

       1 变量问题

         1 Could not execute Write_rows event on table practice.temp_baofoo_unbind; Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again, Error_code: 1197; Writing one row to the row-based binary log failed, Error_code: 1534; handler error HA_ERR_RBR_LOGGING_FAILED; the event's master log binlog.000017, end_log_pos 268602107

       2  数据错乱   

         1  Could not execute Delete_rows event on table hcy.t1; Can't find record in 't1',  

         2  Could not execute Write_rows event on table hcy.t1;  Duplicate entry '2' for key 'PRIMARY'

      3  binlog定位问题

          1 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

五 复制参数补充

     1 replicate-rewrite-db = employees -> hellodb   复制映射,将原主的DB映射到从的其余库,而并不是本来库

        这里要尤为注意,主库作DDL操做 千万不要采用 db.table方式的sql语句,不然可能致使从库复制出现错误

六 GTID模式下的特殊复制错误

     错误1 Got fatal error 1236 from master when reading data from binary log: 'Cannot replicate anonymous transaction when AUTO_POSITION = 1

     分析 匿名事务(anonymous transaction ) 的生成是没法生成全局GTID的

     执行命令

     set  gtid_model =  ON_PERMISSIVE,而后再执行事务

    经过分析主库binlog的位点也能够发现 set  @@session.GTID_NEXT='anonymous' 和以前的猜测项对应

    解决方式:  1  从新在从库执行匿名事务.而后重启slave线程便可 2 严格控制开发行为,不容许手动更改环境变量

    错误2  When@@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a differentvalue after a COMMIT or ROLLBACK. 

    分析可能缘由

      1 主库执行create table as select * from xx; 致使从库复制错误

    分析可能 因为后期加入了GTID的强一致性约束,就不会有这种问题.若是有这种错误,是早期版本,须要用户自我进行约束

七  GTID 补充

     1  GTID 复制模型会检测 gtid event的有效性 

       1 GTID_MODE为 OFF   2  anonymouse +GTID OFF 3 anonymouse + AUTO_POSITION = 1,

       咱们能够发现 GTID 复制模型对匿名事务是0容忍的,也是不会写入从库的relay log中的,同时复制就会发生异常

   2 GTID model四种模式

       OFF <-> OFF_PERMISSIVE <-> ON_PERMISSIVE <-> ON 必须依次调整.  只要OFF_ERMISSIVE就会发生匿名事务

   3 GTID限制

      1 不容许create  select语句事务 

      2 不容许 myisam innodb引擎表在同一个事务内混合应用

     3  Temporary tables事务内部不能执行

  4  强烈建议启动强一致性约束 

  5  只要规范使用GTID, GTID自己仍是不多发生复制错误的