下面我们接着恢复26上面的6379 redis，这时候27的6380是master，26的6380和27的6379作为slave链接到master上面。26执行如下命令：
redis-server redis_6379.conf
sentinel日志如下：
这时候我们在27上看看6379和6380的信息：
redis-cli -p 6379 info Replication
redis-cli -p 6380 info Replication
效果如下：
可以看到新恢复的26的6379并没有恢复到master，而是作为新的slave链接到现有的master上面。
sentinel.conf详解
#sentinel实例监听的端口
port 26379
#告诉sentinel监控这个名为mymaster的master，它的监听地址是127.0.0.1，并且设置failing sentinel为2，表示当有2台sentinel探测到该实例失败时，该实例进入O_DOWN状态。
sentinel monitor mymaster 127.0.0.1 6379 2
#redis实例多少毫秒不可达sentinel，sentinel则认为该实例的状态转变为S_DOWN，但是这个状态还不足以启动automatic failover机制。只有足够多的实例认为该实例是S_DOWN状态，这时该实例进入O_DOWN状态，
sentinel down-after-milliseconds mymaster 30000
#在sentinel检测到O_DOWN后，是否对这台redis启动failover机制
sentinel can-failover mymaster yes
#在failover时，我们可以设置允许多少slave同时可以连接新的master。该值越低，完成failover的进程花费的时间越多，如果对从数据要求不是很及时，你可能不需要所有的从在同一时间同步到新的主（同步到新主，意味着数据重传），你确定在宕机时只有一个从可达则设置为1（如果这样的话其它的从还能用老的数据来干活
sentinel parallel-syncs mymaster 1
#设置failover的超时时间是多少毫秒
sentinel failover-timeout mymaster 900000
redis sentinel在监控redis实例时有两种redis宕机状态S_DOWN和O_DOWN：
S_DOWN:当sentinel在指定的超时时间内没有收到一个正确的ping回复值，则认为是S_DOWN
O_DOWN:O_DOWN的条件是有足够多的sentinel认为该redis实例是S_DOWN。
注意：O_DOWN只能是发生在主服务器，sentinel和其他从服务器不会发生O_DOWN
上面只是简单的试用，sentinel还没合并进稳定版本中，大家可以尝试试用。