共計 2285 個字符，預計需要花費 6 分鐘才能閱讀完成。

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

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

使用的 Nginx 配置

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

在兩臺主庫上面找一找，發現這個鏈接發送到了 67 上面

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

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

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

存活的主庫狀態，可以看到請求都轉到了存活的主庫上；

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

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

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

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

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


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

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

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

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

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

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

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