轉自：http://blog.163.com/yang_jianli/blog/static/16199000620114635036443/
基本上用了mysql作爲oltp業務的，基本上都會配置mysql的主從，一方面用mysql的主從做數據庫的讀寫分離，另一方面mysql本身的單機備份不是很強，一般採用主從架構，在從上進行數據備份。
在這過程中或多或少出現一些主從不同步的情況，本文將對數據主從不同步的情況進行簡單的總結，在看這篇文章請注意了本文主要從數據庫層面上探討數據庫的主從不一致的情況，並不對主從的本身數據不一致引起的主從不同步進行說明：
1.網絡的延遲
由於mysql主從複製是基於binlog的一種異步複製，通過網絡傳送binlog文件，理所當然網絡延遲是主從不同步的絕大多數的原因，特別是跨機房的數據同步出現這種機率非常的大，所以做讀寫分離，注意從業務層進行前期設計。
2.主從兩臺機器的負載不一致
由於mysql主從複製是主上面啓動1個io線程，而從上面啓動1個sql線程和1個io線程，當中任何一臺機器的負載很高，忙不過來，導致其中的任何一個線程出現資源不足，都將出現主從不一致的情況。
3.max_allowed_packet設置不一致
主上面設置的max_allowed_packet比從大，當一個大的sql語句，能在主上面執行完畢，從上面設置過小，無法執行，導致的主從不一致。
4.key自增鍵開始的鍵值跟自增步長設置不一致引起的主從不一致。
5.mysql異常宕機情況下，如果未設置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現binlog或者relaylog文件出現損壞，導致主從不一致。
6.mysql本身的bug引起的主從不同步。
7.版本不一致，特別是高版本是主，低版本爲從的情況下，主上面支持的功能，從上面不支持該功能。
以上是我遇到的一些主從不同步的情況。或許還有其他的一些不同步的情況，請說出你所遇到的主從不一致的情況。
基於以上情況，先保證max_allowed_packet，自增鍵開始點和增長點設置一致，再者犧牲部分性能在主上面開啓sync_binlog，對於採用innodb的庫，推薦配置下面的內容
|
1
2
3
|
innodb_flush_logs_at_trx_commit = 1 innodb-support_xa = 1 # Mysql 5.0 以上 innodb_safe_binlog # Mysql 4.0 |
同時在從上面推薦加入下面兩個參數
|
1
2
|
skip_slave_start read_only |
