Redis全量復制與部分復制示例詳解

2020-10-28 21:29:16

字體：大中小

來源：轉載

供稿：網友

Redis 主從復制

Redis 實例劃分為主節點(master)和從節點(slave)
默認情況下，Redis都是主節點
每個從節點只能有一個主節點，而主節點可以同時具有多個從節點
復制的數據流是單向的，只能由主節點復制到從節點
slaveof 命令在使用時，可以運行期動態配置，也可以提前寫到配置文件中
主從復制

步驟	詳細描述
保存主節點信息	執行slaveof后從節點只保存主節點的地址信息便直接返回
主從建立socket連接	從節點(slave)內部通過每秒運行的定時任務維護復制相關邏輯，當定時任務發現存在新的主節點后，會嘗試與該節點建立網絡連接;從節點會建立一個socket套接字，專門用于接受住節點發送的復制命令；如果從節點無法建立連接，定時任務會無限重試直到連接成功或者執行 slaveof no one 取消復制
發送ping命令	連接建立成功后從節點發送ping請求進行首次通信，ping請求的目的：檢測主從之間套接字是否可用；檢測主節點當前是否可接受處理命令.如果發送ping命令后，從節點沒有收到主節點的pong回復或者超時，比如網絡超時或者主節點正在阻塞無法響應命令，從節點會端口復制連接，下次定時任務會發起重連
權限驗證	如果主節點設置了requirepass 參數，則需要密碼驗證，從節點必須配置masterauth參數保證與主節點相同的密碼才能通過驗證；如果驗證失敗復制將終止，從節點重新發起復制流程
同步數據集	主從復制連接正常通信后，對于首次建立復制的場景，主節點會把持有的數據全部發送給從節點.
命令持續復制	當主節點把當前的數據同步給從節點后，變成了復制的建立流程，接下來主節點會持續地把寫命令發送給從節點，保證主從數據一致性

啟動6380、6381
6381 執行命令

127.0.0.1:6381> slaveof 127.0.0.1 6380Redis5.0.0 改為 ： replicaof <masterip> <masterport>

6380 啟動

6381 啟動

查看info replication

數據同步

類型	描述
全量復制	一般用于初次復制場景，Redis早期支持的復制功能只有全量復制，它會把主節點全部數據一次性發送給從節點，當數據量較大時，會對主從節點和網絡造成很大的開銷
部分復制	用于處理在主從復制中因網絡閃斷等原因造成的數據丟失場景，當從節點再次連上主節點后，如果條件允許，主節點會補發丟失數據給從節點。因為補發的數據遠遠小于全量數據，可以有效避免全量復制的過高開銷

復制偏移量

參數	描述
master_repl_offset	參與復制的主從節點都會維護自身復制偏移量。主節點(master)在處理完寫入命令后，會把命令的字節長度做累加記錄，統計信息在info replication中的master_repl_offset指標中
slave0	從節點(slave) 每秒鐘上報自身的復制偏移量給主節點，因此主節點也會保存從節點的復制偏移量
slave_repl_offset	從節點在接收到主節點發送的命令后，也會累加記錄自身的偏移量。

復制積壓緩沖區

復制積壓緩沖區是保存在主節點上的一個固定長度的隊列，默認大小為1MB，當主節點有連接的從節點(slave)時被創建，這是主節點(master)響應寫命令時，不但會把命名發送給從節點，還會寫入復制積壓緩沖區
由于緩沖區本質上是先進先出的定長隊列，所以能實現保存最近已復制數據的功能，用于部分復制和復制命令丟失的數據補救

參數	描述
repl_backlog_active:1	開啟復制緩沖區
repl_backlog_size:1048576	緩沖區最大長度
repl_backlog_first_byte_offset:1	起始偏移量，計算當前緩沖區可用范圍
repl_backlog_histlen:2301	已保存數據的有效長度
master_replid	主節點實例的master_replid相同
master_replid2	未發生切換，即主實例未發生過變化，所以初始值為0

psync 命令

從節點使用psync命令完成部分復制和全量復制功能

30227:M 05 Aug 2019 18:52:44.698 * Replica 127.0.0.1:6381 asks for synchronization30227:M 05 Aug 2019 18:52:44.698 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'e7d71fb600183a175afadbd1354e97edddb2541a', my replication IDs are 'e24f6e42917e7c162ec45a713b0ee3872005ee8b' and '0000000000000000000000000000000000000000')

6381 從節點打印分析

31771:S 06 Aug 2019 12:21:40.213 * DB loaded from disk: 0.000 seconds31771:S 06 Aug 2019 12:21:40.213 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.#啟動成功31771:S 06 Aug 2019 12:21:40.213 * Ready to accept connections# 開始連接主節點31771:S 06 Aug 2019 12:21:40.214 * Connecting to MASTER 127.0.0.1:6380# 開始同步31771:S 06 Aug 2019 12:21:40.214 * MASTER <-> REPLICA sync started31771:S 06 Aug 2019 12:21:40.214 * Non blocking connect for SYNC fired the event.31771:S 06 Aug 2019 12:21:40.214 * Master replied to PING, replication can continue...# 嘗試增量同步31771:S 06 Aug 2019 12:21:40.214 * Trying a partial resynchronization (request 668b25f85e84c5900e1032e4b5e1f038f01cfa49:5895).# 全量同步31771:S 06 Aug 2019 12:21:40.215 * Full resync from master: c88cd043d66193e867929d9d5fadc952954371e5:031771:S 06 Aug 2019 12:21:40.215 * Discarding previously cached master state.31771:S 06 Aug 2019 12:21:40.240 * MASTER <-> REPLICA sync: receiving 224 bytes from master31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Flushing old data31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Loading DB in memory31771:S 06 Aug 2019 12:21:40.241 * MASTER <-> REPLICA sync: Finished with success

全量復制

全量復制是Redis最早支持的復制方式，也是主從第一次建立復制時必須經歷的階段。觸發全量復制的命令是sync和psync
- 發送psync命令進行數據同步，由于是第一次進行復制，從節點沒有復制偏移量和主節點的運行ID，所以發送psync-1
- 主節點根據psync-1解析出當前為全量復制，回復+FULLRESYNC響應
- 從節點接收主節點的響應數據保存運行ID和偏移量offset
- 主節點執行bgsave保存RDB文件到本地

31651:M 06 Aug 2019 11:08:40.802 * Starting BGSAVE for SYNC with target: disk31651:M 06 Aug 2019 11:08:40.802 * Background saving started by pid 3167631676:C 06 Aug 2019 11:08:40.805 * DB saved on disk31676:C 06 Aug 2019 11:08:40.806 * RDB: 0 MB of memory used by copy-on-write31651:M 06 Aug 2019 11:08:40.886 * Background saving terminated with success31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded

主節點發送RDB給從節點，從節點把接收的RDB文件保存在本地并直接作為從節點的數據文件,接收完RDB后從節點打印相關日志

31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: receiving 224 bytes from master

對于從節點開始接收RDB快照到接收完成期間，主節點仍然響應讀寫命令，因此主節點會把這期間寫命令數據保存在復制客戶端緩沖區內，當從節點加載完RDB文件后，主節點再把緩沖區內的數據發送個從節點，保證主從之間數據一致性。
redis.conf 配置

client-output-buffer-limit replica 256mb 64mb 60

如果主節點創建和傳輸RDB的時間過長，對于高流量寫入場景非常容易造成主節點復制客戶端緩沖區溢出。默認配置如上所示，如果60秒內緩沖區消耗持續大于64MB或者直接超過256MB時，主節點將直接關閉復制客戶端連接，造成全量同步失敗
對于主節點，當發送完所有的數據后就認為全量復制完成.

31651:M 06 Aug 2019 11:08:40.886 * Synchronization with replica 127.0.0.1:6381 succeeded

從節點接收完主節點傳送來的全部數據后會清空自身舊數據

31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Flushing old data

從節點清空數據后開始加載RDB文件，對于較大的RDB文件，這一步操作依然比較耗時，可以通過計算日志之間的時間差來判斷加載RDB的總耗時

31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Loading DB in memory31645:S 06 Aug 2019 11:08:40.886 * MASTER <-> REPLICA sync: Finished with success

從節點成功加載完RDB后，如果當前節點開啟了AOF持久化功能，它會立刻做bgrewriteaof操作，為了保證全量復制后AOF持久化文件立刻可用。
全量復制耗時的原因：
- 主節點bgsave時間
- RDB文件網絡傳輸時間
- 從節點清空數據時間
- 可能的AOF重寫時間
以下為Redis 3.0才會有

標識	含義
M	當前為主節點日志
S	當前為從節點日志
C	子進程日志

部分復制

部分復制主要是Redis針對全量復制的過高開銷做出的一種優化措施，使用psync {runId}{offset}命令實現。當從節點(slave)正在復制主節點(master)時，如果出現網絡閃斷或者命令丟失等異常情況時，從節點會向主節點要求補發丟失的命令數據，如果主節點的復制積壓緩沖區內存咋這部分數據則直接發送給從節點，這樣就可以保持主從節點復制的一致性。補發的這部分數據一般遠遠小于全量數據.
- 當主節點直接網絡出現中斷是，如果超過repl-timeout時間，主節點會認為從節點故障并中斷復制連接

31767:M 06 Aug 2019 14:13:26.096 # Connection with replica 127.0.0.1:6381 lost.

主從連接中斷期間主節點依然響應命令，但因復制連接中斷命令無法發送給從節點，不過主節點內部存在的復制積壓緩沖區，依然可以保存最近一段時間的寫命令數據，默認最大緩存1MB，可以通過into replication 查看
當從節點網絡恢復后，從節點會再次連上主節點

從節點打?。?1934:S 06 Aug 2019 14:20:54.745 * MASTER <-> REPLICA sync started31934:S 06 Aug 2019 14:20:54.745 * Non blocking connect for SYNC fired the event.31934:S 06 Aug 2019 14:20:54.745 * Master replied to PING, replication can continue...31934:S 06 Aug 2019 14:20:54.745 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:9996).31934:S 06 Aug 2019 14:20:54.746 * Successful partial resynchronization with master.31934:S 06 Aug 2019 14:20:54.746 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.主節點打?。?1767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.

當主從連接恢復后，由于從節點之前保存了自身已復制的偏移量和主節點的運行ID。因此會把它們當做psync參數發送個主節點，要求進行部分復制操作.從節點對應日志：

31938:S 06 Aug 2019 14:21:49.065 * Trying a partial resynchronization (request c88cd043d66193e867929d9d5fadc952954371e5:10066).

主節點接到psync命令后首先核對參數runId是否與自身一致，如果一致，說明之前復制的是當前主節點；之后根據參數offset在自身復制積壓緩沖區查找，如果偏移量之后的數據存在緩沖區中，則對從節點發送+COUTINUE響應，表示可以進行部分復制。從節點接到回復打印如下：

31938:S 06 Aug 2019 14:21:49.066 * Successful partial resynchronization with master.31938:S 06 Aug 2019 14:21:49.066 * MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization.

主節點根據偏移量把復制積壓緩沖區里的數據發送給從節點，保證主從復制進入正常狀態。發送的數據量可以在主節點的日志獲取

31767:M 06 Aug 2019 14:21:49.065 * Replica 127.0.0.1:6381 asks for synchronization31767:M 06 Aug 2019 14:21:49.066 * Partial resynchronization request from 127.0.0.1:6381 accepted. Sending 0 bytes of backlog starting from offset 10066.

心跳

主從節點在建立復制后,它們之間維護著長連接并彼此發送心跳命令
主從心跳判斷機制：
- 主從節點彼此都有心跳檢測機制，各自模擬對方的客戶端進行通信，主節點的連接狀態為flags=M,從節點連接狀態為flags=S
- 主節點默認每隔10秒對從節點發送ping命令，判斷從節點的存活性和連接狀態?？梢酝ㄟ^repl-ping-replica-period 10 控制發送頻率
- 從節點在主線程中每隔一秒發送replconf ack{offset} 命令，給主節點上報自身當前的復制偏移量。主節點根據replconf命令判斷從節點超時時間，體現在info replication 統計中的lag信息中，lag表示從節點最后一次通信延遲的秒數，正常延遲應該在0到1之間。如果超過repl-timeout配置的值(默認60秒),則判定從節點下線并斷開復制客戶端連接。即使主節點判定從節點下線后，如果從節點重新恢復，心跳檢測和繼續執行.

異步復制