標籤:replication master 用戶端
注意:在master-slave部署模式下,只需slave執行個體配置Peplication相關項目,各項含義說明如下。
1) slaveof <masterip> <masterport>
slave執行個體需要配置該項,指向master的(ip, port)。
2) masterauth <master-password>
如果master執行個體啟用了密碼保護,則該配置項需填master的啟動密碼;若master未啟用密碼,該配置項需要注釋掉
3) slave-serve-stale-data
指定slave與master串連中斷時的動作。預設為yes,表明slave會繼續應答來自client的請求,但這些資料可能已經到期(因為串連中斷導致無法從master同步)。若配置為no,則slave除正常應答"INFO"和"SLAVEOF"命令外,其餘來自用戶端的請求命令均會得到"SYNC with master in progress"的應答,直到該slave與master的串連重建成功或該slave被提升為master。
4) slave-read-only
指定slave是否唯讀,預設為yes。若配置為no,這表示slave是可寫的,但寫的內容在主從同步完成後會被刪掉。
5) repl-ping-slave-period
Redis部署為Replication模式後,slave會以預定周期(預設10s)發PING包給master,該配置可以更改這個預設周期。
6) repl-timeout
有2種情況的逾時均由該配置指定:1) Bulk transfer I/O timeout; 2) master data or ping response timeout。
需要特別注意的是:若修改預設值,則使用者輸入的值必須大於repl-ping-slave-period的配置值,否則在主從鏈路延時較高時,會頻繁timeout。
7) repl-disable-tcp-nodelay
指定向slave同步資料時,是否禁用socket的NO_DELAY選項。若配置為yes,則禁用NO_DELAY,則TCP協議棧會合并小包統一發送,這樣可以減少主從節點間的包數量並節省頻寬,但會增加資料同步到slave的時間。若配置為no,表明啟用NO_DELAY,則TCP協議棧不會延遲小包的發送時機,這樣資料同步的延時會減少,但需要更大的頻寬。通常情況下,應該配置為no以降低同步延時,但在主從節點間網路負載已經很高的情況下,可以配置為yes。
備忘:socket的NO_DELAY選項涉及到TCP協議棧的擁塞控制演算法—Nagle‘s Algorithm。
8) slave-priority
指定slave的優先順序。在不只1個slave存在的部署環境下,當master宕機時,Redis Sentinel會將priority值最小的slave提升為master。需要注意的是,若該配置項為0,則對應的slave永遠不會被Redis Sentinel自動提升為master。
關於Replication,需要明確的幾點(以下內容主要總結自這裡):
a. Redis的Replication跟cluster的概念不同。假如S是M的slave,則M不能把自己設定成為S的slave。若S掛掉,則M正常工作;相反,若M掛掉,則S可能會停止正常工作,這裡用"可能",是因為S的具體行為由其設定檔中的slave-serve-stale-data來決定。
b 假設共2個節點,M為master,S為slave,若M掛掉,則合理的處理方式是將S提升為master(通過SLAVE NO ONE命令)。當原來的master M恢複後,將M設定為S的slave。當然,實際處理方式並不限於這裡的建議。
c. 假設共3個節點,M為master,S1和S2均為slave,若M掛掉,合理的處理方式是將其中1個slave提升為master,同時,需將另一個slave的master重新設定為新的master執行個體。
現在,新問題來了:如何得知M已經掛掉了?
這就涉及到Redis的監控,所幸的是,我們可以藉助Redis官方發布的工具Redis Sentinel完成監控任務。
下篇筆記會說明sentinel的用法並討論實際使用中可能踩到的坑。
4、redis.conf中replication配置項說明