mysql非常流行，其非常好用的複製特性功不可沒，但是運維人員對複製卻是又愛又恨，為什麼呢，因為在福只能幫忙解決讀寫分離，但是複製延遲，又會帶來業務不可用或者使用者體驗不好。
例如：使用者訂單已付款，由於讀寫分離和mysql複製延遲，導致使用者訂單狀態顯示未付款。
要想解決複製延遲，就得先了解複製原理，mysql的複製其實是有2個程序在處理，乙個是io執行緒，乙個是sql執行緒，io執行緒主要負責拉取binlog日誌，這個程序不會出現瓶頸，sql執行緒則需要讀取日誌，並解析成sql去執行，複製延遲一般出現在sql執行緒執行上，這就好比有上千人在家樂福同時購物，最後收銀台確實只有乙個，這樣肯定需要排隊，一段排隊，就會產生延遲。
那怎麼解決複製的問題呢？
下面有3個方案
方案一：修改以下2個引數
sync_binlog=0innodb_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執行緒序列執行的方式，變成並行執行，並行複製怎麼解決複製延遲，下回分解
mysql雙主複製的缺點 mysql雙主複製總結
雙主複製 1 在兩台伺服器上各自建立乙個具有複製許可權的使用者 2 修改配置檔案 主伺服器a上 mysqld server id 10 log bin mysql bin relay log relay mysql auto increment offset 1 起始值 auto increment...
mysql 延時排查 排查Mysql主從延時的問題
一 背景 突然發現每天中午以及下午的延時變高，檢視主從的延時經常達到10分鐘以上，整體使用的是mysql proxy實現的讀寫分離機制，所以業務的影響主要是插入資料後久久不能查詢到資料。由於使用mysql業務比較多，一時之間不能快速定位，導致該問題存在的較長時間。二 解決思路 1.到了案發時間，下午...
MySQL的非同步複製 全同步複製與半同步複製
非同步複製 非同步複製，主庫將事務 binlog 事件寫入到 binlog 檔案中，此時主庫只會通知一下 dump 執行緒傳送這些新的 binlog，然後主庫就會繼續處理提交操作，而此時不會保證這些 binlog 傳到任何乙個從庫節點上。半同步複製 半同步複製，是介於全同步複製與全非同步複製之間的一...