redis cluster 故障後,主從位於相同節點的修復(丟失了部分資料)
今天機房出現故障,有一個機器啟動不起來,redis cluster叢集丟失了一部分資料,拓撲圖如下:
透過上圖可以看到,192.168.1.122啟動不起來後,其上的主1和從1因為在一個機器上,就全部丟失了。
這個佈局非常危險,主和從不應該放在一個機器上。
我找運維,運維給我分配了一個全新的機器,並且繫結的ip還是原來的192.168.1.122。
在192.168.1.122上,安裝了兩個全新的,空的redis:
/usr/local/redis/bin/redis-server /opt/cachecloud/conf/redis-cluster-6385.conf & /usr/local/redis/bin/redis-server /opt/cachecloud/conf/redis-cluster-6386.conf &
由於詳細的恢復步驟,沒記錄,我現在憑著記憶,把關鍵步驟寫在這:
1、現在 192.168.1.122:6385和 192.168.1.122:6386是兩個獨立的節點,和原來的叢集沒有任何聯絡,現在隨便個叢集節點,登入入叢集,加入叢集:
redis> cluster meet 192.168.1.122 6385 redis> cluster meet 192.168.1.122 6386
2、檢視叢集
redis> cluster nodes 861950ffe756a17831a396592e71c98b4cca7fe5 192.168.1.122:6385 master connected f66b03da36fda230cb5933fb27039935fd525ceb 192.168.1.122:6386 master connected e3e9351854cb1bf30de2b612ede9c93d92c40a09 192.168.1.71:6386 master - 0 1670082221324 48 connected 10924-16383 d946f65359df4c538e95eb1449793b60fed64156 192.168.1.71:6385 slave e3e9351854cb1bf30de2b612ede9c93d92c40a09 0 1670082222327 48 connected 43d45869a4fdc32aad3c13dcce8d5d36e09dcaea 192.168.1.123:6385 slave fbe4515a4f99b933302aa593c51fc7a45d44936a 0 1670082220322 50 connected fbe4515a4f99b933302aa593c51fc7a45d44936a 192.168.1.123:6386 master - 0 1670082223329 50 connected 5462-10923 111111111111111111111111111111111111111 fail master 0-5461 disconnect 222222222222222222222222222222222222222 fail slave disconnect
3、透過disconnect可以看出,0-5461之間的slot槽位丟失了,現在我們把0-5461號slot,繫結到新節點192.168.1.122:6385上
redis> CLUSTER SETSLOT 0 node 861950ffe756a17831a396592e71c98b4cca7fe5 redis> CLUSTER SETSLOT 1 node 861950ffe756a17831a396592e71c98b4cca7fe5 redis> CLUSTER SETSLOT 2 node 861950ffe756a17831a396592e71c98b4cca7fe5 ...... redis> CLUSTER SETSLOT 5461 node 861950ffe756a17831a396592e71c98b4cca7fe5 後面的861950ffe756a17831a396592e71c98b4cca7fe5就是192.168.1.122:6385的id,透過cluster nodes可以看到。 上面的命令在叢集中的所有主節點上,都要執行一遍。
4、因為一次只能setslot一個,所以,我寫了個指令碼,需要在所有叢集主節點上執行一遍:
[root@localhost ~]# cat a.sh for i in {1..5461} do /usr/local/bin/redis-cli -h 192.168.1.122 -p 6385 -a admin -c CLUSTER SETSLOT $i node 861950ffe756a17831a396592e71c98b4cca7fe5 done
[root@localhost ~]# cat a.sh for i in {1..5461} do /usr/local/bin/redis-cli -h 192.168.1.71 -p 6386 -a admin -c CLUSTER SETSLOT $i node 861950ffe756a17831a396592e71c98b4cca7fe5 done
[root@localhost ~]# cat a.sh for i in {1..5461} do /usr/local/bin/redis-cli -h 192.168.1.123 -p 6386 -a admin -c CLUSTER SETSLOT $i node 861950ffe756a17831a396592e71c98b4cca7fe5 done
5、這樣,192.168.1.122:6385就成為叢集的真正主節點,並且管理著0-5451號slot槽。
6、然後,將新裝的、空的 192.168.1.122:6386作為 192.168.1.122:6386的從節點:
登入到192.168.1.122:6386 192.168.1.122:6386> cluster replicate 861950ffe756a17831a396592e71c98b4cca7fe5 後面的861950ffe756a17831a396592e71c98b4cca7fe5 id就是主節點id
7、看到192.168.1.122:6385和192.168.1.122:6386成功加入叢集了,但是原來的資料沒有了,圖中的11109只是剛剛寫入的資料:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28916011/viewspace-2926614/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- redis cluster 故障後,主從位於不同節點的修復。Redis
- Oracle impdp遷移資料後主鍵丟失故障處理Oracle
- redis cluster 強制kill某一個節點和shutdown某一個節點後修復過程Redis
- chkdsk 後資料丟失的恢復方法
- 基於linux系統,fsck後資料丟失的資料恢復方案Linux資料恢復
- 關於操作失誤的資料修復
- 伺服器資料丟失了怎麼恢復/分割槽丟失恢復教程伺服器
- /etc/fstab檔案丟失後--修復系統
- 伺服器不能啟動,修復後部分檔案丟失怎麼解決伺服器
- redis-cluster主從搭建Redis
- 用 docker 學習 redis 主從複製3.3 redis-sentinel「哨兵模式」 資料丟失的情況DockerRedis模式
- RMAN_部分資料檔案丟失或者損壞的恢復
- 控制檔案部分丟失的恢復
- DATA GUARD主庫丟失資料檔案的恢復(2)
- DATA GUARD主庫丟失資料檔案的恢復(3)
- DATA GUARD主庫丟失資料檔案的恢復(1)
- 【故障處理】DG環境主庫丟失歸檔情況下資料檔案的恢復
- redis cluster 叢集故障恢復操作思路Redis
- 【kingsql分享】RAC節點故障修復一例SQL
- 資料檔案丟失的恢復
- oracle歸檔日誌丟失後的資料庫恢復Oracle資料庫
- Google Drive存在未知故障,導致部分使用者丟失雲盤資料Go
- 差點丟失資料的RMAN 恢復,最後用隱藏引數開啟
- 硬碟資料丟失如何恢復?硬碟
- 分割槽丟失資料恢復資料恢復
- redis cluster節點/新增刪除操作Redis
- MySQL主從修復MySql
- Redis Cluster 獲取主從關係Redis
- 電腦硬碟資料丟失後怎麼恢復?硬碟資料恢復技巧教程硬碟資料恢復
- ASM磁碟組丟失member kfed修復ASM
- [天羽]差點丟失資料的一次RMAN恢復
- 09.redis 哨兵主備切換時資料丟失的解決方案Redis
- 故障分析 | redis cluster 從庫無法自動恢復同步案例一則Redis
- RMAN_資料庫的絕大部分資料檔案丟失或者損壞的恢復資料庫
- 資料檔案丟失如何恢復
- 無備份丟失部分資料檔案和控制檔案恢復 [轉]
- RMAN完全恢復丟失的資料檔案
- 普通資料檔案丟失的恢復方法