線上一個mysql主備延遲很大，master節點寫入頻繁，slave節點積累大量relay-log無法即使寫入。
參考：https://www.cnblogs.com/conanwang/p/6006444.html
-
為什么會出現大量relay-log
首先這個需要從mysql的同步機制說起，同步-->半同步
Master節點的數據庫實例並發跑多個線程同時提交事務，提交的事務按照邏輯的時間（數據庫LSN號）順序地寫入binary log日志，slave節點通過I/O線程寫到本地的relay log日志，為了保證主備數據一致性，slave節點必須按照同樣的順序執行，如果順序不一致容易造成主備庫數據不一致的風險。但是slave節點只有SQL單線程來執行relay log中的日志信息重放主庫提交得事務，造成主備數據庫存在延遲 -
處理方法
能物理處理的建議直接物理解決
a. 磁盤使用SSD
b. 磁盤組raid10
c. 從文件系統層面/內核優化層面處理IO問題
mysql的處理方法
想方法讓slave多線程執行relay log
MySQL 5.6版本引入並發復制（schema級別），基於schema級別的並發復制核心思想：“不同schema下的表並發提交時的數據不會相互影響，即slave節點可以用對relay log中不同的schema各分配一個類似SQL功能的線程，來重放relay log中主庫已經提交的事務，保持數據與主庫一致”。
MySQL 5.6基於schema級別的並發復制能夠解決當業務數據的表放在不同的database庫下，但是實際生產中往往大多數或者全部的業務數據表都放在同一個schema下，在這種場景即使slave_parallel_workers>0設置也無法並發執行relay log中記錄的主庫提交數據。 高並發的情況下，由於slave無法並發執行同個schema下的業務數據表，依然會造成主備延遲的情況。
MySQL 5.7 引入Enhanced Muti-threaded slaves,當slave配置slave_parallel_workers>0並且global.slave_parallel_type＝‘LOGICAL_CLOCK’,可支持一個schema下，slave_parallel_workers個的worker線程並發執行relay log中主庫提交的事務。但是要實現以上功能，需要在master機器標記binary log中的提交的事務哪些是可以並發執行，雖然MySQL 5.6已經引入了binary log group commit，但是沒有將可以並發執行的事務標記出來。
MySQL 5.7 GA版本推出的 Enhanced Multi-threaded Slaves功能，徹底解決了之前版本主備數據復制延遲的問題，開啟該功能參數如下：
# slave機器
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-type=DATABASE #兼容MySQL 5.6基於schema級別的並發復制
slave-parallel-workers=4 ＃開啟多線程復制
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON