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

成都創(chuàng)新互聯(lián)公司長期為近千家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為鞏留企業(yè)提供專業(yè)的網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作，鞏留網(wǎng)站改版等技術(shù)服務(wù)。擁有10多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

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


使用的Nginx配置


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

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

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


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

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


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

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

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

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


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

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


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

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

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

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

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

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

以上就是MySQL5.7中多源復(fù)制及Nginx中間件是怎么樣的，小編相信有部分知識點(diǎn)可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。

文章題目：MySQL5.7中多源復(fù)制及Nginx中間件是怎么樣的-創(chuàng)新互聯(lián)
URL標(biāo)題：http://jinyejixie.com/article38/cshhpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、域名注冊、面包屑導(dǎo)航、自適應(yīng)網(wǎng)站、品牌網(wǎng)站設(shè)計(jì)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)