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

目前創(chuàng)新互聯(lián)已為成百上千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管維護、企業(yè)網(wǎng)站設(shè)計、萊山網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(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)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！