溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

mysql復(fù)制出錯怎么辦

發(fā)布時間:2022-01-14 16:10:28 來源:億速云 閱讀:127 作者:小新 欄目:數(shù)據(jù)庫

小編給大家分享一下mysql復(fù)制出錯怎么辦,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!

mysql復(fù)制又出錯了,同事在用navicat操作主,引起不同步.
1. show slave stauts\G
            Master_Log_File: -bin.000027
        Read_Master_Log_Pos: 604734247
             Relay_Log_File: mysqld-relay-bin.000002
              Relay_Log_Pos: 85998
      Relay_Master_Log_File: mysql-bin.000027
           Slave_IO_Running: Yes
          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: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
               Skip_Counter: 0
        Exec_Master_Log_Pos: 588269801
            Relay_Log_Space: 16550444
 
根據(jù)提示檢查到底是主binary log還是relay log 出錯.
   1. 檢查主binary log
mysqlbinlog --no-defaults  --start-position=588269801  mysql-bin.000027 > master.sql
   2.檢查從relay log
mysqlbinlog --no-defaults  --start-position=85998    mysqld-relay-bin.000002 > slave.sql
如果兩個log中有錯誤的話,上面命令是執(zhí)行不成功的必須加上 –f 參數(shù).
然后在master.sql中找到如下命令,其中Unknown event就是不能被識別執(zhí)行的命令,relay_log就卡在這里了.
# at 588269801
#110816 14:45:50 server id 1  end_log_pos 588269874     Query   thread_id=7249444       exec_time=0     error_code=0
SET TIMESTAMP=1313477150/*!*/;
BEGIN
/*!*/;
# at 588269874
#110816 14:45:50 server id 1  end_log_pos 588269941
# Unknown event
# at 588269941
#110816 14:45:50 server id 1  end_log_pos 588270071
# Unknown event
# at 588270071
#110816 14:45:50 server id 1  end_log_pos 588270145     Query   thread_id=7249444       exec_time=0     error_code=0
SET TIMESTAMP=1313477150/*!*/;
COMMIT
知道了原因就好辦了,直接跳過即可.
1. stop slave;
2. change master to master_host='192.168.1.13', master_user='slave', master_password='slavepasswd', MASTER_LOG_FILE='mysql-bin.000027', MASTER_LOG_POS=588270071;
3. start slave;
當(dāng)然如果有多個這樣的Unknown event事件,這樣做就很麻煩了.
可以先把master.sql 在slave上執(zhí)行,然后找到文件最后一個的postion的值, 重新設(shè)置change master 也是可行的.
 
不知道SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;會不會對這種情況有效,剛開始怎么沒想到要試一試呢?

以上是“mysql復(fù)制出錯怎么辦”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對大家有所幫助,如果還想學(xué)習(xí)更多知識,歡迎關(guān)注億速云行業(yè)資訊頻道!

向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI