FAQ
Is there any "clever" way of detecting a readonly slave?

I can't see anything under "info replication", making me think my best bet
is a setex against a random guid and detect the READONLY, but... that's a
bit ugly.

Is there a better way of checking this?

Also: I notice that PUBLISH still works on a readonly slave - intentional?
(part of sentinel maybe?) It just seems odd that someone listening to a
slave could get different (more) messages than someone listening to the
master...

Regards,

Marc

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redis-db@googlegroups.com.
To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

Search Discussions

  • Dvir Volk at Oct 22, 2012 at 2:08 pm
    maybe this is more "clever"?

    redis 127.0.0.1:6379> config get slave-read-only
    1) "slave-read-only"
    2) "yes"


    but IMHO it should appear in the INFO.

    On Mon, Oct 22, 2012 at 3:54 PM, Marc Gravell wrote:

    Is there any "clever" way of detecting a readonly slave?

    I can't see anything under "info replication", making me think my best bet
    is a setex against a random guid and detect the READONLY, but... that's a
    bit ugly.

    Is there a better way of checking this?

    Also: I notice that PUBLISH still works on a readonly slave - intentional?
    (part of sentinel maybe?) It just seems odd that someone listening to a
    slave could get different (more) messages than someone listening to the
    master...

    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Dvir Volk
    Chief Architect, Everything.me
    http://everything.me

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
  • Marc Gravell at Oct 22, 2012 at 2:19 pm
    That's helpful, thanks. It will have to be *combined* with "info" though,
    as "config get slave-read-only" returns "yes" even for masters, so I'll
    need to combine with the "role" from "info replication".

    I would agree that this should be available in "info replication", perhaps
    only when it is in slave mode (like a number of other values that
    appear/not depending on the role)

    Ta,

    Marc
    On 22 October 2012 15:08, Dvir Volk wrote:

    maybe this is more "clever"?

    redis 127.0.0.1:6379> config get slave-read-only
    1) "slave-read-only"
    2) "yes"


    but IMHO it should appear in the INFO.

    On Mon, Oct 22, 2012 at 3:54 PM, Marc Gravell wrote:

    Is there any "clever" way of detecting a readonly slave?

    I can't see anything under "info replication", making me think my best
    bet is a setex against a random guid and detect the READONLY, but... that's
    a bit ugly.

    Is there a better way of checking this?

    Also: I notice that PUBLISH still works on a readonly slave -
    intentional? (part of sentinel maybe?) It just seems odd that someone
    listening to a slave could get different (more) messages than someone
    listening to the master...

    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Dvir Volk
    Chief Architect, Everything.me
    http://everything.me

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
  • Salvatore Sanfilippo at Oct 22, 2012 at 5:29 pm
    Hey! Field added in INFO with commit 99d7dbe

    Thanks,
    Salvatore
    On Mon, Oct 22, 2012 at 3:54 PM, Marc Gravell wrote:
    Is there any "clever" way of detecting a readonly slave?

    I can't see anything under "info replication", making me think my best bet
    is a setex against a random guid and detect the READONLY, but... that's a
    bit ugly.

    Is there a better way of checking this?

    Also: I notice that PUBLISH still works on a readonly slave - intentional?
    (part of sentinel maybe?) It just seems odd that someone listening to a
    slave could get different (more) messages than someone listening to the
    master...

    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Salvatore 'antirez' Sanfilippo
    open source developer - VMware
    http://invece.org

    Beauty is more important in computing than anywhere else in technology
    because software is so complicated. Beauty is the ultimate defence
    against complexity.
    — David Gelernter

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
  • Marc Gravell at Oct 22, 2012 at 7:52 pm
    Confirmed against "unstable" (and I checked the multi/exec fix too)

    Thanks,

    Marc
    On 22 October 2012 18:23, Salvatore Sanfilippo wrote:

    Hey! Field added in INFO with commit 99d7dbe

    Thanks,
    Salvatore
    On Mon, Oct 22, 2012 at 3:54 PM, Marc Gravell wrote:
    Is there any "clever" way of detecting a readonly slave?

    I can't see anything under "info replication", making me think my best bet
    is a setex against a random guid and detect the READONLY, but... that's a
    bit ugly.

    Is there a better way of checking this?

    Also: I notice that PUBLISH still works on a readonly slave -
    intentional?
    (part of sentinel maybe?) It just seems odd that someone listening to a
    slave could get different (more) messages than someone listening to the
    master...

    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Salvatore 'antirez' Sanfilippo
    open source developer - VMware
    http://invece.org

    Beauty is more important in computing than anywhere else in technology
    because software is so complicated. Beauty is the ultimate defence
    against complexity.
    — David Gelernter

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.

    --
    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
  • Salvatore Sanfilippo at Oct 22, 2012 at 7:21 pm
    Thank you for the ACK Marc!

    Salvatore
    On Mon, Oct 22, 2012 at 9:20 PM, Marc Gravell wrote:
    Confirmed against "unstable" (and I checked the multi/exec fix too)

    Thanks,

    Marc

    On 22 October 2012 18:23, Salvatore Sanfilippo wrote:

    Hey! Field added in INFO with commit 99d7dbe

    Thanks,
    Salvatore

    On Mon, Oct 22, 2012 at 3:54 PM, Marc Gravell <marc.gravell@gmail.com>
    wrote:
    Is there any "clever" way of detecting a readonly slave?

    I can't see anything under "info replication", making me think my best
    bet
    is a setex against a random guid and detect the READONLY, but... that's
    a
    bit ugly.

    Is there a better way of checking this?

    Also: I notice that PUBLISH still works on a readonly slave -
    intentional?
    (part of sentinel maybe?) It just seems odd that someone listening to a
    slave could get different (more) messages than someone listening to the
    master...

    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google
    Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Salvatore 'antirez' Sanfilippo
    open source developer - VMware
    http://invece.org

    Beauty is more important in computing than anywhere else in technology
    because software is so complicated. Beauty is the ultimate defence
    against complexity.
    — David Gelernter

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Regards,

    Marc

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to
    redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/redis-db?hl=en.


    --
    Salvatore 'antirez' Sanfilippo
    open source developer - VMware
    http://invece.org

    Beauty is more important in computing than anywhere else in technology
    because software is so complicated. Beauty is the ultimate defence
    against complexity.
    — David Gelernter

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To post to this group, send email to redis-db@googlegroups.com.
    To unsubscribe from this group, send email to redis-db+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupredis-db @
categoriesredis
postedOct 22, '12 at 2:03p
activeOct 22, '12 at 7:52p
posts6
users3
websiteredis.io
irc#redis

People

Translate

site design / logo © 2022 Grokbase