redis的備份

標籤：redis   備份   伺服器   

redis的備份功能使用非常簡單。配置一個主從式備份機制使得redis的從伺服器與主伺服器完全一樣。以下是對redis備份非常重要的描述。
redis使用非同步備份。從2.8版本開始，從站會周期性地從備份流中接收一定量的資料。

• 主站可以有多個從站。
• 從站能夠接收來自其它從站的串連請求。除了串連多個從站到同一個主站，從站還可以串連到其它從站，形成一個圖狀結構。
• redis備份在主站端是非阻塞的。這就意味著當有從站在執行首次同步處理時，主站仍可以繼續處理請求。
• 在從站端也是非阻塞的。當從站在執行首次同步處理時，它仍然可以使用舊版本的資料集處理請求，只要你在redis.conf中這樣配置過。相反，你也可以這樣配置從站，在備份流停止時向用戶端返回一個錯誤。然而，首次同步處理之後，舊的資料集必須被刪除，新的資料集必須被載入。在這段時間，從站會阻塞接下來的串連請求。
• 備份既可以用於擴充，使多個從站都可以處理唯讀類型的請求（例如，耗時的SORT操作可以離線地分給多個從站），也可用於資料冗餘。
• 可以通過備份來避免因為主站把所有資料寫到硬碟帶來的開銷：只需要配置主站的redis.conf檔案去掉儲存操作（把所有的SAVE指令注釋掉），然後連上一個配置成定時儲存的從站。要使用這種配置，必須保證主站不會自動重啟（請閱讀下一節擷取更多資訊）

主站關閉持久化時備份的安全性

在使用redis備份的配置中，強烈建議在主站上開啟持久化。如果因為類似於潛在顧慮等原因不允許開啟持久化，那麼主站應該配置成避免自動重啟。
想要更好地理解為什麼不開啟持久化的主站配置成自動重啟是危險的，請閱讀以下失敗的模型。在這些模型中，主站和它所有的從站上 的資料都被清除了：

1. 我們配置一個節點A作為主站，關閉它的持久化，而節點B和C是節點A的備份。
2. A崩潰了。因為A配置成了自動重啟的系統，A的進程重啟了。然而由於持久化是關閉的，所有的節點重啟時資料集是空的。
3. 節點B和C會從A備份，但A是空的，所以它們會刪除它們的資料副本。

即使Redis的 Sentinel具有高可用性，關閉主站上的持久化，並允許進程的自動重啟，也是危險的。例如如果主站重啟太快，以至於Sentinel還來不及檢測到錯誤，那麼上面錯誤模型描述的情形也會發生了。
資料安全永遠是重要的，在備份情況下，要禁止把主站配置成沒有持久化且允許執行個體重啟的配置。

redis的備份是怎樣工作的？

當你配置了一個從站，它會基於串連發送一個SYNC命令。它並不關心這是它第一次串連或是一次重連。
然後主站開始儲存環境，並將所有新收到的會改變資料集的命令放入緩衝區。背景儲存完成後，主站將資料庫檔案遷移到從站，然後載入到記憶體。從站則把資料庫檔案儲存到硬碟。主站會把所有緩衝區的命令發送給從站。這通過一個命令流來完成，格式與redis本身的協議相同。
你可以通過telnet實驗。將telnet串連到redis的連接埠，同時讓伺服器做一些工作，然後執行SYNC命令。你會看到一個大塊資料的傳輸，所有主站收到的命令都會在telnet會話上重新執行。
當主站與從站之間的連結由於某種原因掛掉時，從站會自動重連。如果主站收到多條當前從站的同步請求，它會執行一個背景儲存來處理所有的請求。
串連掛掉後主站與從站重連時，通常會執行一個全部的同步。然而從redis2.8版本開始，部分同步也是可以的。

部分同步

從2.8版本開始，當備份掛掉時，主站和從站通常能夠繼續備份而不需要一個完整同步。
通過在主站中建立一個用於儲存備份流的記憶體塊就可以實現這一點。主站和所有從站在備份位移和主站的運行ID上達成共識。因此當連結掛掉，從站會重連並請求主站繼續備份。如果主站的運行ID保持不變，且位移在備份記憶體塊上仍然可用，那麼備份會從掛掉的那個點恢複。如果其中任意一個條件不滿足，就會執行完整的同步（這是2.8版本以前是正常行為）。由於所串連的主站的運行ID並不儲存在執行個體的硬碟上，從站重啟時需要完整同步。
部分同步這個新特性在內部使用PSYNC命令，而舊的實現使用SYNC命令。需要注意的是，2.8版本的從站能夠檢測它所已連線的服務器是否支援PSYNC，如果不支援，則使用SYNC。

無硬碟的備份

通常情況下，一個完整的備份需要在硬碟上建立一個RDB檔案，然後從硬碟載入這個RDB檔案用於給從站發資料。
由於硬碟低速，這對於主站來說是一個很有壓力的操作。2.8.18版本是第一個嘗試支援無硬碟備份的版本。在這種配置中子進程直接通過網線把RDB檔案發給從站，而不需要硬碟作為中間儲存。
這個特性目錄還是實驗性的。

配置

要配置備份很簡單，只需要增加以下這一行到從站的設定檔中
slaveof 192.168.1.1 6379
當然你要把192.168.1.1 6379替換成你的主站IP地址（或主機名稱）和連接埠。同樣，你也可以調用SLAVEOF命令，主站就會開始與這個從站同步。
還有一些參數用於協調主站從記憶體中擷取的備份記憶體塊來執行部分同步。請查閱redis版本中內建的redis.fonf中的例子擷取更多的資訊。
無硬碟備份可以通過repl-diskless-sync參數開啟。延遲開始轉移資料是為了等待更多的從站到達，延遲功能通過repl-diskless-sync-delay參數開啟。請查閱redis版本中內建的redis.conf中的例子擷取更多的資訊。

唯讀從站

從redis的2.6版本開始，從站支援設定為唯讀功能，而且是預設開啟的。這個行為由redis.conf檔案中的slave-read-only選項控制，也能夠通過CONFIG SET命令在已耗用時間開啟或關閉。
唯讀從站會拒絕所有寫命令，所以不可能向一個從站寫入，因為這樣會返回一個錯誤。這並不是說這個特性是為了讓一個從站執行個體暴露到網路中或者在一個不受信任的網路中給用戶端使用，因為像DEBUG或CONFIG這樣的管理命令仍然可用。然而，唯讀執行個體的安全性可能通過禁用這些命令來實現，需要在redis.conf檔案中使用rename-command指令。
你可能會奇怪，為什麼可以還原唯讀設定，使從站執行個體能夠成為寫操作的目標。但是如果從站和主站同步或者從站重啟，這些寫入會被丟棄。只是允許一些合理的向可寫從站儲存臨時資料的用例。以後這個特性可能會被去除。

配置一個可向主站認證的從站

如果你的主站要求輸入密碼來處理請求，就要配置從站在所有的同步操作中使用這個密碼。
要在一個運行中的執行個體上實現這一點，在redis用戶端上輸入：

config set masterauth <password>

想要永久地設定，把它加入到你的設定檔

masterauth <password>

有N個串連的備份時才允許寫入

從redis的2.8版本開始可以這樣配置，只有在至少N個從站串連到主站時才允許redis主站接受寫請求。
然後由於redis使用非同步備份，不可能保證從站真正地接收一個給定的寫操作，因此常常會有一個視窗的資料丟失。
這個特性是這樣工作的：

• redis從站每秒ping一次主站，以告知主站備份流的處理進度。
• reids主站會記錄每個從站上一次發來的ping命令。
• 使用者可以配置從站的最小數量值，以及從站ping命令時間間隙不可以超過最大秒數。

如果至少有N個從站，且時間間隙少於M秒，就可以接受寫操作。
你可以把它看作CAP理論的一個“C”的鬆弛版本，對於一個給定的寫入，一致性不可能保證，但至少可以保證資料丟失的數量嚴格控制在給定的數秒內。
如果條件不滿足，主站就會回複一個錯誤而寫入則不接受。
有兩個配置參數可以用於這個特性：

min-slaves-to-write < number of slaves> min-slaves-max-lag < number of seconds>

要擷取更多的資訊，請查閱redis版本中內建的redis.fonf中的例子。

redis的備份