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提供了從伺服器狀態命令，可以通過 show slave status 進行檢視， 比如可以看看Seconds_Behind_Master引數的值來判斷，是否有發生主從延時。
其值有這麼幾種：
NULL - 表示io_thread或是sql_thread有任何一個發生故障，也就是該執行緒的Running狀態是No,而非Yes.
0 - 該值為零，是我們極為渴望看到的情況，表示主從複製狀態正常
4. MySQL資料庫主從同步延遲解決方案
- a. 我們知道因為主伺服器要負責更新操作， 他對安全性的要求比從伺服器高， 所有有些設定可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設定，而slave則不需要這麼高的資料安全，完全可以講sync_binlog設定為0或者關閉binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 可以設定為0來提高sql的執行效率 這個能很大程度上提高效率。另外就是使用比主庫更好的硬體裝置作為slave。
- b. 就是把，一臺從伺服器當度作為備份使用， 而不提供查詢， 那邊他的負載下來了， 執行relay log 裡面的SQL效率自然就高了。
- c. 增加從伺服器嘍，這個目的還是分散讀的壓力， 從而降低伺服器負載。
最簡單的減少slave同步延時的方案就是在架構上做優化，儘量讓主庫的DDL快速執行。還有就是主庫是寫，對資料安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設定，而slave則不需要這麼高的資料安全，完全可以講sync_binlog設定為0或者關閉binlog，innodb_flushlog也 可以設定為0來提高sql的執行效率。另外就是使用比主庫更好的硬體裝置作為slave。
sync_binlog 配置說明：
sync_binlog”：這個引數是對於MySQL系統來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的效能損
耗，而且還影響到MySQL中資料的完整性。對於“sync_binlog”引數的各種設定的說明如下：
sync_binlog=0，當事務提交之後，MySQL不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟，而
讓Filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁碟。
sync_binlog=n，當每進行n次事務提交之後，MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中
的資料強制寫入磁碟。
在MySQL中系統預設的設定是sync_binlog=0，也就是不做任何強制性的磁碟重新整理指令，這時候的效能是最好的，
但是風險也是最大的。因為一旦系統Crash，在binlog_cache中的所有binlog資訊都會被丟失。而當設定為“1”
的時候，是最安全但是效能損耗最大的設定。因為當設定為1的時候，即使系統Crash，也最多丟失binlog_cache
中未完成的一個事務，對實際資料沒有任何實質性影響。
從以往經驗和相關測試來看，對於高併發事務的系統來說，“sync_binlog”設定為0和設定為1的系統寫入效能差距
可能高達5倍甚至更多。
innodb_flush_log_at_trx_commit 配置說明：
預設值1的意思是每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬碟，這是很費時的。特別是使用
電 池供電快取（Battery backed up cache）時。設成2對於很多運用，特別是從MyISAM錶轉過來的是可以的，
它的意思是不寫入硬碟而是寫入系統快取。日誌仍然會每秒flush到硬 盤，所以你一般不會丟失超過1-2秒的更
新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的資料。而值2只會在整個作業系統
掛了時才可能丟資料。