How to know master/slave status of redis?

Question

How to know status of redis from command line (redis-cli) ? master/slave

Lanark

Answer 1

The INFO command returns the current role.

e.g/ if we're the master

role:master

will be shown, amongst other details.

And if we switch to a slave, maybe by using slaveof:

slaveof 192.168.1.66 6379

We get more, when we run INFO:

role:slave
master_host:192.168.1.66
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
master_link_down_since_seconds:1341313174

EDIT: Here's a succinct cli command as shown by Linus (but who's just deleted his post):

redis-cli info | grep ^role

:)

Lithophyte

Since the info command returns a lot of information, you can use info replication to return only replication status information. – Miseno

@Lithophyte How do I find the master's name, which could be used in sentinel configuration? – Dagall

@Dagall The master name is a logical one: you choose it yourself. I give you that it's not completely clear by reading redis.io/docs/management/sentinel/#configuring-sentinel. – Voidable

Answer 2

I want to expand on the answer above by providing status meanings in a distributed setup

# get sentinel / redis instance role of remote host:
› redis-cli -h redis-02.a_slave -p 6379 info|grep role 
role:slave

# get sentinel status of remote host:
› redis-cli -h redis-01.a_sentinel -p 26379 info|grep status
master0:name=mymaster,status=ok,address=172.xx.xxx.xx:6379,slaves=2,sentinels=3    

statuses

http://redis.io/topics/sentinel#pubsub-messages

• +reset-master <instance details> -- The master was reset.
• +slave <instance details> -- A new slave was detected and attached.
• +failover-state-reconf-slaves <instance details> -- Failover state changed to reconf-slaves state.
• +failover-detected <instance details> -- A failover started by another Sentinel or any other external entity was detected (An attached slave turned into a master).
• +slave-reconf-sent <instance details> -- The leader sentinel sent the SLAVEOF command to this instance in order to reconfigure it for the new slave.
• +slave-reconf-inprog <instance details> -- The slave being reconfigured showed to be a slave of the new master ip:port pair, but the synchronization process is not yet complete.
• +slave-reconf-done <instance details> -- The slave is now synchronized with the new master.
• -dup-sentinel <instance details> -- One or more sentinels for the specified master were removed as duplicated (this happens for instance when a Sentinel instance is restarted).
• +sentinel <instance details> -- A new sentinel for this master was detected and attached.
• +sdown <instance details> -- The specified instance is now in Subjectively Down state.
• -sdown <instance details> -- The specified instance is no longer in Subjectively Down state.
• +odown <instance details> -- The specified instance is now in Objectively Down state.
• -odown <instance details> -- The specified instance is no longer in Objectively Down state.
• +new-epoch <instance details> -- The current epoch was updated.
• +try-failover <instance details> -- New failover in progress, waiting to be elected by the majority.
• +elected-leader <instance details> -- Won the election for the specified epoch, can do the failover.
• +failover-state-select-slave <instance details> -- New failover state is select-slave: we are trying to find a suitable slave for promotion.
• no-good-slave <instance details> -- There is no good slave to promote. Currently we'll try after some time, but probably this will change and the state machine will abort the failover at all in this case.
• selected-slave <instance details> -- We found the specified good slave to promote.
• failover-state-send-slaveof-noone <instance details> -- We are trying to reconfigure the promoted slave as master, waiting for it to switch.
• failover-end-for-timeout <instance details> -- The failover terminated for timeout, slaves will eventually be configured to replicate with the new master anyway.
• failover-end <instance details> -- The failover terminated with success. All the slaves appears to be reconfigured to replicate with the new master.
• switch-master <master name> <oldip> <oldport> <newip> <newport> -- The master new IP and address is the specified one after a configuration change. This is the message most external users are interested in.
• +tilt -- Tilt mode entered.
• -tilt -- Tilt mode exited.

Pittance

Answer 3

By using a very simple and direct query for the role:

redis-cli -p 7000 role

1) "master"
2) (integer) 497098
3) 1) 1) "127.0.0.1"
      2) "7004"
      3) "497098"
   2) 1) "127.0.0.1"
      2) "7006"
      3) "497098"

Replace the port 7000 in the command with the Redis server's actual port.

In the above output, the 2 follower instances are the 2 slaves at ports 7004 and 7006 in my setup.

Dagall