Redis主從複製網路閃斷處理

壹頁書發表於2016-05-25
先記錄幾個有意思的用法
1.重複執行
-r 選項重複執行一個命令指定的次數。
-i 設定命令執行的間隔。
比如檢視redis每秒執行的commands(qps)

./redis-cli -r 100 -i 1 info stats | grep instantaneous_ops_per_sec
instantaneous_ops_per_sec:334
instantaneous_ops_per_sec:306
instantaneous_ops_per_sec:294
instantaneous_ops_per_sec:349
instantaneous_ops_per_sec:371
instantaneous_ops_per_sec:380
instantaneous_ops_per_sec:388

2.獲取指定redis例項的rdb檔案,儲存到本地
redis-cli -h 192.168.44.16 -p 6379 --rdb 6379.rdb

3.模擬slave從master上接收到的commands
./redis-cli --slave

和monitor不一樣,monitor接收所有命令.而--slave僅僅接收 insert,update,delete的命令.

4.--scan和--pattern
代替 keys IM*
./redis-cli --scan --pattern 'IM*'

這樣不會長時間阻塞redis而導致其他客戶端的命令請求一直處於阻塞狀態。

參考:
%E7%9A%84%E4%B8%80%E4%BA%9B%E6%9C%89%E8%B6%A3%E4%B9%9F%E5%BE%88%E6%9C%89%E7%94%A8%E7%9A%84%E5%8A%9F%E8%83%BD/


最近經常收到郵件報警,
一般都是Redis CPU使用率達到閾值.
那是一個Slave例項,qps也就僅僅幾百而已.
經過排查,應該是網路不穩定,導致的Slave斷線重連.

中間有幾個引數,還得重新回顧一下.

1.client-output-buffer-limit
redis server以單程式的方式處理接收到的請求,而redis完成請求有些工作比較慢,比如網路IO和磁碟IO等比較慢的操作。redis為了提高處理客戶端請求的響應時間,做了很多最佳化。比如網路io和磁碟io是非同步完成、使用後臺程式完成bgsave和bgrewriteaof工作,在server端為客戶提供讀buffer等等。
client buffer是在server端實現的一個讀取緩衝區。redis server在接收到客戶端的請求後,把影響結果寫入到client buffer中,而不是直接傳送給客戶端。server把結果寫入到client buffer中後,繼續處理客戶端的其他請求。這樣非同步處理方式使redis server不會因為網路原因阻塞其他請求的處理。之前的文章中replication buffer也是client buffer中的一種。

1) "client-output-buffer-limit"
2) "normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"

具體引數含義如下:
class : 客戶端種類,normal、slave、pubsub。
– mormal:普通的客戶端
– slave: 從庫的複製客戶端
– pub/sub: 釋出與訂閱的客戶端的
hard limit: 緩衝區大小的硬性限制。
soft limit: 緩衝去大小的軟性限制。
soft seconds: 緩衝區大小達到了(超過)soft limit值的持續時間。
client-output-buffer-limit引數限制分配的緩衝區的大小,防止記憶體無節制的分配。引數的預設值都為0,意思是不做任何限制。

hard limit:當buffer的量達到硬限制之後,redis立即斷開與client的連線
soft limit和soft seconds:當buffer的在soft seconds秒內超出了soft limit,redis不會關閉client連線。如果當buffer的在soft seconds秒之後,仍然超出了soft limit 的限制,則redis立即關閉client連線。

2.repl-timeout
redis裡面的repl-timeout引數值也太小也將會導致複製不成功.
redis配置檔案中對repl-timeout的引數解釋如下:
# The following option sets the replication timeout for:
#
# 1) Bulk transfer I/O during SYNC, from the point of view of slave.
# 2) Master timeout from the point of view of slaves (data, pings).
# 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
三種情況認為複製超時:
1)slave角度,如果在repl-timeout時間內沒有收到master SYNC傳輸的rdb snapshot資料,
2)slave角度,在repl-timeout沒有收到master傳送的資料包或者ping。
3)master角度,在repl-timeout時間沒有收到REPCONF ACK確認資訊。
當redis檢測到repl-timeout超時(預設值60s),將會關閉主從之間的連線,redis slave發起重新建立主從連線的請求。
對於記憶體資料集比較大的系統,可以增大repl-timeout引數。

3.slave ping period
redis slave會定期從master傳送ping命令,時間間隔repl-ping-slave-period指定。
因而,設定引數時, repl-timeout > repl-ping-slave-period。
# Slaves send PINGs to server in a predefined interval.  The default value is 10 seconds.
# repl-ping-slave-period 10
 
# It is important to make sure that this value is greater than the values pecified for repl-ping-slave-period otherwise a timeout will be detected every time there is low traffic between the master and the slave.

4.repl-backlog-size
當主伺服器進行命令傳播的時候,maser不僅將所有的資料更新命令傳送到所有slave的replication buffer,還會寫入replication backlog。當斷開的slave重新連線上master的時候,slave將會傳送psync命令(包含複製的偏移量offset),請求partial resync。如果請求的offset不存在,那麼執行全量的sync操作,相當於重新建立主從複製。

為了避免網路不穩定造成的全量同步.
修改引數如下:
config set repl-timeout 240
config set repl-backlog-size 67108864

參考:
%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6%EF%BC%884%EF%BC%89-client-buffer/
%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6%EF%BC%883%EF%BC%89-%E5%A4%8D%E5%88%B6%E8%B6%85%E6%97%B6/
http://leejia.blog.51cto.com/4356849/1419997

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29254281/viewspace-2106724/,如需轉載,請註明出處,否則將追究法律責任。

相關文章