Mysql複製延遲解決方案
自從軟件開源火爆互聯網以後，一些開源數據庫也愈來愈受到你們關注和重視，自從阿里去IOE以後，更是全面推廣開源數據庫Mysql，替換商業數據庫Oracle，通過通過雙11的洗禮，已證實Mysql的穩定性和可靠性，這也引起了大批互聯網公司使用Mysql，例如小米科技，360，美團，58同城等，下面一張圖是2016年數據庫使用排名，能夠看出Mysql已經成爲排名第二，距離第一已是一步之遙mysql
固然在使用Mysql數據庫時，也會碰到一些問題，複製延遲就是最多見的。例如在市場搞促銷，雙11，雙12等等，致使業務數據劇增，Mysql複製處理超載，就會出現延遲，而一旦出現延遲，在有些場景就會致使用戶體驗降低，例如：用戶訂單已付款，因爲讀寫分離和mysql複製延遲，致使用戶訂單狀態顯示未付款。sql
要想解決複製延遲，就得先了解複製原理，Mysql的複製實際上是有2個進程在處理，一個是IO線程，一個是sql線程，IO線程主要負責拉取binlog日誌，這個進程不會出現瓶頸，sql線程則須要讀取日誌，並解析成sql去執行，複製延遲通常出如今sql線程執行上，這就比如有上千人在家樂福同時購物，最後收銀臺確實只有一個，這樣確定須要排隊，一段排隊，就會產生延遲。數據庫
那怎麼解決複製的問題呢？安全
下面有3個方案，能夠參考一下工具
方案一：修改如下2個參數spa
sync_binlog=0線程
innodb_flush_log_at_trx_commit=2日誌
在調整上述參數以前，先解釋一下mysql中這2個參數做用
進程
sync_binlog=0，當事務提交以後，MySQL不作fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定何時來作同步，或者cache滿了以後才同步到磁盤。事務
sync_binlog=n，當每進行n次事務提交以後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。
innodb_flush_log_at_trx_commit設置爲0，log buffer將每秒一次地寫入log file中，而且log file的flush(刷到磁盤)操做同時進行.該模式下，在事務提交的時候，不會主動觸發寫入磁盤的操做。
innodb_flush_log_at_trx_commit設置爲1，每次事務提交時MySQL都會把log buffer的數據寫入log file，而且flush(刷到磁盤)中去.
若是innodb_flush_log_at_trx_commit設置爲2，每次事務提交時MySQL都會把log buffer的數據寫入log file.可是flush(刷到磁盤)操做並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁盤)操做。
上述2個參數是經過調整mysql事物提交速度，去提高複製效率的，固然這個方法是犧牲數據安全爲代價的，這種方式也是在被逼無奈的狀況下使用。
方案二：開發一套預熱工具
sql線程解析出來的日誌，基本都是update,insert,delete語句，insert語句自不說，update和delete語句怎麼提高執行效率呢？
那得先看看update在數據庫中執行的過程，首先數據庫得先去緩衝區看看涉及的數據塊存不存在，若是不存在，則會去磁盤上讀取，加載到緩衝區，這樣就會產生一個物理IO，若是數據塊在緩衝區存在，則直接從緩衝區讀取，只會有一個邏輯IO，物理IO和邏輯IO的區別就在於，一個從磁盤讀取，一個從內從讀取，速度相差10倍以上
按照這個思路，就是開發一套程序，去解析binlog日誌，並將update,delete轉換成select語句，預熱要使用的數據塊，加快sql線程執行sql語句的效率，提高複製效率，下降複製延遲
方案三：使用mysql5.7
官方發佈的mysql5.7版本已經支持並行複製，原來的sql線程串行執行的方式，變成並行執行，不過此版本還得通過業界驗證
下面是個人公衆號二維碼，歡迎添加