Redis replication主從複製原理及配置

本文主要介紹Redis replication 主從複製原理和配置及基本操作 等

主要參考官方文件：

 

一.原理

This system works using three main mechanisms:
系統工作的三個主要機制：   
1. When a master and a slave instances are well-connected, the master keeps the slave updated by sending a stream of commands to the slave, in order to replicate the effects on the dataset happening in the master side due to: client writes, keys expired or evicted, any other action changing the master dataset.
當master和slave例項連線良好時，master透過從slave傳送命令流來更新slave

2. When the link between the master and the slave breaks, for network issues or because a timeout is sensed in the master or the slave, the slave reconnects and attempts to proceed with a partial resynchronization: it means that it will try to just obtain the part of the stream of commands it missed during the disconnection.
當master和slave連線中斷時，因為網路故障或者感知到master或者slave超時。Slave重連並試圖進行重新同步：意味著獲取失去連線時丟失的命令流

3. When a partial resynchronization is not possible, the slave will ask for a full resynchronization. This will involve a more complex process in which the master needs to create a snapshot of all its data, send it to the slave, and then continue sending the stream of commands as the dataset changes.
當無法重新部分同步(partial resynchronization)時，slave將要求完全重新同步(full resynchronization)。它將包含一個複雜過程，這過程中master需要為所有資料建立一個快照，傳送到slave，再繼續對變化的資料傳送命令流

資料安全性概念
Redis的持久化儲存主要提供兩種方式：RDB與AOF

 
1. RDB(Snapshot)模式

是預設的，即儲存某一時刻的資料到硬碟，在下一次觸發snapshot前如果伺服器crash，在上次snapshot之後修改的資料會丟失。

主要配置redis.conf引數：

save <seconds> <changes>
stop-writes-on-bgsave-error yes
rdbcompression yes
dbfilename dump.rdb
dir ./

引數說明：
save <seconds> <changes>：在X秒內如果key有至少X次改變就觸發持久化，例如save 900 1的話就是在900秒如果key有至少1次改變就觸發持久化(其實執行bgsave命令)。如果想關閉此功能的話，可以把全部save行都註釋或刪除或者使用save ""。
stop-writes-on-bgsave-error：在bgsave遇到error的時候是否停止持久化，預設是yes代表是，no代表不是
rdbcompression：是否壓縮，預設是yes代表是，no代表不是，如果想節省CPU的話就設為no，但rdb檔案會比較大
dbfilename：持久化的檔名字，預設是dump.rdb
dir：持久化的目錄名字，預設是redis.conf所在的目錄./

注：save和bgsave命令區別

SAVE  儲存是阻塞主程式，客戶端無法連線redis，等SAVE完成後，主程式才開始工作，客戶端可以連線

BGSAVE  是fork一個save的子程式，在執行save過程中，不影響主程式，客戶端可以正常連結redis，等子程式fork執行save完成後，通知主程式，子程式關閉。很明顯BGSAVE方式比較適合線上的維護操作，兩種方式的使用一定要了解清楚在謹慎選擇。

2.AOF(append-only file)模式

需要手動開啟，開啟後以追加的方式預設每秒鐘將記錄的修改操作儲存到硬碟
主要配置redis.conf引數：

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
dir ./
### 以下rewrite引數，AOF模式以追加方式記錄所有寫操作命令到硬碟，檔案會越來越大，為緩解這種問題，redis使用了BGREWRITEAOF用於刪除重複多餘的寫命令，類似BGSAVE，rewrite的時候會刪除舊的AOF檔案
###
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
引數說明：
appendonly：是否啟動aof，預設是no代表不啟用
appendfilename：aof的檔名，預設是appendonly.aof
appendfsync：觸發的間隔，預設是everysec代表每秒，還可使用always代表有改變都觸發，效能差些但資料最安全，no代表讓OS自己決定什麼時候執行，效能最好但資料不安全
dir：持久化的目錄名字，預設是redis.conf所在的目錄./
no-appendfsync-on-rewrite：執行rewrite時appendfsync是否暫停，預設no代表不暫停
auto-aof-rewrite-percentage：aof rewrite觸發時機，當前aof檔案大小超過上一次rewrite後aof檔案的百分比後觸發rewrite。如200，即當前的aof檔案超過上一次重寫後aof檔案的2倍時才會再次rewrite
auto-aof-rewrite-min-size aof檔案重寫最小檔案大小，即最開始aof檔案必須要達到這個檔案時才觸發，後面的每次重寫就不會根據這個變數了(根據上一次重寫完成之後的大小).此變數僅初始化啟動redis有效.如果是redis恢復時，則lastSize等於初始aof檔案大小.

rewrite目的：減少磁碟佔用，提升恢復速度

RDB 和AOF比較

複製功能的運作原理
無論是初次連線還是重新連線， 當建立一個從伺服器時， 從伺服器都將向主伺服器傳送一個 SYNC 命令。
接到 SYNC 命令的主伺服器將開始執行 BGSAVE ， 並在儲存操作執行期間， 將所有新執行的寫入命令都儲存到一個緩衝區裡面。
當 BGSAVE 執行完畢後， 主伺服器將執行儲存操作所得的 .rdb 檔案傳送給從伺服器， 從伺服器接收這個 .rdb 檔案， 並將檔案中的資料載入到記憶體中。
之後主伺服器會以 Redis 命令協議的格式， 將寫命令緩衝區中積累的所有內容都傳送給從伺服器。
即使有多個從伺服器同時向主伺服器傳送 SYNC ， 主伺服器也只需執行一次 BGSAVE 命令， 就可以處理所有這些從伺服器的同步請求。
從伺服器可以在主從伺服器之間的連線斷開時進行自動重連， 在 Redis 2.8 版本之前， 斷線之後重連的從伺服器總要執行一次完整重同步（full resynchronization）操作， 但是從 Redis 2.8 版本開始， 從伺服器可以根據主伺服器的情況來選擇執行完整重同步還是部分重同步（partial resynchronization）。

部分重同步
從 Redis 2.8 開始， 在網路連線短暫性失效之後， 主從伺服器可以嘗試繼續執行原有的複製程式（process）， 而不一定要執行完整重同步操作。
這個特性需要主伺服器為被髮送的複製流建立一個記憶體緩衝區（in-memory backlog）， 並且主伺服器和所有從伺服器之間都記錄一個複製偏移量（replication offset）和一個主伺服器 ID （master run id）， 當出現網路連線斷開時， 從伺服器會重新連線， 並且向主伺服器請求繼續執行原來的複製程式：
• 如果從伺服器記錄的主伺服器 ID 和當前要連線的主伺服器的 ID 相同， 並且從伺服器記錄的偏移量所指定的資料仍然儲存在主伺服器的複製流緩衝區裡面， 那麼主伺服器會向從伺服器傳送斷線時缺失的那部分資料， 然後複製工作可以繼續執行。
• 否則的話， 從伺服器就要執行完整重同步操作。
Redis 2.8 的這個部分重同步特性會用到一個新增的 PSYNC master_run_id offset 內部命令， 而 Redis 2.8 以前的舊版本只有 SYNC 命令， 不過， 只要從伺服器是 Redis 2.8 或以上的版本， 它就會根據主伺服器的版本來決定到底是使用 PSYNC master_run_id offset 還是 SYNC ：
• 如果主伺服器是 Redis 2.8 或以上版本，那麼從伺服器使用 PSYNC master_run_id offset 命令來進行同步。
• 如果主伺服器是 Redis 2.8 之前的版本，那麼從伺服器使用 SYNC 命令來進行同步。

二. replication具體配置
實驗：一臺機器上配置兩個伺服器 master 6379  slave 6380

版本：redis_version:3.0.6

Master: 除 appendonly改yes,其它使用預設值即可

/usr/local/redis/etc/redis.conf   

appendonly yes

因為在同一臺server上做slave測試需要複製一份配置檔案，並分別更改埠號，pid檔名字，dump.rdb名字，aof檔名字
Slave:  /usr/local/redis/etc/redis.conf.6380
pidfile /var/run/redis6380.pid
port 6380
dbfilename dump6380.rdb
appendfilename "appendonly6380.aof"
appendonly yes
slaveof 127.0.0.1 6379

注：從 Redis 2.6 開始， slave支援只讀模式， 且為slave的預設模式。
# Since Redis 2.6 by default slaves are read-only.
slave-read-only yes

開啟slave
# redis-server /usr/local/redis/etc/redis.conf.6380

檢視狀態
master中執行：
[root@cloud ~]# redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=57,lag=0
master_repl_offset:57
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:56
127.0.0.1:6379> role
1) "master"  --當前server角色
2) (integer) 71 --當前server複製偏移量
3) 1) 1) "127.0.0.1"  --下屬slave IP
      2) "6380" --下屬slave port
      3) "71" --下屬slave複製偏移量

slave中執行：
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:83567
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

127.0.0.1:6380> role
1) "slave"  --當前server角色
2) "127.0.0.1"  --上層master IP
3) (integer) 6379 --上層master port
4) "connected"  
5) (integer) 83581 --目前從master接收到的複製副本偏移量

以上，master-slave 配置完成

注：因為 Redis 使用非同步複製， 所以master傳送的寫資料並不一定會被slave接收到。因此，資料丟失可能性仍然是存在的。

為了進一步保證資料安全，可設定master伺服器只在有至少 N 個slave伺服器的情況下，才執行寫操作

以下是這個特性的運作原理：
• 從伺服器以每秒一次的頻率 PING 主伺服器一次， 並報告複製流的處理情況。
• 主伺服器會記錄各個從伺服器最後一次向它傳送 PING 的時間。
• 使用者可以透過配置， 指定網路延遲的最大值 min-slaves-max-lag
以及執行寫操作所需的至少從伺服器數量 min-slaves-to-write 。

slave啟用為master

在slave伺服器執行命令 SLAVEOF NO ONE 將使得這個從屬伺服器關閉複製功能，並從slave伺服器轉變為master伺服器，原來同步所得資料集不會被丟棄。

利用“SLAVEOF NO ONE 不會丟棄同步所得資料集”這個特性，可以在主伺服器失敗的時候，將從屬伺服器用作新的主伺服器，從而實現無間斷執行。

上述，介紹了 Redis replication主從複製原理和最簡單的配置，後續會對Sentinel,Redis-Cluster等方案做整理