Redis集羣使用總結（二）：
本篇文章需要結合上一篇《redis集羣使用總結（一）》，而這裏主要介紹Redis集羣的管理的分析和研究總結。
· 如何管理
· 故障轉移
· 注意事項
一、如何管理
Redis集羣的管理涉及的主要就是針對集羣中的主次節點進行新增、刪除以及對節點重新分片操作，而這些操作我們就可以使用redis-trib.rb工具來實現，具體如下：
1、新增Master節點
Redis集羣中新增節點需要新創建一個空節點，然後將該空節點加入到集羣中，最後爲這個新的空節點分配slot哈希槽值即可，具體如下：
A、新建空節點
首先，新建一個redis-6382.conf配置文件：
文件內容與其它節點內容類似，不同的是端口，日誌目錄以及數據庫文件的路徑；
其次，啓動這個新節點：
$redis-server /redis/etc/redis-6382.conf
B、加入空節點到集羣
$redis-trib.rb add-node 127.0.0.1:6382 127.0.0.1:6379
NOTE：
127.0.0.1:6379爲集羣中的任意節點；
127.0.0.1:6382爲集羣新增的空節點；
執行完成之後，結果顯示如下：
可以使用redis-trib.rb驗證新增節點的類型是否爲主節點：
$redis-trib.rb check 127.0.0.1:6382
結果顯示如下：
C、爲空節點分配slot
$redis-trib.rb reshard 127.0.0.1:6382
執行結果顯示，並按提示輸入：
// 提示要遷移的slots的數量，這裏輸入500
How many slots do you want to move (from 1 to 16384)? 500
// 提示指定爲哪個node-id分配slot，這裏輸入新增的node
What is the receiving node ID? e7fcec2bdbd19c5244502276059a53878b9093af
// 選擇指定slot的來源
// all->代表從所有的master中重新分配
// done-> 數據要提取slot的master節點id，最後用done結束
Please enter all the source node IDs.
Type ‘all’ to use all the nodes assource nodes for the hash slots.
Type ‘done’ once you entered allthe source nodes IDs.
// 這裏我們選擇all即可
Source node #1:all
// 輸入yes之後，開始進行slots的分配和數據的移動
Do you want to proceed with the proposed reshard plan (yes/no)? yes
執行結果顯示：
從上圖可以知道，新的主節點已經添加並分配好slots，slots值的範圍爲500.
D、驗證使用該節點
從上圖知道，新節點已經添加並配置成功，並且使用正常無問題。
2、新增Slave節點
新增Slave節點與新增Master的前三步驟相同，這裏不再介紹，不同的是需要登錄到從節點的redis-cli，使用replicate爲該節點指定主節點，具體如下：
127.0.0.1:7382>cluster replicatee7fcec2bdbd19c5244502276059a53878b9093af
結果顯示：
(error) ERR To set a master the node must be empty and without assignedslots.
NOTE：
上面的錯誤意思是不能爲一個非空並且分配了slot的主節點繼續添加從節點。
由於上面的問題，我們現在將6382主節點置空並且清除爲其指定的slots，具體如下：
A、先刪除主節點的slots
$redis-trib.rb reshrd 127.0.0.1:6382
// 刪除指定的500的slots
How many slots do you want to move (from 1 to 16384)? 500
// 選擇將當前的slots要轉移到的node-id（非當前的節點id）
What is the receiving node ID? ae4c4e5faf5fb679f697d07b7afe1cfb55991113
// 指定slots的來源爲當前的node-id
Source node #1:e7fcec2bdbd19c5244502276059a53878b9093af
Source node #2:done
// 開始轉移同步
Do you want to proceed with the proposed reshard plan (yes/no)? yes
B、再刪除從節點的slots
該步驟的實現與A中的步驟完全相同，請自行實現。
C、指定從節點
127.0.0.1:7382>cluster replicatee7fcec2bdbd19c5244502276059a53878b9093af
執行結果：
從上圖已經知道，從節點已經綁定成功了。
D、查看下主從節點關係
$redis-trib.rb check 127.0.0.1:6380
執行結果：
從上圖我們看出，主節點6382爲空，從節點7382也爲空，並且主從節點的關係也已經正常，接下來就是使用reshard如同上面的操作相同，這裏不介紹說明。
3、刪除Slave節點
$redis-trib.rb del-node 127.0.0.1:7382
8d8589fd7e9d140442e06b06e9e810d5d0f5e257
執行結果：
4、刪除Master節點
A、轉移主節點slots
這裏的操作與上面的操作相同，這裏不贅述。
B、刪除主節點
$redis-trib.rb del-node 127.0.0.1:6382
8d8589fd7e9d140442e06b06e9e810d5d0f5e257
執行結果：
二、故障轉移
Redis集羣支持一旦某個主節點故障之後，集羣如何保持正常工作，目前其包含兩種故障轉移類型：自動轉移和手動轉移。對於前者，不需要使用者做任何工作，全部交由Redis集羣內部維護，但這種方式會存在很小概率丟失keys的機率；相對於前者，手動轉移可以解決前者數據丟失的問題，具體如下：
A、自動轉移
要觸發一次故障自動轉移，最簡單的辦法就是令集羣中的某個主節點進入下線狀態，具體可以如下面操作：
首先，查看下當前集羣的主節點：
$redis-cli -p 6379 cluster nodes | grep master
執行結果：
上圖展示了目前集羣共有6379,6380,6381三個主節點。
其次，向主節點6381發送debug segfault,讓其下線：
$redis-cli -p 6381 debug segfault
執行結果：
Error: Server closed the connection
此時，主節點6381已經斷開連接，已經下線了。
最後，查看下主從節點：
$redis-cli -p 6379 cluster nodes | grep master
執行結果：
由上圖可以知道，當主節點6381下限故障之後，其擁有的從節點7381上升爲主節點，而6381節點的類型不變，只是處於下限不能工作，這就是Redis集羣中節點的主從故障自動轉移了。
B、手動轉移
有的時候在主節點沒有任何問題的情況下，強制手動故障轉移也是很有必要的，比如想要升級主節點的Redis進程，我們可以通過故障轉移將其轉爲slave，再進行升級操作來避免對集羣的可用性造成很大的影響。
Redis集羣使用 CLUSTERFAILOVER命令來進行故障轉移，不過要被轉移的主節點的從節點上執行該命令，手動故障轉移比主節點失敗自動故障轉移更加安全，因爲手動故障轉移時，客戶端的切換是在確保新的主節點完全複製了失敗的舊的主節點數據的前提下下發生的，所以避免了數據的丟失。
具體操作在後續文章中繼續介紹，謝謝。
三、注意事項
1、從節點添加
在實際使用中，我們在添加主節點之後（分配slots之前），同時爲其添加一個或多個從節點（從節點必須爲空）。
2、主節點刪除
在刪除主節點時，必須確保該主節點爲空，否則不能刪除該節點，可以刪除前將該節點的slots轉移分配到其它節點，然後再行刪除。
NOTE：
有人會疑惑，該主節點如果有從節點可以刪除嗎？答案是可以的，當該主節點被刪除之後，其所有的從節點會被隨機分配給其它的主節點，其繼續保持從節點的身份。
3、故障轉移
故障轉移從主節點的多個從節點中選舉了一個從節點，並將其升爲主節點，使繼續提供服務，那麼如果故障的主節點恢復之後，節點的主從關係如何？答案是，以最新的分配角色爲準，即升級爲主節點的從節點，繼續保持主節點身份，而恢復的舊主節點，其身份變爲了從節點。
技術討論羣：
489451956（新）