注意:在master-slave部署模式下,只需slave實(shí)例配置Peplication相關(guān)項(xiàng),各項(xiàng)含義說(shuō)明如下。
1) slaveof
slave實(shí)例需要配置該項(xiàng),指向master的(ip, port)。
2) masterauth
如果master實(shí)例啟用了密碼保護(hù),則該配置項(xiàng)需填master的啟動(dòng)密碼;若master未啟用密碼,該配置項(xiàng)需要注釋掉
3) slave-serve-stale-data
指定slave與master連接中斷時(shí)的動(dòng)作。默認(rèn)為yes,表明slave會(huì)繼續(xù)應(yīng)答來(lái)自client的請(qǐng)求,但這些數(shù)據(jù)可能已經(jīng)過(guò)期(因?yàn)檫B接中斷導(dǎo)致無(wú)法從master同步)。若配置為no,則slave除正常應(yīng)答"INFO"和"SLAVEOF"命令外,其余來(lái)自客戶端的請(qǐng)求命令均會(huì)得到"SYNC with master in progress"的應(yīng)答,直到該slave與master的連接重建成功或該slave被提升為master。
4) slave-read-only
指定slave是否只讀,默認(rèn)為yes。若配置為no,這表示slave是可寫(xiě)的,但寫(xiě)的內(nèi)容在主從同步完成后會(huì)被刪掉。
5) repl-ping-slave-period
redis部署為Replication模式后,slave會(huì)以預(yù)定周期(默認(rèn)10s)發(fā)PING包給master,該配置可以更改這個(gè)默認(rèn)周期。
6) repl-timeout
有2種情況的超時(shí)均由該配置指定:1) Bulk transfer I/O timeout; 2) master data or ping response timeout。
需要特別注意的是:若修改默認(rèn)值,則用戶輸入的值必須大于repl-ping-slave-period的配置值,否則在主從鏈路延時(shí)較高時(shí),會(huì)頻繁timeout。
7) repl-disable-tcp-nodelay
指定向slave同步數(shù)據(jù)時(shí),是否禁用socket的NO_DELAY選項(xiàng)。若配置為yes,則禁用NO_DELAY,則TCP協(xié)議棧會(huì)合并小包統(tǒng)一發(fā)送,這樣可以減少主從節(jié)點(diǎn)間的包數(shù)量并節(jié)省帶寬,但會(huì)增加數(shù)據(jù)同步到slave的時(shí)間。若配置為no,表明啟用NO_DELAY,則TCP協(xié)議棧不會(huì)延遲小包的發(fā)送時(shí)機(jī),這樣數(shù)據(jù)同步的延時(shí)會(huì)減少,但需要更大的帶寬。通常情況下,應(yīng)該配置為no以降低同步延時(shí),但在主從節(jié)點(diǎn)間網(wǎng)絡(luò)負(fù)載已經(jīng)很高的情況下,可以配置為yes。
備注:socket的NO_DELAY選項(xiàng)涉及到TCP協(xié)議棧的擁塞控制算法—Nagle's Algorithm。
8) slave-priority
指定slave的優(yōu)先級(jí)。在不只1個(gè)slave存在的部署環(huán)境下,當(dāng)master宕機(jī)時(shí),Redis Sentinel會(huì)將priority值最小的slave提升為master。需要注意的是,若該配置項(xiàng)為0,則對(duì)應(yīng)的slave永遠(yuǎn)不會(huì)被Redis Sentinel自動(dòng)提升為master。
創(chuàng)新互聯(lián)公司于2013年成立,是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司,擁有項(xiàng)目成都網(wǎng)站建設(shè)、成都網(wǎng)站制作網(wǎng)站策劃,項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命,1280元阿拉山口做網(wǎng)站,已為上家服務(wù),為阿拉山口各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:028-86922220
關(guān)于Replication,需要明確的幾點(diǎn)(以下內(nèi)容主要總結(jié)自這里):
a. Redis的Replication跟cluster的概念不同。假如S是M的slave,則M不能把自己設(shè)置成為S的slave。若S掛掉,則M正常工作;相反,若M掛掉,則S可能會(huì)停止正常工作,這里用"可能",是因?yàn)镾的具體行為由其配置文件中的slave-serve-stale-data來(lái)決定。
b 假設(shè)共2個(gè)節(jié)點(diǎn),M為master,S為slave,若M掛掉,則合理的處理方式是將S提升為master(通過(guò)SLAVE NO ONE命令)。當(dāng)原來(lái)的master M恢復(fù)后,將M設(shè)置為S的slave。當(dāng)然,實(shí)際處理方式并不限于這里的建議。
c. 假設(shè)共3個(gè)節(jié)點(diǎn),M為master,S1和S2均為slave,若M掛掉,合理的處理方式是將其中1個(gè)slave提升為master,同時(shí),需將另一個(gè)slave的master重新設(shè)置為新的master實(shí)例。
現(xiàn)在,新問(wèn)題來(lái)了:如何得知M已經(jīng)掛掉了?
這就涉及到Redis的監(jiān)控,所幸的是,我們可以借助Redis官方發(fā)布的工具Redis Sentinel完成監(jiān)控任務(wù)。
下篇筆記會(huì)說(shuō)明sentinel的用法并討論實(shí)際使用中可能踩到的坑。