MySQL5.7中多源復制及Nginx中間件是怎么樣的

本篇文章給大家分享的是有關MySQL5.7中多源復制及Nginx中間件是怎么樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

之前有寫了一點驗證多源復制的東西，下半篇寫點Nginx的東西；
背景：趕
環(huán)境：MySQL-5.7.9 x 4，Nging-1.9.7 x 1，五臺虛擬機
總體思路：
四個MySQL實例組成雙主雙從的多源復制結構，Nginx放在前端，對應用層屏蔽DB層細節(jié)，同時由Nginx來完成負載均衡/讀寫分離和“偽HA”


使用的Nginx配置


簡單試一下功能，連接的時候指定host，使用TCP的方式去連接61上面的Nginx，可以看到成功的登錄了MySQL，

在兩臺主庫上面找一找，發(fā)現(xiàn)這個鏈接發(fā)送到了67上面

既然連進來了，通過一個純粹做請求轉發(fā)的Nginx之后， 普通的操作應該是沒什么問題，試驗略過；
連接write的upstream和連接read的upstream沒什么本質上的區(qū)別，試驗略過；
通過Nginx做中間件來實現(xiàn)讀寫分離的話，只需要在URL中連接不同的端口就可以了,試驗略過；
多個連接同時連到這個Nginx的寫庫(主庫)，可以看到連接被分到了不同的服務器上，


提問：如果有session連接在某一臺主庫上，然后那臺主庫出問題掛掉了，客戶端的狀態(tài)？
解惑：kill主庫的mysql進程，模擬down機；

有兩個客戶端出現(xiàn)了重連的提示，另外兩個一切正常；


存活的主庫狀態(tài)，可以看到請求都轉到了存活的主庫上；

結論：對客戶端來說，雖然保持連接的那個主庫掛掉了，但是在前端來看，就像是連接超時被斷開了一樣，并不會感受到端口為13579的主庫已經掛掉了；
讀庫同理，驗證略過；

額外發(fā)現(xiàn)的斷開連接現(xiàn)象：在Nginx設置的timeout也會有一定的影響，接上圖的狀態(tài)，一直不去操作這幾個客戶端，在超時時間之后，會在MySQL端輸出如下錯誤日志；

重新操作一下幾個客戶端，會看到所有的連接其實都斷開了；


解惑：連接建立以后，空閑的時間超過Nginx（proxy_timeout）和MySQL的設置中比較短的那個之后，就會自行斷開；
結論：和Nginx+Tomcat的反向代理一樣，超時時間的設置也要注意一下；

提問：某一個庫（以上面掛掉的那個主庫為例）掛掉之后，fail_timeout的時間之后，這個主庫恢復了，會不會自動加回列表？
解惑：為了方便測試，改一下fail_timeout的時間，然后關掉主庫67，重啟Nginx以后，再啟動67，等待一段時間，


間隔的時間稍微久了點， 不過重新開啟連接以后，可以看到有連接重新進來了，fail_timeout的設置還是ok的，在超過這個時間段以后，Nginx會去檢測后端服務器的狀況，把啟動起來的服務器重新加進來；
結論：Nginx作為一個中間件，可以做到“自動移除掛掉的機器/自動加回恢復的機器”；
PS：如果是啟動了，正在恢復數(shù)據(jù)的話，最好還是把出問題的庫從upstream移除比較好；

提問：在upstream的配置中，寫的是通過hash的方式去轉發(fā)連接，那么是否可以像Nginx+Tomcat的反向代理一樣，采用權重等其他的方式來轉發(fā)連接？
解惑：試一下；為了方便看效果，簡單改一下Nginx的配置

連接四個客戶端以后，看看兩個主庫的連接；

可以看到連接都轉發(fā)到了65主庫上面去了；
結論：權重的配置是可以生效的，這樣的話，可以根據(jù)實際要求，用不同配置的MySQL實例來搭建這種類似的架構；

提問：既然使用Nginx作為中間件，可以做到“自動移除掛掉的機器/自動加回恢復的機器”，也對前端屏蔽了后端DB架構上的細節(jié)，不會發(fā)現(xiàn)某個DB不可用，為什么要描述成“偽HA”？
解惑：個人觀點，確實，通過Nginx的中間件，去訪問后端的MySQL，確實是具備了HA的樣子；某個MySQL實例掛掉了，不會導致整個DB系統(tǒng)無法運行；失敗的MySQL實例恢復以后能自動加入；
但是用Nginx做中間件有兩個很明顯的短板：Nginx的端口是作為對外的唯一出口暴露給應用層的， Nginx本身的HA需要其他方式去保障（不像VIP，就算admin或者worker掛掉了，也不影響數(shù)據(jù)庫訪問）；
另一個更重要的缺點，就是兩個主庫全部掛了以后，Nginx本身不能新選舉一個從庫作為新的master來重新搭建新的主從架構；
這兩個短板，尤其是第二個短板，如果是很嚴格的HA環(huán)境和要求，這第二個短板是非常致命的，想要彌補這個，自行開發(fā)一套/修改開源工具也許能做到；

追問：存在這么明顯/嚴重的短板，多源復制+Nginx的中間件，到底好用么？
解惑：個人觀點，還不錯；
1.Nginx的單出口問題，完全可以通過啟動多個實例（分開的）指向同一套后端數(shù)據(jù)庫來提高可用性（keepalived也可以）
2.不能選舉新Master的問題，在5.7的多源復制功能中，可以橫向增加Master的數(shù)量，完全靠更多的實例來提高可用性，
這么做，可能會使N主之間的數(shù)據(jù)一致性受到影響，不過只需要在讀庫的upstream里面剔除掉這些主庫就行了；
3.完全用提高實例數(shù)的方式去提高可用性，個別的實例（不管主或者從）掛掉了，基本上不會影響到業(yè)務，所表現(xiàn)出來的，只是“某些事務異常中斷了”，需要應用層重試，
而不是mha那樣，主庫掛了需要一段時間來重建主從結構；

以上就是MySQL5.7中多源復制及Nginx中間件是怎么樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。