MYSQL主從不一樣步延遲原理分析及解決方案（摘自http://www.jb51.net/article/41545.htm）

1. MySQL數據庫主從同步延遲原理。
要說延時原理，得從mysql的數據庫主從複製原理提及，mysql的主從複製都是單線程的操做，
主 庫對全部DDL和DML產生binlog，binlog是順序寫，因此效率很高，slave的Slave_IO_Running線程到主庫取日誌，效率很 比較高，下一步，問題來了，slave的Slave_SQL_Running線程將主庫的DDL和DML操做在slave實施。DML和DDL的IO操做 是隨即的，不是順序的，成本高不少，還可能可slave上的其餘查詢產生lock爭用，因爲Slave_SQL_Running也是單線程的，因此一個 DDL卡主了，須要執行10分鐘，那麼全部以後的DDL會等待這個DDL執行完纔會繼續執行，這就致使了延時。有朋友會問：「主庫上那個相同的DDL也需 要執行10分，爲何slave會延時？」，答案是master能夠併發，Slave_SQL_Running線程卻不能夠。

2. MySQL數據庫主從同步延遲是怎麼產生的。
當主庫的TPS併發較高時，產生的DDL數量超過slave一個sql線程所能承受的範圍，那麼延時就產生了，固然還有就是可能與slave的大型query語句產生了鎖等待。

3. MySQL數據庫主從同步延遲解決方案。
丁奇的transefer是一個不錯的方案，不過通常公司受限於對mysql的代碼修改能力的限制和對mysql的掌控能力，仍是不太適合。
最 簡單的減小slave同步延時的方案就是在架構上作優化，儘可能讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，好比 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不須要這麼高的數據安全，徹底能夠講sync_binlog設置爲0或者關閉binlog，innodb_flushlog也 能夠設置爲0來提升sql的執行效率。另外就是使用比主庫更好的硬件設備做爲slave。
mysql-5.6.3已經支持了多線程的主從複製。原理和丁奇的相似，丁奇的是以表作多線程，oracle使用的是以數據庫(schema)爲單位作多線程，不一樣的庫可使用不一樣的複製線程。

sync_binlog=1 o
     This makes MySQL synchronize the binary log's contents to disk each time it commits a transaction
     默認狀況下，並非每次寫入時都將binlog與硬盤同步。所以若是操做系統或機器(不單單是MySQL服務器)崩潰，有可能binlog中最後的語句丟 失了。要想防止這種狀況，你可使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入後與硬盤 同步。即便sync_binlog設置爲1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。若是使用InnoDB表，MySQL服務器 處理COMMIT語句，它將整個事務寫入binlog並將事務提交到InnoDB中。若是在兩次操做之間出現崩潰，重啓時，事務被InnoDB回滾，但仍 然存在binlog中。能夠用--innodb-safe-binlog選項來增長InnoDB表內容和binlog之間的一致性。(註釋：在MySQL 5.1中不須要--innodb-safe-binlog；因爲引入了XA事務支持，該選項做廢了），該選項能夠提供更大程度的安全，使每一個事務的 binlog(sync_binlog =1)和(默認狀況爲真)InnoDB日誌與硬盤同步，該選項的效果是崩潰後重啓時，在滾回事務後，MySQL服務器從binlog剪切回滾的 InnoDB事務。這樣能夠確保binlog反饋InnoDB表的確切數據等，並使從服務器保持與主服務器保持同步(不接收 回滾的語句)。

innodb_flush_log_at_trx_commit （這個很管用）
抱 怨Innodb比MyISAM慢 100倍？那麼你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都須要把日誌寫入（flush）硬盤，這是很費時的。特別是使用電 池供電緩存（Battery backed up cache）時。設成2對於不少運用，特別是從MyISAM錶轉過來的是能夠的，它的意思是不寫入硬盤而是寫入系統緩存。日誌仍然會每秒flush到硬 盤，因此你通常不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即便MySQL掛了也可能會丟失事務的數據。而值2只會在整個操做系統 掛了時纔可能丟數據。