- 論壇徽章:
- 0
|
我使用主-分發(fā)-從的結構模擬mysql復制;分發(fā)庫使用blackhole引擎,實際是不貯存任何數(shù)據(jù),只作收發(fā)復制日志。
主庫為centos虛擬主機,分發(fā)庫為windows 7 64bit ,從庫是centos實體機。
mysql版本分別為 主mysql7.12 分發(fā)7.13 從庫 7.13
實際是,我有另外二部電腦,相同的配置,版本一致,沒出現(xiàn)問題。
接著,配置完畢,從分發(fā)庫至從庫的IO與SQL線程是正常的,但從主庫到分發(fā)庫的復制則出現(xiàn)了錯誤,報錯如下:
- 2016-07-24T14:28:19.810200Z 16 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'mysql-bin.000002' at position 154, relay log '.\N4EVFLR2X6U1.replicate' position: 4
- 2016-07-24T14:28:19.837202Z 15 [Note] Slave I/O thread for channel '': connected to master 'reslave@192.168.1.112:3306',replication started in log 'mysql-bin.000002' at position 154
- 2016-07-24T14:28:19.922207Z 16 [ERROR] next log error: -1 offset: 28 log: .\N4EVFLR2X6U1.replicate included: 1
- 2016-07-24T14:28:19.924207Z 16 [ERROR] Error reading relay log event for channel '': Error purging processed logs
- 2016-07-24T14:28:19.925207Z 16 [ERROR] Slave SQL for channel '': Relay log read failure: 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. Error_code: 1594
- 2016-07-24T14:28:19.930207Z 16 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000002' position 154
復制代碼 google了下,第三個最長的錯誤是最常見的,主要是復制的pos由于各種原因出現(xiàn)了偏差,重新校正就行了,但我認真對比主、從的復制文件與位置幾十遍都不湊效。
困難的是net log error與Error reading relay log...兩條錯誤,幾乎google不到。
無論我把主機reset master,從機reset slave重新開始復制都是出現(xiàn)同樣的錯誤,都是IO線程正常,而進行復制的SQL因為錯誤無法啟動。
從理論上來說應該是復制過來的語句無法執(zhí)行,但通過把mysqlbinlog導出復制語句在分發(fā)庫上實際執(zhí)行,無法看到語句有問題。
[SQL]/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
受影響的行: 0
時間: 0.001s
[SQL]
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
受影響的行: 0
時間: 0.001s
[SQL]
# at 4
#160724 18:33:11 server id 104 end_log_pos 123 CRC32 0xda3ae9db Start: binlog v 4, server v 5.7.13-log created 160724 18:33:11 at startup
# This Format_description_event appears in a relay log and was generated by the slave thread.
# at 123
#160724 18:33:11 server id 104 end_log_pos 154 CRC32 0xe26e4262 Previous-GTIDs
# [empty]
# at 154
#160724 18:34:22 server id 104 end_log_pos 210 CRC32 0xa505b2a4 Rotate to N4EVFLR2X6U1.replicate pos: 4
# at 210
#160724 18:34:22 server id 104 end_log_pos 329 CRC32 0x7d993545 Start: binlog v 4, server v 5.7.13-log created 160724 18:34:22
# This Format_description_event appears in a relay log and was generated by the slave thread.
# at 329
#160724 18:34:22 server id 104 end_log_pos 360 CRC32 0x27113558 Previous-GTIDs
# [empty]
# at 360
#700101 8:00:00 server id 10 end_log_pos 0 CRC32 0x5bce41ed Rotate to mysql-bin.000002 pos: 154
# at 407
#160724 16:00:58 server id 10 end_log_pos 0 CRC32 0xda5a7a82 Start: binlog v 4, server v 5.7.12-log created 160724 16:00:58
BINLOG '
unWUVw8KAAAAdwAAAAAAAAAAAAQANS43LjEyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
AYJ6Wto=
';
受影響的行: 0
時間: 0.000s
[SQL]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ ;
受影響的行: 0
時間: 0.001s
[SQL]
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
受影響的行: 0
時間: 0.001s
[SQL]
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
受影響的行: 0
時間: 0.001s
這是什么原因?
另外,如果我在分發(fā)庫上執(zhí)行二次start slave;SQL線程是可以啟動的,但這樣做是非正常啟動吧?!
|
|