時(shí)間：2015-06-28 00:00:00 來源：IT貓撲網(wǎng) 作者：網(wǎng)管聯(lián)盟 我要評論(2)
公司里有兩個mysql服務(wù)器做主從同步，某天Nagios發(fā)來報(bào)警短信，mysqla is down...趕緊聯(lián)系機(jī)房，機(jī)房的人反饋來的信息是 HARDWARE ERROR 后面信息省略，讓機(jī)房記下錯誤信息后讓他們幫忙重啟下看是不是能正常起來，結(jié)果竟然正常起來了，趕緊導(dǎo)出所有數(shù)據(jù)。
問題又出現(xiàn)了，nagios 又報(bào)警，mysql_AB error，檢查從庫
show slave status \G; 果然
Slave_IO_Running: Yes
Slave_SQL_Running: No
而且出現(xiàn)了1062錯誤，還提示
Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)'
很顯然，由于主庫重啟導(dǎo)致 從庫數(shù)據(jù)不同步而且主鍵沖突。查看error 日志發(fā)現(xiàn)error日志文件變得好大，比以前大了將近好幾倍，
tail -f mysql_error.log 最開始查看到的是這條信息
發(fā)現(xiàn)這條信息
[ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296
報(bào)錯和上面的意思差不多，
最先想到的就是首先手動同步一下，從庫上首先 stop slave;停止同步
進(jìn)入主庫鎖表，
FLUSH TABLES WITH READ LOCK；
mysql> show master status;
+-------------------+-----------+--------------+------------------+
| File? | Position? | Binlog_Do_DB | Binlog_Ignore_DB |
+-------------------+-----------+--------------+------------------+
| ufo.000063 | 159164526 |? |????? |
+-------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)
進(jìn)入從庫
mysql>change master to master_host='192.168.1.141', master_user='slave',
master_password='xxx',
master_port=3306,
master_log_file='ufo.000063',
master_log_pos=159164526;
完成上面這些后
start slave;
回到主庫
unlock tables; 解鎖
回到從庫 查看
show slave status \G;
發(fā)現(xiàn)正常了，長處了一口氣。可是還沒過一分鐘，發(fā)現(xiàn)又開始報(bào)錯了，還是最開始那個錯誤，這是怎么回事...
于是又想到了跳過錯誤的辦法，（不過我不太喜歡用這種方法）馬上進(jìn)入從庫
stop slave;
set global sql_slave_skip_counter=1; （1是指跳過一個錯誤）
slave start;
再show slave status \G;查看
還是報(bào)錯 只不過 原來的 164761 變成了 165881，連續(xù)執(zhí)行了幾次后
除了上面的數(shù)值 在變，錯誤依然還在
郁悶了，看來只能先強(qiáng)制跳過 1062錯誤了，于是修改從庫的/etc/my.cnf文件
在里面的[mysqld]下面加入了一行
slave-skip-errors = 1062 (忽略所有的1062錯誤)
重啟下從庫的mysql /etc/init.d/mysqld restart
再 show slave status \G;一下發(fā)現(xiàn)正常了，但是我知道這時(shí)的數(shù)據(jù)可能已經(jīng)不同步了，
再次查看一下日志，讓我感到意外的是tail -f mysql_error.log 出現(xiàn)大量的
.......
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1
.........
日志里面有大量的這種警告，意思應(yīng)該是statement 格式不安全，用vim 打開他看了一下，發(fā)現(xiàn)好多這類警告，我說為什么錯誤日志怎么變這么大了呢！！
statement format 應(yīng)該是 binlog的一種格式，進(jìn)入從庫查看一下
show global variables like 'binlog_format';
果然當(dāng)前的格式為statement
我需要把格式改為 mixed格式
修改從庫的 my.cfg
在[mysqld]下面加入下面這行
binlog_format=mixed
然后重啟mysql服務(wù)，發(fā)現(xiàn)錯誤日志里的 警告 都停止了。這回清靜多了~~
我突然想起一件事，記得有朋友說過 RBR 模式可以解決很多因?yàn)橹麈I沖突導(dǎo)致的主從無法同步情況，想到這里我就想要不要把 slave-skip-errors = 1062 去掉再試試，
于是就進(jìn)入到my.cnf 里在注釋掉了 slave-skip-errors = 1062
再次重新啟動 mysql服務(wù)
進(jìn)入從庫
show slave status \G;
.........
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
........
恢復(fù)了?。?！有觀察了一段時(shí)間沒有出現(xiàn)問題這才放心，
看來導(dǎo)致 mysql 主從復(fù)制出錯的原因還真不少修復(fù)的辦法也不止一個，binlog的格式也是其中之一。
希望遇到和這次一樣問題的朋友看到這篇文章后會得到 一些啟發(fā)和解決問題的方法~~
關(guān)鍵詞標(biāo)簽：MYSQL同步故障
相關(guān)閱讀
熱門文章
Xbox Game Pass
10款MySQL數(shù)據(jù)庫客戶端圖形界面管理工具推薦
MySQL常用維護(hù)管理工具
MySQL數(shù)據(jù)庫啟動失敗1067進(jìn)程意外終止的解決辦法總結(jié)
人氣排行 10款MySQL數(shù)據(jù)庫客戶端圖形界面管理工具推薦 MySQL數(shù)據(jù)庫啟動失敗1067進(jìn)程意外終止的解決辦法總結(jié) Mysql 1045錯誤解決辦法 MySQL服務(wù)器進(jìn)程CPU占用100%解決辦法 MySQL導(dǎo)出導(dǎo)入命令的用例 MySQL連接字符串的實(shí)際操作步驟匯總 MySQL無法啟動、無法停止各種解決方法總結(jié) 三種常用的MySQL建表語句