問題

我們經常使用浮動 IP(SIP，或叫 VIP)，來完成數據庫的高可用部署。

業務通過訪問浮動 IP，始終訪問主數據庫。如果業務正在訪問數據庫時，數據庫主從發生切換，導致 SIP 漂移，那正在使用的數據庫連接會受到影響么?

實驗

我們創建同子網的兩臺虛擬機，分別安裝 MySQL。再準備一臺額外的虛擬機，用來模擬業務，訪問數據庫，此處省略安裝過程。這兩臺虛擬機的 IP 分別是 x.x.x.37 和 x.x.x.39，為了容易區分，我們設置 PS1，來區分兩個 linux 的會話。下圖以 37 為例，這里設置了 PS1，并確認機器上有創建好數據庫，

39 與之類似：

我們再選取一個 SIP: x.x.x.200，將其綁定到 37 上，

向子網進行 arp 宣告，通知大家 ip 變更了：

現在業務機器上，測試一下訪問 SIP 成功：

我們在數據庫中用 sysbench 灌入數據，此處省略步驟，只看結果：

然后向數據庫執行一個 select，這里我們用了一個 sleep，使得數據庫返回結果集慢一些，大概每秒輸出 1000 行左右：

執行 SQL 后，MySQL 客戶端會不停輸出結果，如果發生了任何連接問題，我們可以立刻發現。現在讓 SIP 發生一次切換。準備好如下命令：先在 37 上卸下 SIP，再在 39 上加上 SIP，發送 arp 宣告。

準備好命令后，開始拼手速，讓命令以很短的時間先后執行。執行后，會發現業務機上跑的 select 輸出停了，會停很久以后，

我們來看看這個現象的原理：在 37 上，我們可以找到這根連接：

幾十秒后，進入 FIN-WAIT-1 階段，也就是說 37 已經感知到這根連接不太對，再 48 秒后，會關閉這根連接：

而此時在業務機器上，這根連接依然存在，會在 116 分鐘以后，探測 tcp keepalive 失敗后，才感知到連接出問題：

我們試著將業務機的 tcp keepalive 間隔調小一點，看看能不能讓業務機更快感知到連接出了問題：

再重做一下實驗，會發現幾秒鐘后，MySQL client 就會感知到連接出了問題：

我們來抓個包看看：

重做試驗，用 Wireshark 打開抓包結果：

可以看到 SIP 切換后，TCP Keepalive 包發往了交換機，但沒有收到應答包。當超過 TCP Keepalive 的指定次數后，應用機器感知到了連接錯誤，發起了 RST 斷開連接。也就是說：當 SIP 發生切換時，舊連接發出的包已經被丟棄了，舊連接會一直等待應答，所以需要 TCP keepalive 這種主動探測機制，才會探測到無應答的狀況。

小貼士

當應用連接到數據庫時，建議要配置 TCP keepalive 功能，并且間隔要調小到業務能接受的范圍內。默認的 TCP keepalive 的間隔是幾小時才能感知故障。

但是：不要模仿實驗中這樣，調整操作系統級別的 TCP Keepalive 參數。應在應用建立連接時將 TCP keepalive 參數配置在連接級別。

關于 MySQL 的技術內容，你們還有什么想知道的嗎？趕緊留言告訴小編吧！

總結

以上是生活随笔為你收集整理的mysql数据漂移_第28问：SIP 漂移时，会影响正在使用的数据库连接么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。