線上redis遷移思路

[TOC]

線上redis遷移思路

背景

實際應用中，咱們的系統在上線後，總會遇到一些問題，須要對redis進行遷移，或者說切實例。可是因爲是線上系統，一個是要謹慎，一個是要保證服務可用，在不停服的狀況進行處理。

好比，咱們的redis實例的機器宕機、或者機器磁盤只讀、或者redis服務異常；或者須要rename一些高危命令；或者業務底層redis存儲機制更改。當咱們遇到諸如此類的場景，那麼就須要考慮切redis實例了,下面就一些經常使用場景來一一舉例說明

一個大的前提是，業務訪問資源，建議都是經過域名來訪問，而不是ip來訪問。

遷移方案

遷移從庫

背景

若是redis實例所在機器異常，須要遷移，而且這個redis實例，是業務的從庫，業務這邊作了讀寫分離，寫主庫、讀從庫的話，切從庫是最容易實現的，基本就是DBA切個DNS，當前，前提是業務訪問是經過域名訪問而不是直接經過ip訪問

具體方案

假如主庫是7526

1. 先從主庫上搭建新的從庫

2. 7526 掛載新的實例host 並下掉老的實例Host

3. 肯定老的從庫的鏈接數，要保證老的從庫沒有鏈接，

   • 能夠經過info查看client， 也能夠client list 查看
   • DBA 能夠經過監控查看， 也能夠經過登陸redis主機查看

4. 若是老的從庫沒有鏈接了，而且新的從庫有鏈接，就說明切從庫實例ok

通常，經過DNS來解析的話，業務若是採用鏈接池等方式，那可能遷移的過程，業務須要重啓，才能保證立刻斷開鏈接，實際中就發現雖然ping 從庫域名已是新的ip地址了，可是時間上，程序裏面鏈接的仍是老的ip，這個時候須要重啓一下服務

遷移主庫

背景

若是redis實例所在機器異常，或者其餘須要遷移，而且這個redis實例，是業務的主庫，那麼遷移主庫的流程，相對從庫的流程就稍微麻煩一點。

具體方案

前提以下：

m7614.xxx.redis.com 對應的IP是 192.168.xxx.93

s7614.xxx.redis.com 對應的ip是 192.168.xxx.94

思路：

提高從實例爲主實例，而後把主從域名都指向從實例去，而後再搭建新的從庫

遷移流程是：

1. 把192.168.xxx.94 slave_readonly 設置爲no，並設置 slaveof no one（配置文件刪slaveof 192.168.xxx.93 7614）
2. 而後要注意192.168.xxx.94要同步完原主庫的數據，等數據同步完後，再把m7614.xxx.redis.com 解析改到 192.168.xxx.94，而後業務肯定域名是否解析正常
3. 業務這邊若是有長鏈接進程的話重啓相關進程 ，重啓老的主庫實例進程（程序端），確保老庫沒有鏈接
4. 從新搭建從實例。
5. 新從庫建好後，再從新搞一下從庫的域名並掛載到新從庫上

雙寫+遷移

背景

在某些場景下，若是直接切主庫、切從庫都不合適，可能會致使數據不一致或者數據丟失；或者須要停服或者短暫停寫的狀況下，咱們就要考慮雙寫+遷移策略，雙寫+遷移策略是萬能的，不只僅針對redis，其餘資源如mysql等也是好使的。

這個方案稍微繁瑣一點，可是有個好處就是必定保證不停服，不影響用戶，而且可以回滾，保證數據一致性。缺點就是須要業務方在修改代碼，而且再代碼裏面增長開關配置，好的作法是經過配置文件就可以打開雙寫、讀寫新庫等

具體方案

1. 業務方修改代碼，增長雙寫配置開關，而後更新上線
2. 再在代碼裏面開啓雙寫，也就是新庫老庫都寫
3. 後臺進程或者腳本進行數據同步，把老庫的數據同步到新庫中，並要作check，確保數據必定是一致的
4. 同步完成後，經過代碼配置文件來控制中止雙寫，讀寫新庫。
5. 確保讀寫新庫ok後，再清掉老庫的某個遷移出去的db。

這個方案的兩個關鍵點在於：

1. 代碼裏面增長的雙寫開關配置，要作到抽象，確保經過配置，就能打開雙寫配置、中止雙寫、讀寫新庫
2. 後臺腳本校驗程序要作好，確保數據的一致性

總結

以上幾種狀況都是xxx項目在這一年多來遇到的，而且都是和運維、DBA一塊兒作過遷移，算是一點點小經驗。 另一點就是開發人員要可以分析排查問題，遇到線上問題後，要可以經過各類手段定位到緣由，再給出合適的解決方案

【"歡迎關注個人微信公衆號：Linux 服務端系統研發，後面會大力經過微信公衆號發送優質文章"】