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自己仍是不多發生複製錯誤的