MySQL主從數據庫同步延遲問題解決（轉）

最近在作MySQL主從數據庫同步測試，發現了一些問題，其中主從同步延遲問題是其中之一，下面內容是從網上找到的一些講解，記錄下來以便本身學習；

MySQL的主從同步是一個很成熟的架構，優勢爲：①在從服務器能夠執行查詢工做(即咱們常說的讀功能)，下降主服務器壓力;②在從主服務器進行備份，避免備份期間影響主服務器服務;③當主服務器出現問題時，能夠切換到從服務器。

MySQL主從同步故障－Slave_SQL_Running: No http://www.linuxidc.com/Linux/2014-02/96945.htm

MySQL主從同步搭建 http://www.linuxidc.com/Linux/2013-12/93934.htm

MySQL主從複製配置詳述 http://www.linuxidc.com/Linux/2014-02/97136.htm

MySQL Replication(主從服務器)配置實例 http://www.linuxidc.com/Linux/2013-12/94485.htm

在Linux系統中作MySQL數據庫主從服務器 http://www.linuxidc.com/Linux/2013-12/93986.htm

MySQL 安裝與主從配置 http://www.linuxidc.com/Linux/2013-12/93378.htm

相信你們對於這些好處已經很是瞭解了，在項目的部署中也採用這種方案。可是MySQL的主從同步一直有從庫延遲的問題，那麼爲何會有這種問題。這種問題如何解決呢？

1. MySQL數據庫主從同步延遲原理。

2. MySQL數據庫主從同步延遲是怎麼產生的。

3. MySQL數據庫主從同步延遲解決方案。

1. MySQL數據庫主從同步延遲原理。

答：談到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數據庫主從同步延遲解決方案

答：最簡單的減小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

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只會在整個操做系統 掛了時纔可能丟數據。