介紹

redis支援複製的功能以實現當一臺伺服器的資料更新後，自動將新的資料同步到其它資料庫。

把資料庫分為主資料庫master和從資料庫slave，當主資料庫可以進行讀寫操作，從資料庫一般是隻讀的，當主資料庫資料變化的時候會自動同步給從資料庫。

為什麼需要複製

1. 可以實現讀寫分離，從而提高系統業務處理效能。
2. 方便在主資料庫奔潰時的資料恢復

配置

複製的配置方式非常簡單，只需要在從資料庫上配置 slaveof <masterip> <masterport> 即可。主資料庫不用作任何改變。

測試環境的搭建

1. 方法一：安裝三個虛擬機器，並分別安裝redis。
2. 方法二：在同一臺虛擬機器上執行多個redis例項，但是要通過配置檔案進行區分。
   
   • 複製一份redis.conf並命名於 redis_6378.conf
   • 修改複製出來的配置檔案中的內容
   • port 6378
   • unixsocket /tmp/redis_6378.sock
   • pidfile /var/run/redis_6378.pid
   • logfile "log_6378.log"
   • dbfilename dump_6378.rdb
   • appendfilename "appendonly_6378.aof"

假設你和我一樣有兩個redis例項，主例項埠為6378，從例項埠為6379。你需要在 redis_6379.conf

redis_6379.conf

# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6378

• 儲存配置檔案並重啟redis例項，在日誌中可以看到配置成功的資訊。

5581:S 04 Jul 10:55:40.606 * Connecting to MASTER 127.0.0.1:6378
5581:S 04 Jul 10:55:40.606 * MASTER <-> SLAVE sync started
5581:S
 
 04 Jul 10:55:40.607 * Non blocking connect for SYNC fired the event.
5581:S 04 Jul 10:55:40.607 * Master replied to PING, replication can continue...
5581:S 04 Jul 10:55:40.607 * Partial resynchronization not possible (no cached master)
5581:S 04 Jul 10:55:40.613 * Full resync from master: 268a828c8f410ce4abeda4f8425bd846bb568170:1
5581:S 04 Jul 10:55:40.664 * MASTER <-> SLAVE sync: receiving 76 bytes from master
5581:S 04 Jul 10:55:40.664 * MASTER <-> SLAVE sync: Flushing old data
5581:S 04 Jul 10:55:40.664 * MASTER <-> SLAVE sync: Loading DB in memory
5581:S 04 Jul 10:55:40.665 * MASTER <-> SLAVE sync: Finished with success

複製的基本操作命令

1. info replication 檢視複製節點的相關資訊
2. slaveof host port 可在執行期間修改slave節點的資訊，如果該資料庫已經是某個主資料庫的從資料庫，那麼會停止和原主資料庫的同步關係，轉而和新的主資料庫同步。
3. slaveof no one 使當前資料庫停止與其他資料庫的同步，轉成主資料庫

複製的基本原理

1. slave啟動時會向master傳送sync命令（2.8版後傳送psync以實現增量複製）
2. 主資料庫接到sync請求後在後臺儲存快照，也就是實現RDB持久化，並將保
   存快照期間接收到的命令快取起來。
3. 快照完成後主資料庫會將快照檔案和所有快取的命令傳送給從資料庫
4. 從資料庫接收後會載入快照檔案並執行快取的命令，從而完成複製的初始化。
5. 在資料庫使用階段主資料庫會自動把每次收到的寫命令同步到從伺服器。

配置檔案中複製部分

• slaveof 指定某一個redis作為另一個redis的從伺服器，通過指定IP和埠來設定主redis。建議為從redis設定一個不同頻率的快照持久化的週期，或者為從redis配置一個不同的服務埠。
• masterauth 如果主redis設定了驗證密碼的話（使用requirepass來設定），則在從redis的配置中要使用masterauth來設定校驗密碼，否則主redis會拒絕從redis的訪問請求。
• slave-serve-stale-data 設定當從redis失去了與主redis的連線，或者主從同步正在進行中時，redis該如何處理外部發來的訪問請求。
  
  • 如果設定為yes（預設）則從redis仍會繼續響應客戶端的讀寫請求。
  • 如果設定為no，則從redis會對客戶端的請求返回 SYNC with master in progress，當然也有例外，當客戶端發來INFO請求和SLAVEOF請求，從redis還是會進行處理。
  • 從redis2.6版本之後，預設從redis為只讀。
• slave-read-only 設定從Redis為只讀
• repl-ping-slave-period 設定從redis會向主redis發出PING包的週期，預設是10秒。
• repl-timeout 設定主從同步的超時時間，要確保這個時限比 repl-ping-slave-period 的值要大，否則每次主redis都會認為從redis超時。
• repl-disable-tcp-nodelay 設定在主從同步時是否禁用TCP_NODELAY，如果開啟，那麼主redis會使用更少的TCP包和更少的頻寬來向從redis傳輸資料。但是這可能會增加一些同步的延遲，大概會達到40毫秒左右。如果關閉，那麼資料同步的延遲時間會降低，但是會消耗更多的頻寬。
• repl-backlog-size 設定同步佇列長度。佇列長度（backlog）是主redis中的一個緩衝區，在與從redis斷開連線期間，主redis會用這個緩衝區來快取應該發給從redis的資料。這樣的話，當從redis重新連線上之後就不必重新全量同步資料，只需要同步這部分增量資料即可。
• repl-backlog-ttl 設定主redis要等待的時間長度，如果主redis等了這麼長時間之後，還是無法連線到從redis，那麼緩衝佇列中的資料將被清理掉。設定為0，則表示永遠不清理。預設是1個小時。
• slave-priority 設定從redis優先順序。在主redis持續工作不正常的情況，優先順序高的從redis將會升級為主redis。而編號越小優先順序越高。當優先順序被設定為0時，這個從redis將永遠也不會被選中。預設的優先順序為100。
• min-slaves-to-write 設定執行寫操作所需的最少從伺服器數量，如果至少有這麼多個從伺服器， 並且這些伺服器的延遲值都少於 min-slaves-max-lag 秒， 那麼主伺服器就會執行客戶端請求的寫操作。
• min-slaves-max-lag 設定最大連線延遲的時間。min-slaves-to-write和min-slaves-max-lag中有一個被置為0，則這個特性將被關閉。預設情況下min-slaves-to-write為0，而min-slavesmax-lag為10。

樂觀複製策略

Redis採用樂觀複製的策略，容忍在一定時間內主從資料庫的內容不同，儲存最終的資料會是一樣的。這個策略保證了效能，在複製的時候，主資料庫並不阻塞，照樣處理客戶端的請求。
Redis提供了配置來限制只有當資料庫至少同步給指定數量的從資料庫時，主資料庫才可寫，否則返回錯誤。配置是：min-slaves-to-write、min-slavesmax-lag。

無硬碟複製

當複製發生時主資料庫會在後臺儲存RDB快照，即使你關閉了RDB它也會這麼做，這樣就會導致一些問題。

1. 如果主資料庫關閉了RDB，現在強行生成了RDB，那麼下次主資料庫啟動的時候，可能會從RDB來恢復資料，這可能是舊的資料。
2. 由於要生成RDB檔案，在硬碟效能不高的時候會對效能造成一定影響，因此從2.8.18版本引入了無硬碟複製選項 repl-diskless-sync。

哨兵（sentinel）

• Redis提供了哨兵工具來實現監控Redis系統的執行情況，主要實現：
  
  1. 監控主從資料庫執行是否正常
  2. 當主資料庫出現故障時，自動將從資料庫轉換成為主資料庫
  3. 使用Redis-sentinel，redis例項必須在非叢集模式下執行

開啟哨兵功能

• 找到 sentinel.conf 檔案並設定被監控主資料庫
• sentinel monitor (監控的主資料庫的名字) 127.0.0.1 6378 1
• 1 表示選舉主資料庫的最低票數
• 這個檔案的內容在執行期間會被sentinel動態修改，一般追回到檔案的最後面。
• 可以同時監控多個主資料庫，一行一個配置即可。
• 如果監控的主資料庫故障，則哨兵將從slave中選舉master，後續原來的master服務恢復後會作為slave處理。