Mysql主從不一樣步解決方法
主從同步配置好後，運行了一時間，出現了不一樣步現象，用命令檢查，看到從上報下面錯誤：
msyq > show slave status \G; Last_Errno: 1062 Last_Error: Error 'Duplicate entry '149' for key 'PRIMARY'' on query. Default database: 'zabbix'. Query: 'insert into escalations (escalationid,actionid,status,triggerid,itemid,eventid,r_eventid) values (149,7,0,16272,null,3334811,null)'
看這個報錯，應該是主MYSQL上建表時，主鍵有重複的值報錯，形成從不能同步。
解決的辦法是在從庫上執行:
mysql> slave stop; mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1; mysql> slave start;
上面的方法能夠解決問題，還有一種解決問題的辦法是經過修改mysql的配置文件，讓從庫的同步線程忽略這個錯誤，方法：
修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行 slave_skip_errors = 1062 ,保存重啓mysql
mysql slave能夠正常同步了
binlog三種模式的區別
1.Row
日誌中會記錄成每一行數據被修改的形式，而後在slave端再對相同的數據進行修改，只記錄要修改的數據，只有value，不會有sql多表關聯的狀況。
優勢：在row模式下，bin-log中能夠不記錄執行的sql語句的上下文相關的信息，僅僅只須要記錄那一條記錄被修改了，修改爲什麼樣了，因此row的日誌內容會很是清楚的記錄下每一行數據修改的細節，很是容易理解。並且不會出現某些特定狀況下的存儲過程和function，以及trigger的調用和出發沒法被正確複製問題。
缺點：在row模式下，全部的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。
mysql> insert into username(username) select * from aa; ERROR 1146 (42S02): Table 'test.username' doesn't exist mysql> insert into user(username) select * from aa; Query OK, 1 row affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0
查看binlog
root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000017 BINLOG ' 63EfUBNQAAAALgAAAA8CAAAAAA8AAAAAAAEABHRlc3QABHVzZXIAAgIPAi0AAA== 63EfUBdQAAAAJgAAADUCAAAAAA8AAAAAAAEAAv/8BAAFYmFveXU= '/*!*/; ### INSERT INTO test.user ### SET ### @1=4 /* SHORTINT meta=0 nullable=0 is_null=0 */ ### @2='baoyu' /* VARSTRING(45) meta=45 nullable=0 is_null=0 */ # at 565 #120806 0:27:39 server id 80 end_log_pos 592 Xid = 20 COMMIT/*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
因而可知，row模式是針對每一行的數據，而於關聯表無關，它把關聯中的相應數據記錄在log中。這樣一來會產生大量的數據。
2.statement
每一條會修改數據的sql都會記錄到master的binlog中，slave在複製的時候sql進程會解析成和原來master端執行多相同的sql再執行。
優勢：在statement模式下首先就是解決了row模式的缺點，不須要記錄每一行數據的變化減小了binlog日誌量，節省了I/O以及存儲資源，提升性能。由於他只須要記錄在master上所執行的語句的細節以及執行語句的上下文信息。
缺點：在statement模式下，因爲他是記錄的執行語句，因此，爲了讓這些語句在slave端也能正確執行，那麼他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證全部語句在slave端被執行的時候可以獲得和在master端執行時候相同的結果。另外就是，因爲mysql如今發展比較快，不少的新功能不斷的加入，使mysql的複製遇到了不小的挑戰，天然複製的時候涉及到越複雜的內容，bug也就越容易出現。在statement中，目前已經發現很多狀況會形成Mysql的複製出現問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，好比：sleep()函數在有些版本中就不能被正確複製，在存儲過程當中使用了last_insert_id()函數，可能會使slave和master上獲得不一致的id等等。因爲row是基於每一行來記錄的變化，因此不會出現，相似的問題。
mysql> insert into user(username) values('xuebinbin');
ERROR 1598 (HY000): Binary logging not possible. Message: Transaction level 'READ-COMMITTED' in InnoDB is not safe for binlog mode 'STATEMENT'
mysql> SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
-> ;
Query OK, 0 rows affected (0.00 sec)
mysql> insert into user(username) values('xuebinbin');
Query OK, 1 row affected (0.00 sec)
查看binlog
root@xuebinbin:/vobiledata/mysqllog# mysqlbinlog mysql-bin.000008
BEGIN
/*!*/;
# at 174
#120806 14:47:35 server id 80 end_log_pos 202 Intvar
SET INSERT_ID=2/*!*/;
# at 202
#120806 14:47:35 server id 80 end_log_pos 311 Query thread_id=5 exec_time=0 error_code=0
use test/*!*/;
SET TIMESTAMP=1344235655/*!*/;
insert into user(username) values('xuebinbin')
/*!*/;
# at 311
#120806 14:47:35 server id 80 end_log_pos 338 Xid = 20
COMMIT/*!*/;
# at 338
#120806 14:53:18 server id 80 end_log_pos 357 Stop
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
結果發現statement是以sql記錄形式記錄的。這樣的話一個sql就只記錄一條，減小了大量的數據存儲。
3.Mixed
從官方文檔中看到，以前的 MySQL 一直都只有基於 statement 的複製模式，直到 5.1.5 版本的 MySQL 纔開始支持 row 複製。從 5.0 開始，MySQL 的複製已經解決了大量老版本中出現的沒法正確複製的問題。可是因爲存儲過程的出現，給 MySQL Replication 又帶來了更大的新挑戰。另外，看到官方文檔說，從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 以外的第三種複製模式：Mixed，實際上就是前兩種模式的結合。在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日誌形式，也就是在 statement 和 row 之間選擇一種。新版本中的 statment 仍是和之前同樣，僅僅記錄執行的語句。而新版本的 MySQL 中對 row 模式也被作了優化，並非全部的修改都會以 row 模式來記錄，好比遇到表結構變動的時候就會以 statement 模式來記錄，若是 SQL 語句確實就是 update 或者 delete 等修改數據的語句，那麼仍是會記錄全部行的變動。
Mysql Binlog日誌分析
經過MysqlBinlog指令查看具體的mysql日誌，以下:
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// SET TIMESTAMP=1350355892/*!*/; BEGIN /*!*/; # at 1643330 #121016 10:51:32 server id 1 end_log_pos 1643885 Query thread_id=272571 exec_time=0 error_code=0 SET TIMESTAMP=1350355892/*!*/; Insert into T_test….) /*!*/; # at 1643885 #121016 10:51:32 server id 1 end_log_pos 1643912 Xid = 0 COMMIT/*!*/; ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.開始事物的時間:mysql
SET TIMESTAMP=1350355892/*!*/;sql
BEGINbash
2.sqlevent起點函數
#at 1643330 :爲事件的起點，是以1643330字節開始。性能
3.sqlevent 發生的時間點優化
#121016 10:51:32:是事件發生的時間，spa
4.serverId線程
server id 1 :爲master 的serverIdscala
5.sqlevent終點及花費時間，錯誤碼日誌
end_log_pos 1643885:爲事件的終點，是以1643885 字節結束。
execTime 0: 花費的時間
error_code=0:錯誤碼
Xid:事件指示提交的XA事務