I am running 3 Sentinels and Redis Master/Slave. Version 2.6.10
And Redis properties are the same as master/slave.

Under normal circumstances, sometimes the Sentinel will trigger a sdown alarm.

It is included in the same private band, so it does not go through firewalls or L3 devices.
In addition, no special issues occurred in the network communication side.

What is suspicious is that the "Aof Fsync is taking too long" log is recorded during AOF in Redis.

Could this affect the ping-pong and sdown alarms between Sentinel and Redis? Or could it affect the sentinel's sdown if Redis is busy? (For example, a large number of expires work in Redis..)

redis master/slave conf

daemonize yes
syslog-enabled yes

databases 1

save 900 1
save 300 10
save 60 10000

dir /var/lib/redis/

appendonly yes
auto-aof-rewrite-min-size 64mb

maxmemory-policy noeviction

requirepass p@ssword
masterauth p@ssword

#rename-command CONFIG __CONFIG__
rename-command DEBUG ""
rename-command SHUTDOWN __SHUTDOWN__
rename-command FLUSHDB ""
rename-command FLUSHALL ""

sentinel conf

port 26379
daemonize yes
tcp-keepalive 60
pidfile /var/run/redis/sentinel.pid
logfile /var/log/redis/sentinel.log

sentinel monitor mymaster 192.168.0.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel can-failover mymasteryes
sentinel auth-pass mymaster p@ssword

redis config get 

 81) "aof-rewrite-incremental-fsync"
 82) "yes"

 83) "appendonly"
 84) "yes"

 89) "appendfsync"
 90) "everysec"

redis log

...
[38750] 24 Feb 09:48:49.097 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
[38750] 24 Feb 09:48:57.006 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
[38750] 24 Feb 09:49:04.012 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

sentinel log

+sdown slave 192.168.0.101:6379 192.168.0.101 6379 @ mymaster 192.168.0.100 6379

Comment From: yossigo

@dalzzing2 sdown indicates a Sentinel instance has determined that a Redis instance is down after not responding in time, and the Redis logs you included provide a hint why this is happening (Disk IO becoming a bottleneck or experiencing some issue).

BTW you're using a version that is >7 years old, consider upgrading.

Comment From: hwware

Hi @dalzzing2, In addition to what @yossigo mentioned, I noticed your configuration down-after-milliseconds has been set to 5s (default is 30s). You can also consider to set a bigger value in order to avoid the +sdown state, but from your description the main reason of this is either because redis server is busy or the slow disk io. thanks!

Comment From: oranagra

question was answered. feel free to reopen or respond if needed.

Comment From: dalzzing2

I missed answering. thank you for the reply. It was very helpful and I was able to fix it.