背景
系統中Redis使用三臺服務器（slave01,slave02,slave03），交叉搭建了三主三從集羣。一段時間內，Redis集羣頻繁出現CLUSTERDOWN異常，使用redis-cli客戶端連上集羣后，使用cluster info查看集羣信息，發現 cluster_state狀態爲fail，排查發現slave02服務器負載超高，redis服務已經連不上了。但奇怪的是該服務器上只有一個master，理論上“宕機”後，該服務器上的master(slave02:7003)的從節點（slave01:7002）應該自動failover選舉成master纔對，但是集羣的自動切換機制並沒有生效，整個集羣處於CLUSTERDOWN狀態，不可對外提供服務，一直等到slave02這臺服務器負載恢復正常後cluster_state才恢復爲ok狀態。
踩坑過程
-
沒有開啓日誌的痛
沒有日誌啊沒有日誌啊，忍不住嚎啕一嗓子，發生故障只能靠猜啊，搞半天摸不着頭腦啊。後來逼於無奈，還是關閉了故障節點的Redis，添加了日誌配置再重啓，也幫助了後續問題的排查； -
redis-server啓動路徑之坑
由於集羣的配置文件***.conf中，沒有指定aof文件名和路徑，因此redis默認使用appendonly.aof作爲AOF文件名，且，文件位於啓動命令執行的目錄，也就是說，你在哪裏執行redis-server啓動redis，這個AOF文件就從哪裏加載，找不到的話就自動生成一個新的。而由於之前狂野粗放的操作，不同節點上的啓動路徑並不一致，而我們也沒注意到這個問題，重啓Redis的時候用了一個與之前不同的路徑，導致Redis重啓後加載不了持久化的數據…我們也是在鏈接redis後發現keys沒了才注意到這個問題； -
cluster-config-file配置文件之坑
跟上面的問題有點類似，在配置cluster-config-file的時候，沒有指定路徑，因此，redis默認在啓動命令執行的目錄去找集羣節點信息的配置文件，如果找不到，它就自己創建一個新的。聽起來好像沒問題，但是這樣創建的Redis節點，它雖然是集羣模式，卻因爲配置文件丟失沒有加入之前的集羣，這時候它自己本身成了一個獨立的集羣。如果你企圖用redis-trib將它加入原本的集羣，那麼它還是一個孤零零的master（而其實我們期待它恢復成某個master節點的slave），如果當做master用，還得給它分配槽；如果你企圖將它手動指定爲某個master的slave，它還可能傲嬌地給你說：不行，i’m not empty，你只能逼於無奈將它的數據清空再來一次；
所以，2跟3要合起來一起看，當你重啓Redis時，一定要注意redis-server這個命令的執行位置，是否跟重啓前一致，也千萬別刪掉原來的node***.conf文件，它保存了你原始的集羣節點信息（登錄後執行cluster nodes命令可以看到一樣的信息），只有使用這個文件啓動，重啓的節點才能正確地加入之前的集羣。 -
masterauth之坑
在解決問題3之後，我們發現一個奇葩的事，明明集羣已經恢復了啊，爲什麼master節點的數據沒有同步到slave節點!!! 同時，我們嘗試着手動kill掉master節點，爲什麼slave節點沒有自動選舉成master!!! 好在這一次我們開啓了日誌，直接查看slave節點的日誌，發現一直在打印一個錯誤“Unexpected reply to PSYNC from master: -NOAUTH Authentication required.”這時才恍然大悟，我特麼配置了requirepass要求別的節點連我要密碼，但是我沒有配置masterauth啊， slave節點去同步master數據時，因爲沒有配置這個參數，導致一直同步失敗，這也就是前面發生的幾個現象-爲什麼明明集羣狀態是ok了但是數據沒有從master同步過來，爲什麼master掛了slave不能自己選舉成爲master-的原因。配置了masterauth後，再重啓slave節點，一切如絲般潤滑：正確的同步數據，生成AOF文件，keys也有了，關閉master後它也能切換成新的master了…這裏有個意外收穫：原來，雖然配置的是AOF機制，但redis slave從master同步數據的時候，還是會先生成rdb文件，然後再生成AOF文件，然後再使用aof-rewrite機制，重寫AOF文件。
回顧整個踩坑過程：
- 第一是沒有開啓redis日誌，導致集羣其實沒有配置成功但是沒人知道，後續發生故障後也只能靠猜測排查問題；
- 第二是集羣異常時，沒人想到是不是集羣沒有配置正確，都默認以集羣正確配置爲前提來排查；
- 第三是沒想到啓動位置會影響redis aof文件以及集羣配置文件生成的路徑；
- 第四是沒注意到只配置了自己的服務端密碼（requirepass）沒有配置對應另一個節點的客戶端密碼（masterauth）…
這幾個小問題湊一起之後，就把人弄得暈頭轉向一頭霧水，折騰了很久才搞清楚“莫名其妙的現象”背後的原因。
以此爲戒，吸取教訓，第一是，以後使用應用時，一定要開啓日誌，方便排查問題，第二個教訓就是還是得了解你使用的應用的原理和主要配置項，儘量避免發生故障後臨時抱佛腳。