MYSQL M-S主從架構

MYSQL M-S主從架構（半同步複製）

上一篇文章我們講到MYSQL M-S的非同步複製架構，今天我們來講講MYSQL M-S的半同步複製。

mysql M-S複製分為非同步複製，半同步複製，全同步複製

非同步複製：

非同步複製就是默認的複製方法，master端將事件的處理寫到了binlog日誌，slave端 start slave 的時候會開啟兩個線程（IO thread,SQL thread）,master的io thread 將binlog信息推送到slave端，slave 的io thread將其寫入到relay log當中，再通過sql thread讀取同步relay log的信息。主庫在執行完事務之後會，並沒有關心從庫是否將數據應用到數據，這種情況會導致如果主crash掉

了，這個時候可能master的數據沒有被slave應用，如果將slave強行提升為主，那麼可能導致數據丟失的情況。

全同步複製：

當master完成一個事務，會確認slave是否將事務也同步執行，性能自然而然也會下降。

半同步複製：

半同步複製出現在mysql5.5之後，當master執行一個事務，等待至少一個從庫接收到並且寫到relay log中才能反饋給客戶端程序，半同步複製提高了性能和安全性，但是有少量的延遲。

半同步複製原理圖：

圖畫的有些拙劣，湊乎的看吧。。。總之，就是在連接master的客戶端那邊，只有在slave 端進將數據同步寫入到relay log當中返回給master一個信號後，master才會顯示到客戶端。

缺點：

半同步複製有可能會有以下的一些缺點

1，如果事務沒有發送到slave 上，master在此時crash掉，客戶端會發生SQL commit失敗的回饋，此時，配置了keepalive的時候，slave會升到master，前master會成為slave，客戶端會連接到前slave(現master)這邊，這個時候，這個現slave端數據有可能會被提交兩次！！！！！！

2，如果事務發送到了slave上，master此時crash，客戶端返回commit失敗，slave提升到master，客戶端連接到前slave(現master），還會再次commit，這樣就會將數據重新提交一次，會導致現master發生重複。

3，如果沒有配置高可用的話。當master的事務沒有傳到slave端，master crash 的話就會導致資料庫數據丟失。

在mysql 5.7的時候增加了一個參數（-rpl_semi_sync_master_wait_point）可以讓數據不丟失，叫做loss-less半同步，這個我之後再說。

實驗：

master：

首先想要實現半同步複製的話，需要有semisync_master.so和semisync_slave.so模塊。我們查看當前master資料庫的安裝插件。

這裡顯示了資料庫當中所有的插件信息，但是資料庫並沒有我么所需要的semi包。這個包是內嵌在mysql當中的，我們將其安裝到資料庫當中。

install plugin rpl_Semi_sync_master soname "semisync_master.so";（補充一下想要刪除插件uninstall plugin pluginname）

安裝過後我們查看資料庫的參數

這裡多了如下幾行參數。

rpl_semi_sync_master_enabled 控制是否開啟資料庫非同步同步。

rpl_semi_sync_master_timeout 控制當超過這個時間後將會轉變為非同步複製，默認時間為10000ms，單位是ms。

rpl_semi_sync_master_trace_leve 這個level值可以控制列印出半同步複製的日誌。

開啟半同步複製開關

set global rpl_semi_sync_master_enabled=on ;

slave：

安裝slave所需要的半同步複製包

install plugin rpl_semi_sync_slave soname "semisync_slave.so";

開啟半同步複製：

這個時候slave端的半同步複製狀態並沒有開啟，我們查看一下slave端的狀態：

我們看到狀態是off的，我們查看一下master的狀態：

我們發現master的rpl_semi_sync_master_status 的狀態已經是on，所以現在解決slave端的半同步複製為off的情況，這個時候需要我們重啟slave端資料庫。這裡注意如果重啟數據後不行的話，那麼將rpl_semi_sync_slave_enabled這個參數放到配置文件當中，重啟後即可。

我們發現slave的半同步複製的status是on的狀態，現在查看master 的status。我們發現Rpl_semi_sync_master_clients的value變成了1，這就表示我們連接的半同步伺服器有1個，也就證明我們的半同步已經成功了。

接下來我們進行測試，查看下數據是否同步。

MASTER：

SLAVE：

我們在這裡驗證一下，是不是半同步複製，我們查看一下slave端的狀態，並且關閉slave端的io thread 。

stop slave io_thread

我們關閉了M-S的slave端的iothread ，這個時候我們從master端insert一條數據，查看下狀態

我們發現這個時候出現了延遲，這裡會卡10s左右，我們再去slave端查看數據，我們發現這個值也並沒有過來，為什麼會這樣呢？

這是因為我們之前說的半同步複製存在一個參數rpl_semi_sync_master_timeout，如果延遲大於這個參數的限定值的話（默認10000ms=10s），那麼就會轉變成非同步複製，然而，轉變成非同步同步的同時，io thread無法捕獲master dumping thread 的信息，所以無法將其同步。

也就證明，我們當前的狀態是半同步複製M-S。

說到這裡，再多說一句，如果將slave的sql thread 關閉的話會有什麼現象？

我們用實驗證明一下：

slave：

stop slave sql_thread;

我們在master端insert 一條數據，這裡並沒有延遲的發生。

並且在slave端我們查看資料庫數據，發現沒有同步過來。

這也就證明了我們之前說的，半同步複製是等待slave 的io thread 寫入到binary log即返回給master證明收到日誌，master再展示給client ，所以我們這裡也就證明，如果SQL thread出問題，很有可能slave並沒有應用到資料庫中，只是記錄到binary。當sql thread狀態為on的時候，會從binary 日誌當中去應用到庫里。

THAT"S ALL

BY CUI PEACE ~~~

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！