MySQL主從不一致情形與解決方法

時間  2019-11-16
標籤 mysql 主從 不一致 情形 解決 方法 欄目 MySQL 简体版
原文   原文鏈接

1、MySQL主從不一樣步狀況

1.1 網絡的延遲

  • 因爲mysql主從複製是基於binlog的一種異步複製 經過網絡傳送binlog文件，理所固然網絡延遲是主從不一樣步的絕大多數的緣由，特別是跨機房的數據同步出現這種概率很是的大，因此作讀寫分離，注意從業務層進行前期設計。

1.2 主從兩臺機器的負載不一致

因爲mysql主從複製是主數據庫上面啓動1個io線程，而從上面啓動1個sql線程和1個io線程，當中任何一臺機器的負載很高，忙不過來，致使其中的任何一個線程出現資源不足，都將出現主從不一致的狀況。python

1.3 max_allowed_packet設置不一致

主數據庫上面設置的max_allowed_packet比從數據庫大，當一個大的sql語句，能在主數據庫上面執行完畢，從數據庫上面設置太小，沒法執行，致使的主從不一致。mysql

1.4 自增鍵不一致

key自增鍵開始的鍵值跟自增步長設置不一致引發的主從不一致。sql

1.5 同步參數設置問題

mysql異常宕機狀況下，若是未設置sync_binlog=1或者innodb_flush_log_at_trx_commit=1頗有可能出現binlog或者relaylog文件出現損壞，致使主從不一致。shell

1.6 自身bug

mysql自己的bug引發的主從不一樣步數據庫

1.7 版本不一致

特別是高版本是主，低版本爲從的狀況下，主數據庫上面支持的功能，從數據庫上面不支持該功能。bash

1.8 主從不一致優化配置

  • 基於以上狀況，先保證max_allowed_packet，自增鍵開始點和增加點設置一致
  • 再者犧牲部分性能在主上面開啓sync_binlog，對於採用innodb的庫，推薦配置下面的內容
innodb_flush_logs_at_trx_commit = 1
innodb-support_xa = 1 # Mysql 5.0 以上
innodb_safe_binlog      # Mysql 4.0
複製代碼

同時在從上面推薦加入下面兩個參數服務器

skip_slave_start
read_only
複製代碼

2、解決主從不一樣步的方法

2.1 主從不一樣步場景描述

今天發現Mysql的主從數據庫沒有同步網絡

先上Master庫：架構

  • mysql>show processlist; 查看下進程是否Sleep太多。發現很正常。
  • show master status; 查看主庫狀態也正常。
mysql> show master status;
+-------------------+----------+--------------+-------------------------------+
| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB              |
+-------------------+----------+--------------+-------------------------------+
| mysqld-bin.000001 |     3260 |              | mysql,test,information_schema |
+-------------------+----------+--------------+-------------------------------+
1 row in set (0.00 sec)
複製代碼

再到Slave上查看併發

mysql> show slave status\G                                                

Slave_IO_Running: Yes
Slave_SQL_Running: No
複製代碼

因而可知是Slave不一樣步

2.2 解決方法一：忽略錯誤後，繼續同步

該方法適用於主從庫數據相差不大，或者要求數據能夠不徹底統一的狀況，數據要求不嚴格的狀況 解決：

stop slave;
複製代碼
  • 表示跳過一步錯誤，後面的數字可變
set global sql_slave_skip_counter =1;
start slave;
複製代碼
  • 以後再用mysql> show slave status\G 查看：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
複製代碼

ok，如今主從同步狀態正常了。。。

2.3 方式二：從新作主從，徹底同步

該方法適用於主從庫數據相差較大，或者要求數據徹底統一的狀況 解決步驟以下：

  • 1.先進入主庫，進行鎖表，防止數據寫入 使用命令：

mysql> flush tables with read lock;

注意：該處是鎖定爲只讀狀態，語句不區分大小寫

  • 2.進行數據備份 把數據備份到mysql.bak.sql文件 [root@server01 mysql]#mysqldump -uroot -p -hlocalhost > mysql.bak.sql 這裏注意一點：數據庫備份必定要按期進行，能夠用shell腳本或者python腳本，都比較方便，確保數據萬無一失

  • 3.查看master 狀態

mysql> show master status; 
+——————-+———-+————–+——————————-+ 
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
+——————-+———-+————–+——————————-+ 
| mysqld-bin.000001 | 3260 | | mysql,test,information_schema | 
+——————-+———-+————–+——————————-+ 
1 row in set (0.00 sec)
複製代碼
  • 4.把mysql備份文件傳到從庫機器，進行數據恢復

使用scp命令 [root@server01 mysql]# scp mysql.bak.sql root@192.168.1.206:/tmp/

  • 5.中止從庫的狀態 mysql> stop slave;

  • 6.而後到從庫執行mysql命令，導入數據備份

mysql> source /tmp/mysql.bak.sql

  • 7.設置從庫同步，注意該處的同步點，就是主庫show master status信息裏的| File| Position兩項

change master to master_host = ‘192.168.1.206’, master_user = ‘rsync’, master_port=3306, master_password=」, master_log_file = ‘mysqld-bin.000001’, master_log_pos=3260;

  • 8.從新開啓從同步 mysql> start slave;

  • 9.查看同步狀態 mysql> show slave status\G 查看：

Slave_IO_Running: Yes Slave_SQL_Running: Yes

好了，同步完成啦

3、如何監控mysql主從之間的延遲

3.1 前言：

平常工做中，對於MYSQL主從複製的檢查有兩方面

  • 保證複製的總體結構是否完整；
  • 須要檢查數據是否一致； 對於前者咱們能夠經過監控複製線程是否工做正常以及主從延時是否在容忍範圍內，對於後者則能夠經過分別校驗主從表中數據的md5碼是否一致，來保證數據一致，可使用Maatkit工具包中的mk-table-checksum工具去檢查。 本文檔介紹下關於如何檢查主從延遲的問題。

主從延遲判斷的方法，一般有兩種方法：Seconds_Behind_Master和mk-heartbeat

3.2方法1.

  • 經過監控show slave status\G命令輸出的Seconds_Behind_Master參數的值來判斷，是否有發生主從延時。
mysql>  show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.205
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: edu-mysql-bin.000008
          Read_Master_Log_Pos: 120
               Relay_Log_File: edu-mysql-relay-bin.000002
                Relay_Log_Pos: 287
        Relay_Master_Log_File: edu-mysql-bin.000008
             Slave_IO_Running: Yes
            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: 120
              Relay_Log_Space: 464
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 205
                  Master_UUID: 7402509d-fd14-11e5-bfd0-000c2963dd15
             Master_Info_File: /home/mysql/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)
複製代碼

以上是show slave status\G的輸出結果，這些結構給咱們的監控提供了不少有意義的參數。

  • Slave_IO_Running 該參數可做爲io_thread的監控項，Yes表示io_thread的和主庫鏈接正常並能實施複製工做，No則說明與主庫通信異常，多數狀況是由主從間網絡引發的問題；

  • Slave_SQL_Running 該參數表明sql_thread是否正常，具體就是語句是否執行經過，常會遇到主鍵重複或是某個表不存在。

  • Seconds_Behind_Master 是經過比較sql_thread執行的event的timestamp和io_thread複製好的event的timestamp(簡寫爲ts)進行比較，而獲得的這麼一個差值；NULL—表示io_thread或是sql_thread有任何一個發生故障，也就是該線程的Running狀態是No，而非Yes。0 — 該值爲零，是咱們極爲渴望看到的狀況，表示主從複製良好，能夠認爲lag不存在。 正值 — 表示主從已經出現延時，數字越大表示從庫落後主庫越多。負值 — 幾乎不多見，我只是聽一些資深的DBA說見過，其實，這是一個BUG值，該參數是不支持負值的，也就是不該該出現。

  • 備註Seconds_Behind_Master的計算方式可能帶來的問題 咱們都知道的relay-log和主庫的bin-log裏面的內容徹底同樣，在記錄sql語句的同時會被記錄上當時的ts，因此比較參考的值來自於binlog，其實主從沒有必要與NTP進行同步，也就是說無需保證主從時鐘的一致。你也會發現，其實比較真正是發生在io_thread與sql_thread之間，而io_thread才真正與主庫有關聯，因而，問題就出來了，

  • 當主庫I/O負載很大或是網絡阻塞 io_thread不能及時複製binlog（沒有中斷，也在複製），而sql_thread一直都能跟上io_thread的腳本，這時Seconds_Behind_Master的值是0，

  • 也就是咱們認爲的無延時，可是，實際上不是，你懂得。 這也就是爲何你們要批判用這個參數來監控數據庫是否發生延時不許的緣由，可是這個值並非老是不許，

  • 若是當io_thread與master網絡很好的狀況下，那麼該值也是頗有價值的。’‘以前，提到Seconds_Behind_Master這個參數會有負值出現，咱們已經知道該值是io_thread的最近跟新的ts與sql_thread執行到的ts差值，

前者始終是大於後者的，惟一的肯能就是某個event的ts發生了錯誤，比以前的小了，那麼當這種狀況發生時，負值出現就成爲可能。

3.2 方法2.

mk-heartbeat：Maatkit萬能工具包中的一個工具，被認爲能夠準確判斷複製延時的方法。 mk-heartbeat的實現也是藉助timestmp的比較實現的，它首先須要保證主從服務器必需要保持一致，經過與相同的一個NTP server同步時鐘。它須要在主庫上建立一個heartbeat的表，裏面至少有id與ts兩個字段，id爲server_id，ts就是當前的時間戳now()，該結構也會被複制到從庫上，表建好之後，會在主庫上之後臺進程的模式去執行一行更新操做的命令，按期去向表中的插入數據，這個週期默認爲1秒，同時從庫也會在後臺執行一個監控命令，與主庫保持一致的週期去比較，複製過來記錄的ts值與主庫上的同一條ts值，差值爲0表示無延時，差值越大表示延時的秒數越多。咱們都知道複製是異步的ts不願徹底一致，因此該工具容許半秒的差距，在這以內的差別均可忽略認爲無延時。這個工具就是經過實打實的複製，巧妙的借用timestamp來檢查延時；

讀者福利

歡迎工做一到五年的Java工程師朋友們加入Java架構開發：277763288

羣內提供免費的Java架構學習資料（裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用本身每一分每一秒的時間來學習提高本身，不要再用"沒有時間「來掩飾本身思想上的懶惰！趁年輕，使勁拼，給將來的本身一個交代！

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程