FAQ
Hi,

there's the document http://redis.io/topics/cluster-spec about Redis
Cluster specs -- AFAICS there's neither a time stamp, nor any kind of
version of this document.

As Redis 2.6 was released recently, I'm pretty excited what* *the *current* state
on this issues is?

Thanks in advance.

Best,

Timo

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/y-3k1fUX9LQJ.
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

  • Jisoo Park at Nov 1, 2012 at 6:46 pm
    You can see them on Github.

    https://github.com/antirez/redis/issues/search?q=cluster Issues containing
    'cluster'

    https://github.com/antirez/redis/issues?milestone=2&state=open 3.0 Milestone

    On Wednesday, October 31, 2012 3:17:49 AM UTC+9, Timo Schoeler wrote:

    Hi,

    there's the document http://redis.io/topics/cluster-spec about Redis
    Cluster specs -- AFAICS there's neither a time stamp, nor any kind of
    version of this document.

    As Redis 2.6 was released recently, I'm pretty excited what* *the *current
    * state on this issues is?

    Thanks in advance.

    Best,

    Timo
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/YxVAeNqNSLsJ.
    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.
  • Timo Schoeler at Nov 1, 2012 at 6:51 pm
    Thanks a lot, that was right what I was searching for!

    Best,

    Timo

    Am Donnerstag, 1. November 2012 15:51:26 UTC+1 schrieb Jisoo Park:
    You can see them on Github.

    https://github.com/antirez/redis/issues/search?q=cluster Issues
    containing 'cluster'

    https://github.com/antirez/redis/issues?milestone=2&state=open 3.0
    Milestone

    On Wednesday, October 31, 2012 3:17:49 AM UTC+9, Timo Schoeler wrote:

    Hi,

    there's the document http://redis.io/topics/cluster-spec about Redis
    Cluster specs -- AFAICS there's neither a time stamp, nor any kind of
    version of this document.

    As Redis 2.6 was released recently, I'm pretty excited what* *the *
    current* state on this issues is?

    Thanks in advance.

    Best,

    Timo
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/Hpj__aXRRGkJ.
    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 Nov 1, 2012 at 6:55 pm

    On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler wrote:
    Hi,

    there's the document http://redis.io/topics/cluster-spec about Redis Cluster
    specs -- AFAICS there's neither a time stamp, nor any kind of version of
    this document.

    As Redis 2.6 was released recently, I'm pretty excited what the current
    state on this issues is?
    Hello Timo,

    the Redis Cluster specification is not really a "specification" in the
    proper strict sense as "get me the specification, I can implement it".
    There are a number of holes that must be filled, not much, but the
    evil is in the details.

    A lot of those unspecified points are actually sometimes *already*
    implemented in the unstable branch, other are discussed, and a lot
    more will be simply discovered as the implementation gets more
    complete / mature.

    So what we have *for now* in the unstable branch about Cluster?

    1) Gossip to propagate information about the cluster, to link every
    node with each other.
    2) Gossip to propagate information about what node is responsible for
    what hash slot.
    3) Redirections. Node can redirect you to the right node if you ask a
    question they can't reply to.
    4) Atomic keys migration, that is the base of the resharding.
    5) Failure detection. It is possible that this will get reworked using
    experiences from Sentinel. Sentinel failure detection is probably
    better already.
    6) The user space tool to manage the cluster is a work in progress,
    but can already do a "toy resharding" operation.

    So that's the current state, but the good news is, Cluster and
    Sentinel will be my main goals in the next months, and I want to bring
    Cluster to beta-quality ASAP. I'll focus a lot into it because at this
    point with Redis 2.6 we have a project that's pretty mature compared
    to the past, and I can't see other big features apart form Sentinel
    and Cluster to say, ok, let's block the development of these two
    features and get XYZ ready instead. I'm also pretty confident we'll
    stick with our single-thread-serves-all design for time to come, and
    use Cluster to distribute Redis when there is need to use multiple
    cores. Basically this means that in the Redis philosophy the approach
    could be "another core or another computer for me is the same". I can
    change idea, but *after* I'll see how Cluster will perform in this
    regard :-)

    Cheers,
    Salvatore

    --
    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.
  • Timo Schoeler at Nov 1, 2012 at 8:05 pm
    Thanks a lot, Salvatore, that did quite shed some light on open questions
    of mine. I appreciate your answer very much!

    Best,

    Timo

    Am Donnerstag, 1. November 2012 19:55:48 UTC+1 schrieb Salvatore Sanfilippo:
    On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler
    <timothy....@googlemail.com <javascript:>> wrote:
    Hi,

    there's the document http://redis.io/topics/cluster-spec about Redis Cluster
    specs -- AFAICS there's neither a time stamp, nor any kind of version of
    this document.

    As Redis 2.6 was released recently, I'm pretty excited what the current
    state on this issues is?
    Hello Timo,

    the Redis Cluster specification is not really a "specification" in the
    proper strict sense as "get me the specification, I can implement it".
    There are a number of holes that must be filled, not much, but the
    evil is in the details.

    A lot of those unspecified points are actually sometimes *already*
    implemented in the unstable branch, other are discussed, and a lot
    more will be simply discovered as the implementation gets more
    complete / mature.

    So what we have *for now* in the unstable branch about Cluster?

    1) Gossip to propagate information about the cluster, to link every
    node with each other.
    2) Gossip to propagate information about what node is responsible for
    what hash slot.
    3) Redirections. Node can redirect you to the right node if you ask a
    question they can't reply to.
    4) Atomic keys migration, that is the base of the resharding.
    5) Failure detection. It is possible that this will get reworked using
    experiences from Sentinel. Sentinel failure detection is probably
    better already.
    6) The user space tool to manage the cluster is a work in progress,
    but can already do a "toy resharding" operation.

    So that's the current state, but the good news is, Cluster and
    Sentinel will be my main goals in the next months, and I want to bring
    Cluster to beta-quality ASAP. I'll focus a lot into it because at this
    point with Redis 2.6 we have a project that's pretty mature compared
    to the past, and I can't see other big features apart form Sentinel
    and Cluster to say, ok, let's block the development of these two
    features and get XYZ ready instead. I'm also pretty confident we'll
    stick with our single-thread-serves-all design for time to come, and
    use Cluster to distribute Redis when there is need to use multiple
    cores. Basically this means that in the Redis philosophy the approach
    could be "another core or another computer for me is the same". I can
    change idea, but *after* I'll see how Cluster will perform in this
    regard :-)

    Cheers,
    Salvatore

    --
    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 view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/HMOFd9rFdIQJ.
    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.
  • Timo Schoeler at Nov 2, 2012 at 11:58 am
    Hi again, however, I'm still searching for kind of 'matrix' to see what
    features are really implemented and 'production ready' in 2.6...

    Cheers,

    Timo

    Am Donnerstag, 1. November 2012 21:05:09 UTC+1 schrieb Timo Schoeler:
    Thanks a lot, Salvatore, that did quite shed some light on open questions
    of mine. I appreciate your answer very much!

    Best,

    Timo

    Am Donnerstag, 1. November 2012 19:55:48 UTC+1 schrieb Salvatore
    Sanfilippo:
    On Tue, Oct 30, 2012 at 7:17 PM, Timo Schoeler
    wrote:
    Hi,

    there's the document http://redis.io/topics/cluster-spec about Redis Cluster
    specs -- AFAICS there's neither a time stamp, nor any kind of version of
    this document.

    As Redis 2.6 was released recently, I'm pretty excited what the current
    state on this issues is?
    Hello Timo,

    the Redis Cluster specification is not really a "specification" in the
    proper strict sense as "get me the specification, I can implement it".
    There are a number of holes that must be filled, not much, but the
    evil is in the details.

    A lot of those unspecified points are actually sometimes *already*
    implemented in the unstable branch, other are discussed, and a lot
    more will be simply discovered as the implementation gets more
    complete / mature.

    So what we have *for now* in the unstable branch about Cluster?

    1) Gossip to propagate information about the cluster, to link every
    node with each other.
    2) Gossip to propagate information about what node is responsible for
    what hash slot.
    3) Redirections. Node can redirect you to the right node if you ask a
    question they can't reply to.
    4) Atomic keys migration, that is the base of the resharding.
    5) Failure detection. It is possible that this will get reworked using
    experiences from Sentinel. Sentinel failure detection is probably
    better already.
    6) The user space tool to manage the cluster is a work in progress,
    but can already do a "toy resharding" operation.

    So that's the current state, but the good news is, Cluster and
    Sentinel will be my main goals in the next months, and I want to bring
    Cluster to beta-quality ASAP. I'll focus a lot into it because at this
    point with Redis 2.6 we have a project that's pretty mature compared
    to the past, and I can't see other big features apart form Sentinel
    and Cluster to say, ok, let's block the development of these two
    features and get XYZ ready instead. I'm also pretty confident we'll
    stick with our single-thread-serves-all design for time to come, and
    use Cluster to distribute Redis when there is need to use multiple
    cores. Basically this means that in the Redis philosophy the approach
    could be "another core or another computer for me is the same". I can
    change idea, but *after* I'll see how Cluster will perform in this
    regard :-)

    Cheers,
    Salvatore

    --
    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 view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/El3_F01fFSsJ.
    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 Nov 2, 2012 at 12:03 pm

    On Fri, Nov 2, 2012 at 12:58 PM, Timo Schoeler wrote:

    Hi again, however, I'm still searching for kind of 'matrix' to see what
    features are really implemented and 'production ready' in 2.6...
    In 2.6 there is almost no cluster, with the exception of the following commands:

    DUMP, MIGRATE, RESTORE, that are inside 2.6 and are production ready.

    Cheers,
    Salvatore

    --
    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.
  • Timo Schoeler at Nov 2, 2012 at 12:05 pm
    Hi,

    wow, that was a very fast reply...

    Okay, thanks for that information.

    Cheers,

    Timo

    Am Freitag, 2. November 2012 13:03:47 UTC+1 schrieb Salvatore Sanfilippo:
    On Fri, Nov 2, 2012 at 12:58 PM, Timo Schoeler
    <timothy....@googlemail.com <javascript:>> wrote:
    Hi again, however, I'm still searching for kind of 'matrix' to see what
    features are really implemented and 'production ready' in 2.6...
    In 2.6 there is almost no cluster, with the exception of the following
    commands:

    DUMP, MIGRATE, RESTORE, that are inside 2.6 and are production ready.

    Cheers,
    Salvatore

    --
    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 view this discussion on the web visit https://groups.google.com/d/msg/redis-db/-/wcCAei70rXQJ.
    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 30, '12 at 6:42p
activeNov 2, '12 at 12:05p
posts8
users3
websiteredis.io
irc#redis

People

Translate

site design / logo © 2022 Grokbase