keys命令導致叢集崩潰

總是原理上知道keys命令很危險,線上禁用,會導致各種問題,終於見到真身了

一、redis-migrate-tool遷移失敗，fork:cannot allocate memory導致

前一天晚上,我用redis-migrate-tool工具遷移哨兵資料到叢集,也遇到問題

工具裡邊一直提示我Partial resynchronization for MASTER [] not possible(no cached master).我開始還理解這是在部分同步?為啥進行部分同步,英語沒學好,看到源redis的日誌之後我才理解了,tool工具裡邊說的是沒有快取的主節點資料.

下邊是源redis中報出來的異常，cannot save in background:fork:cannot allocate memory

我以為就是記憶體不足，檢視一下記憶體還有9個g，完全是夠用的

於是乎更改一下核心引數，有以下三種方式更改

1.編輯/etc/sysctl.conf ，改vm.overcommit_memory=1，然後sysctl -p 使配置檔案生效
2.sysctl vm.overcommit_memory=1
3.echo 1 > /proc/sys/vm/overcommit_memory

推薦2和3的方式更改，這樣只更改一個overcommit_memory這一個引數值，如果使用第一種方式，不能確定檔案裡邊的內容是否本來就生效的，這樣可能更改更多的核心引數，所以不建議
 

修改之後重新同步，問題解決.

二、keys導致redis叢集崩潰

遷移發生在前一天晚上，第二天上午就在我出去的半個小時裡，監控報警了，失聯了一對主從節點,叢集狀態fail

就如上圖所示,每條keys命令執行需要1s,一共執行了30分鐘差不多,阻塞產生的結果是什麼呢?

redis叢集間的通訊是通過ping-pong來檢視節點是否存活的,如果15s之內發出的ping都沒有反饋,這個節點就被定義為失聯,這時會發生主從替換,替換之後,從節點也面臨相同的問題,keys阻塞節點,這時候從節點也會失聯,同一對主從失聯的結果就是叢集fail,直到keys命令執行完成,redis叢集才恢復正常,這是一次血的教訓,從這一天開始我們生產就開始嚴格的規範禁止使用keys *,flushdb,flushall等命令了