Redis哨兵模式（故障转移测试）
哨兵模式是在主备模式的基础上，加上哨兵，实现redis集群的故障转移。哨兵负责监控集群状态，当redis主节点发生故障，哨兵通过选举，选出替代的master节点。一般需要单数的哨兵进行选举，大多数达成一致。问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。
为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。
本文章针对这个问题做一下实验。
使用3+3模式，3redis+3sentinel。
三台虚拟机，每台虚拟机运行1个redis+1个sentinel
ip、角色规划
192.168.237.101：master，sentinel
192.168.237.100：slave，sentinel
192.168.237.103：slave，sentinel
安装redis、redis sentinel
apt-get install redis-server
apt-get install redis-sentinel
redis-server配置修改(/etc/redis/redis.conf)
redis-server slave配置修改
启动redis-server
/etc/init.d/redis-server restart
查看redis-server主从集群情况
修改sentinel配置(/etc/redis/sentinel.conf)
sentinel monitor mymaster 192.168.237.101 6379 2
sentinel known-slave mymaster 192.168.237.100 6379
protected-mode no
启动sentinel
/etc/init.d/redis-sentinel start
查看redis-sentinel情况
预期：故障转移，哨兵选举出新的master
关掉redis-server（192.168.237.101）
查看sentinel日志（/var/log/redis/redis-sentinel.log）
可以看到，+odown master，哨兵检测master客观下线
然后进行投票：vote-for-leader
选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379
192.168.237.101的sentinel日志：
查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）
恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave
预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完成故障转移。
经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server
查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：
查看redis集群状态，确认master（192.168.237.100）
预期：无法切换
依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master
查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票
恢复一个redis-sentinel，现有两个redis-sentinel
查看sentinel日志，选出101为master
有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。
+sdown：主观down机
+odown：客观down机
+new-epoch：集群递增版本号
+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader
+try-failover：开始对某ip进行故障转移
voted for：另一个哨兵进行投票
+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。
+selected-slave slave：选出leader
+failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。
+failover-state-wait-promotion slave：等待其它的sentinel确认slave
+promoted-slave slave：其它的sentinel全部确认成功
+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)
+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master
+switch-master：故障转移完毕后，各个sentinel开始监控新的master
绛旓細3銆侀泦缇妯″紡锛氬湪闆嗙兢妯″紡涓嬶紝鏁版嵁琚垎鐗囧瓨鍌ㄥ湪澶氫釜Redis鑺傜偣涓婏紝姣忎釜鑺傜偣閮借礋璐ｅ鐞嗕竴閮ㄥ垎鏁版嵁銆傞泦缇ゆā寮忓彲浠ュ疄鐜版按骞虫墿灞曪紝鎻愰珮绯荤粺鐨勫悶鍚愰噺鍜屽閿欐с傚綋鏌愪釜鑺傜偣鍑虹幇鏁呴殰鏃讹紝闆嗙兢浼氳嚜鍔ㄨ繘琛鏁呴殰杞Щ锛屽皢鏁版嵁閲嶆柊鍒嗛厤鍒板叾浠栧彲鐢ㄧ殑鑺傜偣涓娿傛澶栵紝闆嗙兢妯″紡杩樻敮鎸佸湪绾挎墿瀹瑰拰缂╁锛屽彲浠ユ柟渚垮湴璋冩暣闆嗙兢鐨勮妯°
绛旓細Redis闆嗙兢鏁呴殰杞Щ鐨勬柟娉曪細涓銆佹晠闅滄娴- 1.闆嗙兢涓墍鏈夎妭鐐归兘浼氬悜鍏跺畠鑺傜偣鍙戦丳ING娑堟伅,褰撳湪瑙勫畾鐨勬椂闂村唴,娌℃湁鏀跺埌瀵瑰簲鐨凱ONG娑堟伅,灏辨妸姝よ妭鐐规爣璁颁负鐤戜技涓嬬嚎锛- 2.鍦ㄥ彂閫佺殑PING娑堟伅閲岄潰,浼氬甫鐫褰撳墠闆嗙兢鍜岃妭鐐圭殑淇℃伅;閫氳繃杩欑鏂瑰紡,鍗冲彲妫娴嬭妭鐐圭殑瀛樻椿,鍙堣兘缁存姢闆嗙兢淇℃伅鐨勭粺涓鎬,涓嶈繃鏈変竴瀹氱殑鏃跺欢锛- 3....
绛旓細sentinal锛屼腑鏂囧悕鏄鍝ㄥ叺 鍝ㄥ叺鏄redis闆嗙兢鏋舵瀯涓潪甯搁噸瑕佺殑涓涓粍浠讹紝涓昏鍔熻兘濡備笅锛氾紙1锛夐泦缇ょ洃鎺э紝璐熻矗鐩戞帶redis master鍜宻lave杩涚▼鏄惁姝ｅ父宸ヤ綔 锛2锛夋秷鎭氱煡锛屽鏋滄煇涓猺edis瀹炰緥鏈夋晠闅滐紝閭ｄ箞鍝ㄥ叺璐熻矗鍙戦佹秷鎭綔涓烘姤璀﹂氱煡缁欑鐞嗗憳 锛3锛鏁呴殰杞Щ锛屽鏋渕aster node鎸傛帀浜嗭紝浼氳嚜鍔ㄨ浆绉诲埌slave node涓 ...
绛旓細娴嬭瘯鍝ㄥ叺妯″紡缁撴灉锛屽涓嬪浘锛1銆佸摠鍏甸泦缇わ紝鍩轰簬涓讳粠澶嶅埗妯″紡锛屾墍鏈夌殑涓讳粠閰嶇疆浼樼偣锛屽畠鍏ㄦ湁銆2銆佷富浠庡彲浠ュ垏鎹紝鏁呴殰鍙互杞Щ锛岀郴缁熺殑鍙敤鎬у氨浼氭洿濂姐3銆佸摠鍏垫ā寮忓氨鏄富浠庢ā寮忕殑鍗囩骇锛屾墜鍔ㄥ埌鑷姩锛屾洿鍔犲仴澹1銆侀泦缇ゅ閲忎竴鏃﹀埌杈句笂闄愶紝鍦ㄧ嚎鎵╁鍗佸垎楹荤儲銆2銆佸疄鐜板摠鍏垫ā寮忕殑閰嶇疆鍏跺疄鏄緢楹荤儲鐨勶紝閲岄潰鏈夊緢澶氶夋嫨...
绛旓細Redis鐨勫摠鍏鏈哄埗灏辨槸瑙ｅ喅涓讳粠澶嶅埗瀛樺湪缂洪櫡锛堥変妇闂锛夛紝瑙ｅ喅闂淇濊瘉鎴戜滑鐨凴edis楂樺彲鐢紝瀹炵幇鑷姩鍖栨晠闅滃彂鐜颁笌鏁呴殰杞Щ銆 瑕佷娇鐢ㄥ摠鍏垫満鍒讹紝闄や簡鍚姩Redis鏈嶅姟浠ュ锛岃繕瑕佸惎鍔ㄥ摠鍏垫湇鍔℃潵杩涜鐩戞帶锛屼細浠嬬粛璇︾粏姝ラ銆傚摠鍏垫湇鍔＄殑宸ヤ綔鍘熺悊濡備笅锛氭紨绀洪泦缇ら噰鐢1涓2浠庯紝閲囩敤浼泦缇わ紝鍦ㄤ竴鍙拌櫄鎷熸満涓惎鍔紝绔彛鏆傚畾6381銆...
绛旓細鍝ㄥ叺妯″紡鍏锋湁浠ヤ笅涓ょ鍚箟锛1. 鍝ㄥ叺妯″紡鐗规寚鐗规柉鎷夎溅涓诲彲瀹炴椂鏌ョ湅杞﹁韩鍥涘懆鎽勫儚澶寸殑瑙嗛淇℃伅锛屽綋杞﹁締琚鎾炴垨绉诲姩鏃讹紝澶栭儴鎽勫儚澶翠細褰曞埗杞﹁締鍛ㄥ洿鐨勭幆澧冿紝骞堕氳繃鎵嬫満APP/鐭俊閫氱煡杞︿富锛屽悓鏃跺湪杞︽満涓婁篃鍙互鏌ョ湅褰曞儚銆2. 鍝ㄥ叺妯″紡鏄垎甯冨紡绯荤粺涓洃鎺 redis 涓讳粠鏈嶅姟鍣ㄧ殑涓绉嶆満鍒讹紝鍏锋湁鐩戞帶銆佹彁閱掑拰鑷姩鏁呴殰杩佺Щ涓...
绛旓細鍝ㄥ叺妯″紡鍦ㄥ涓鍩熶腑鍙戞尌鐫鍏抽敭浣滅敤锛屾棬鍦ㄦ彁鍗囩郴缁熺殑绋冲畾鎬у拰瀹夊叏鎬с傚湪鐗规柉鎷夋苯杞︿腑锛屽摠鍏垫ā寮忓氨鍍忎竴涓24灏忔椂涓嶉棿鏂殑鐩戞帶绯荤粺锛岃溅杈嗗仠娉婃椂锛岄氳繃鍓嶈銆佷晶瑙嗗拰鍚庤鎽勫儚澶达紝鍙婃椂璁板綍浠讳綍鍙兘鐨勭鎾炴垨寮傚父绉诲姩锛岀‘淇濊溅涓绘棤闇鎷呭績杞﹁締琚伓鎰忓埉鎿︽垨鐩楃獌銆傛澶栵紝Redis鏁版嵁搴撶殑鍝ㄥ叺妯″紡鍒欐槸涓绉鏁呴殰杞Щ鏈哄埗锛...
绛旓細Sentinel杩涚▼鏄敤浜庣洃鎺edis闆嗙兢涓璏aster涓绘湇鍔″櫒宸ヤ綔鐨勭姸鎬侊紝鍦∕aster涓绘湇鍔″櫒鍙戠敓鏁呴殰鐨勬椂鍊欙紝鍙互瀹炵幇Master鍜孲lave鏈嶅姟鍣ㄧ殑鍒囨崲锛屼繚璇佺郴缁熺殑楂樺彲鐢紝鍏跺凡缁忚闆嗘垚鍦 redis2.6+鐨勭増鏈腑锛Redis鐨勫摠鍏垫ā寮鍒颁簡2.8鐗堟湰涔嬪悗灏辩ǔ瀹氫簡涓嬫潵銆備竴鑸湪鐢熶骇鐜涔熷缓璁娇鐢≧edis2.8浠ュ悗鐗堟湰銆傚摠鍏(Sentinel)鏄竴涓...
绛旓細鍚姩鏈嶅姟瑕佹寜鐓т富浠庨『搴忎緷娆″惎鍔ㄣ傛煡鐪嬫湇鍔″惎鍔ㄦ儏鍐碉細涔熷彲浠ラ氳繃鏌ョ湅鏃ュ織鏂囦欢鏉ョ‘璁ゆ湇鍔℃槸鍚︽甯稿惎鍔ㄣ傞氳繃瀹㈡埛绔櫥褰Redis楠岃瘉鏁版嵁鍚屾鎯呭喌锛氫富Redis鐧诲綍楠岃瘉锛岃缃暟鎹細浠嶳edis鐧诲綍锛岃幏鍙栨暟鎹細浠嶳edis骞舵病鏈夎缃瘑鐮侊紝鎵浠ユ棤闇楠岃瘉灏卞彲浠ユ搷浣溿傞厤缃鍝ㄥ叺妯″紡锛歊edis Sentinel闆嗙兢閫氬父鐢3鍒5涓妭鐐圭粍鎴愶紝濡傛灉涓埆...
绛旓細鍝ㄥ叺鏈哄埗鏄敤鏉ヨВ鍐充富浠庡悓姝aster瀹曟満鍚庣殑 鍔ㄦ佽嚜鍔ㄤ富浠庡垏鎹 闂銆 涓昏鏈変互涓嬩綔鐢 璇曟兂濡傛灉鐢ㄦ潵淇濋殰redis闆嗙兢楂樺彲鐢ㄧ殑鍝ㄥ叺鏄崟鏈虹殑,鐒跺悗鍝ㄥ叺鎸備簡,redis涔熸寕浜,杩檛m鏄綍绛 鍗фЫ? 鎵浠ュ摠鍏典篃鏄泦缇ょ殑,鎵鏈夋搷浣滈渶瑕佽繘琛屾姇绁ㄥ喅瀹氥 (1)鏁呴殰杞Щ鏃,鍒ゆ柇涓涓猰aster node鏄畷鏈轰簡,闇瑕佸ぇ閮ㄥ垎鐨勫摠鍏甸兘鍚屾剰鎵嶈,娑夊強鍒颁簡...
