Redis replication主從復制原理及配置

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

主要參考官方文檔：

https://redis.io/topics/replication  

http://redisdoc.com/topic/replication.html

一.原理

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

http://redisdoc.com/topic/persistence.html

 
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次改變就觸發持久化。如果想關閉此功能的話，可以把全部save行都注釋或刪除或者使用save ""。
stop-writes-on-bgsave-error：在bgsave遇到error的時候是否停止持久化，默認是yes代表是，no代表不是
rdbcompression：是否壓縮，默認是yes代表是，no代表不是，如果想節省CPU的話就設為no，但rdb文件會比較大
dbfilename：持久化的文件名字，默認是dump.rdb
dir：持久化的目錄名字，默認是redis.conf所在的目錄./

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文件大小.

復制功能的運作原理
無論是初次連接還是重新連接， 當建立一個從服務器時， 從服務器都將向主服務器發送一個 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等方案做整理