介紹
上篇文章介紹了MMM架構的實現方法，但是上篇文章的MMM方案的複製是非同步複製，非同步複製的主要問題在於當主從存在延時時如果主機出現了故障導致了主從切換時這時將會存在資料丟失；mysql為了解決非同步複製資料丟失的問題增加了半同步複製，半同步複製存在5.5以上的版本，半同步複製的原理是客戶端在事務提交時必須等待從庫接收到binlog的迴應之後才能提交事務（當存在多個從庫時預設只需要一個從庫接受到了bInlog即可，也可以配置必須每一個從庫都必須接收到binlog但是這樣對效能影響就會很大），如果從庫當機或者故障導致binlog沒有及時傳送到從庫（由引數rpl_semi_sync_master_timeout控制，預設是10S）,這時mysql會自動轉為非同步複製，當從庫又重新啟動有新的一條binglog從主庫傳送到從庫在規定的時間內得到響應mysql又會自動轉換為半同步複製，所以半同步複製對主從之間的網路要求比較高。
mysql版本：5.6
方案：MMM+半同步複製
一、原理
5.6的半同步複製是在客戶端執行commit主庫寫入完binlog然後執行資料重新整理到磁碟後才由dump執行緒將binlog記錄傳送到從庫的io執行緒。
二、安裝配置
首先說明一下，當前的配置是基於MMM方案的配置，由於MMM方案是兩主一從，所以我在其中的雙主上面配置半同步複製，從庫上面還是原先的非同步複製。半同步複製是基於外掛來實現的，主從上面各自執行不同的外掛。
1.查詢是否支援動態外掛
主從上面都需要檢視是否支援動態外掛
2.安裝動態外掛
主備都執行
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
注意：由於我當前的雙主模式所以主和備都需要執行主從的外掛，如果只是單純的主從模式那麼主執行主的外掛從執行從的外掛即可。
檢視外掛是否安裝
3.開啟半同步複製
SET GLOBAL rpl_semi_sync_master_enabled = 1; SET GLOBAL rpl_semi_sync_slave_enabled = 1;
同樣主和備上面都同時執行上面兩個操作，注意必須是開啟全域性的變數。
4.重啟io執行緒
1.備庫執行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
2.主庫執行
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
5.配置引數
show variables like '%rpl_semi%';
rpl_semi_sync_master_enabled、rpl_semi_sync_slave_enabled
分別代表主從的半同步複製是否啟用，因為我當前是雙主模式所以即擔當了主又擔當了從，所以這裡面存在slave的引數在裡面
rpl_semi_sync_master_timeout
該引數是配置半同步複製的延時時間，當主庫發生binlog到從庫從庫在10s內還沒有返回則自動轉換為非同步複製，這個時間可以調整，預設是10S
注意：如果僅僅是作為slave那麼只有"rpl_semi_sync_slave_enable","rpl_semi_sync_trace_level"這兩個狀態，其它的4個是作為master端顯示的，由於我這裡是配置雙主模式，所有主從都存在。
6.狀態引數
show status like '%rpl_%';
這些狀態引數比較重要，通常用來對半同步複製進行分析。
Rpl_semi_sync_master_clients：有多個個半同步複製的從庫，對於當前的主來說只有backup是半同步複製的從庫，而slave是非同步複製，所以這裡是1；
Rpl_semi_sync_master_net_avg_wait_time：master等待從庫的平均響應時間，單位微妙
Rpl_semi_sync_master_net_wait_time： master等待從庫響應的總時間，單位微妙
Rpl_semi_sync_master_net_waits：master等待從庫響應的總次數
Rpl_semi_sync_master_no_times：master關閉半同步複製的次數，也就是當主從延時超過規定的時間轉換為非同步複製的次數。
Rpl_semi_sync_master_no_tx：master提交沒有被slave響應成功的次數，也可以理解為不是同步半同步複製的次數。
Rpl_semi_sync_master_status：僅噹噹前伺服器作為主庫，是否開啟了半同步複製，如果這裡是OFF代表是非同步複製，前提是當前查詢的伺服器是主伺服器。
Rpl_semi_sync_master_timefunc_failures：master呼叫時間函式失敗的次數，例如：gettimeofday().
Rpl_semi_sync_master_tx_avg_wait_time：master等待每一個事務的平均時間，單位微妙
Rpl_semi_sync_master_tx_wait_time：master等待事務的總時間，單位微妙
Rpl_semi_sync_master_tx_waits：master等待事務的總次數
Rpl_semi_sync_master_wait_pos_backtraverse：發生master寫入的binlog的數量和slave響應返回的binlog數量不一致的次數。
Rpl_semi_sync_master_wait_sessions：當前等待slave響應的回話數量，該狀態可以反應當前主從延時包括壓力的情況
Rpl_semi_sync_master_yes_tx：master提交被slave成功響應的次數
Rpl_semi_sync_slave_status：僅噹噹前伺服器作為從庫，半同步複製是否開啟，on代表開啟。
注意：如果僅僅是作為slave那麼只有"rpl_semi_sync_slave_status"這1個狀態，其它的狀態是作為master端顯示的，由於我這裡是配置雙主模式，所有主從都存在。
注意：注意關注上面顏色加粗的這些狀態
三、測試
模擬從庫當機
stop slave;
在master執行插入操作
主庫上面等待響應的時間剛好是10S
從引數值也可以得到剛才有一次半同步複製失敗
當從庫重新啟動複製之後，半同步複製也同樣開啟，剛才的插入記錄也被非同步複製應用了過來。
注意：開啟半同步複製要加入到my.cnf檔案中才能保證重啟mysql服務後半同步複製也啟用
SET GLOBAL rpl_semi_sync_master_enabled = 1; SET GLOBAL rpl_semi_sync_slave_enabled = 1;
參考：
http://dev.mysql.com/doc/refman/5.6/en/replication-semisync-interface.html
前面寫的複製相關文章：
主從複製：http://www.cnblogs.com/chenmh/p/5089919.html
主主複製：http://www.cnblogs.com/chenmh/p/5153184.html
MMM:http://www.cnblogs.com/chenmh/p/5563778.html
總結
半同步複製雖然主從的binlog是同步的，但是主只是等待binlog寫入到從庫並不等待從庫應用這部分binlog,而從庫應用這部分binlog的操作則是非同步的，所以主從的資料並不是實時同步的，所以只能叫做半同步複製。在5.7版本之前作為主從的業務都會遇到主從延時比較大的情況，特別是當主是密集寫的情況這種延時就更加大，那是因為主是併發寫也從庫應用主的binlog是順序執行導致從跟不上主，在5.7引入了並行複製，所謂的並行也就是將不相關的操作放在一個組裡面這樣從庫就可以做到理論上的並行了從而提高主庫應用binlog的速率，並且在5.7的半同步複製引入了一個新的引數“rpl_semi_sync_master_wait_point=AFTER_SYNC”該引數是控制主庫響應從庫的binlog發生在flush disk之前，在5.6版本當主庫flush disk之後才傳送binlog如果這時主庫由於某種原因當機了，這時如果客戶端沒有收到從庫的響應那麼客戶端可能從新執行操作而這時主從已經做了切換客戶端連線主庫（之前是從庫）再次執行之前的操作，這樣當之前的主庫（現在變成從庫）啟動之後變成從庫後又重新應用了一次操作造成了資料寫了兩次，所以在5.7就把binlog的響應放在flush disk之前這樣就不會存在資料重複寫的情況了，預設該引數是開啟的所以搭建方法和5.6是完全一致的不需要做什麼改變。如果將該引數的值改成“rpl_semi_sync_master_wait_point=AFTER_COMMIT”則又變成5.6一樣的方案。在後面會單獨寫一篇關於5.7複製有關的新改進的文章，歡迎關注。
|
備註： 作者：pursuer.chen 部落格：http://www.cnblogs.com/chenmh 本站點所有隨筆都是原創，歡迎大家轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連結。 《歡迎交流討論》 |