redis-2.6.7のソースから。
まずはマスターから。
⇒マスターが終わったら、マスターからスレーブの情報を引っ張ってきてそいつらをチェック。
⇒次にマスターからsentinelの情報を引っ張ってきて、そいつらを。
⇒マスター、自分に接続してるsentinelの情報なんて持ってるんだね。
sentinel.c: sentinelHandleRedisInstanceの中で
1) コネクションが切れてたら再接続(sentinel.c: sentinelReconnectInstance)
2) INFOやPINGの打ち込み(sentinel.c: sentinelPingInstance)
3) PINGの戻りがPONG, LOADING, MASTERDOWNだったらlast_avail_timeを更新。
4) チェックしているマスターのステータスがSDOWN, FAILOVER_IN_PROGRESSだったら、他のsentinelにis-master-down-by-addrを投げて問い合わせる。これ、「このsentinelは自分のマスターがダウンしていると認識しているかどうか(=MASTERDOWN)」を判定して格納してるように見える(sentinel.c: sentinelAskMasterStateToOtherSentinels)
5) ここでSDOWNしているかどうかの判定関数を呼ぶ(sentinel.c: sentinelCheckSubjectivelyDown)
6) last_avail_timeと現在時刻の差がdown_after_millisecondsを超えていたらSDOWN判定。
7) 自分がSDOWNとしている場合、他のsentinelがSDOWNと判定しているかどうか問い合わせる。quorumの値を超えたらODOWNのステータスをつける(sentinel.c: sentinelCheckObjectivelyDown)
http://redis.io/topics/sentinel
PONG, LOADING, MASTERDOWN以外のレスポンスは無効でSDOWNに叩き落とされるのかと思ったら、
無効で無視されてlast_avail_timeが更新されない、という動作だった。
なんでSDOWN判定されたのかをログに吐かせたくて色々読んだんだけれども、
そもそもSDOWN判定ではlast_avail_timeと現在時刻の差しか見てなくて、
PINGのレスポンスを受け取るところは結構前の段階なのでどうしようか考えちゅう。
5) ここでSDOWNしているかどうかの判定関数を呼ぶ(sentinel.c: sentinelCheckSubjectivelyDown)
6) last_avail_timeと現在時刻の差がdown_after_millisecondsを超えていたらSDOWN判定。
7) 自分がSDOWNとしている場合、他のsentinelがSDOWNと判定しているかどうか問い合わせる。quorumの値を超えたらODOWNのステータスをつける(sentinel.c: sentinelCheckObjectivelyDown)
http://redis.io/topics/sentinel
PONG, LOADING, MASTERDOWN以外のレスポンスは無効でSDOWNに叩き落とされるのかと思ったら、
無効で無視されてlast_avail_timeが更新されない、という動作だった。
なんでSDOWN判定されたのかをログに吐かせたくて色々読んだんだけれども、
そもそもSDOWN判定ではlast_avail_timeと現在時刻の差しか見てなくて、
PINGのレスポンスを受け取るところは結構前の段階なのでどうしようか考えちゅう。
0 件のコメント :
コメントを投稿