談談Mysql主從同步延遲分析及解決方案

1、MySQL的數據庫主從複製原理

MySQL主從複製實際上基於二進制日誌，原理能夠用一張圖來表示：

分爲四步走：

1. 主庫對全部DDL和DML產生的日誌寫進binlog；

2. 主庫生成一個 log dump 線程，用來給從庫I/O線程讀取binlog；

3. 從庫的I/O Thread去請求主庫的binlog，並將獲得的binlog日誌寫到relay log文件中；

4. 從庫的SQL Thread會讀取relay log文件中的日誌解析成具體操做，將主庫的DDL和DML操做事件重放。

關於DDL和DML

SQL語言共分爲四大類：查詢語言DQL，控制語言DCL，操縱語言DML，定義語言DDL。

DQL：能夠簡單理解爲SELECT語句；

DCL：GRANT、ROLLBACK和COMMIT一類語句；

DML：能夠理解爲CREATE一類的語句；

DDL：INSERT、UPDATE和DELETE語句都是；

2、主從複製存在的問題

1. 主庫宕機後，數據可能丟失；

2. 主從同步延遲。

3、MySQL數據庫主從同步延遲產生緣由

緣由分析

MySQL的主從複製都是單線程的操做，主庫對全部DDL和DML產生的日誌寫進binlog，因爲binlog是順序寫，因此效率很高。Slave的SQL Thread線程將主庫的DDL和DML操做事件在slave中重放。DML和DDL的IO操做是隨即的，不是順序的，成本高不少。另外一方面，因爲SQL Thread也是單線程的，當主庫的併發較高時，產生的DML數量超過slave的SQL Thread所能處理的速度，或者當slave中有大型query語句產生了鎖等待那麼延時就產生了。

常見緣由：Master負載太高、Slave負載太高、網絡延遲、機器性能過低、MySQL配置不合理。

4、主從延時排查方法

經過監控 show slave status 命令輸出的Seconds_Behind_Master參數的值來判斷：

NULL，表示io_thread或是sql_thread有任何一個發生故障；

0，該值爲零，表示主從複製良好；

正值，表示主從已經出現延時，數字越大表示從庫延遲越嚴重。

5、解決方案

解決數據丟失的問題：

1. 半同步複製

從MySQL5.5開始，MySQL已經支持半同步複製了，半同步複製介於異步複製和同步複製之間，主庫在執行完事務後不馬上返回結果給客戶端，須要等待至少一個從庫接收到並寫到relay log中才返回結果給客戶端。相對於異步複製，半同步複製提升了數據的安全性，同時它也形成了一個TCP/IP往返耗時的延遲。

2. 主庫配置sync_binlog=1，innodb_flush_log_at_trx_commit=1

sync_binlog的默認值是0，MySQL不會將binlog同步到磁盤，其值表示每寫多少binlog同步一次磁盤。

innodb_flush_log_at_trx_commit爲1表示每一次事務提交或事務外的指令都須要把日誌flush到磁盤。

注意:將以上兩個值同時設置爲1時，寫入性能會受到必定限制，只有對數據安全性要求很高的場景才建議使用，好比涉及到錢的訂單支付業務，並且系統I/O能力必須能夠支撐！

解決從庫複製延遲的問題：

1. 優化網絡

2. 升級Slave硬件配置

3. Slave調整參數，關閉binlog，修改innodb_flush_log_at_trx_commit參數值

4. 升級MySQL版本到5.7，使用並行複製

更多優化方案措施歡迎廣大博友補充並糾正啦...