Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis cluster, no longer vaporware

antirez.com

Post reply on HN
Print view View original

11–20 of 52 posts

Re: Redis cluster, no longer vaporware

#11

Post by seiji »

mfenniak wrote: post #6
chrisan wrote: post #3

Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...

I have very little evidence to support this, but they probably use twemproxy. twemproxy is a proxy for redis that automatically manages routing commands to multiple redis servers efficiently. They definitely don't use redis cluster, because redis cluster requires explicit client-side support. That support is only available in a limited number of clients today.

Nope, they don't (and neither should anybody else... twemproxy is weird).

Re: Redis cluster, no longer vaporware

#12

Post by [deleted] »

rem7 wrote: post #7
chrisan wrote: post #3

Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...

If I remember correctly they only have read replicas. I don't think they even have proper Fail over. You manually have to promote one of the read replicas to master... Feel free to correct me :)

[deleted]

Re: Redis cluster, no longer vaporware

#13

Post by jabo »

rem7 wrote: post #7
chrisan wrote: post #3

Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...

If I remember correctly they only have read replicas. I don't think they even have proper Fail over. You manually have to promote one of the read replicas to master... Feel free to correct me :)

No, they do have automatic failover to your hot standby via Replication Groups.

Re: Redis cluster, no longer vaporware

#14

Post by swartkrans »

jrallison wrote: post #8
ryanpetrich wrote: post #2

Can't wait to see it get the Jepsen treatment.

It won't do well, but at least Antirez is up front about the shortcomings. The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).

Seems like given the above problems you would only want to use this with non-critical data of which you didn't care a great deal about its integrity. This doesn't describe a lot of use cases.

It's not too hard to get memcached running for cluster of machines, nor is it really all that difficult to get started with cassandra for basic applications, although I haven't done it. I've heard ReThinkDB wants to be a serious contender and that they've tried to solve these problems, but I haven't read about how great it is nor have I heard anyone use it in production so I don't know where it stands.

Re: Redis cluster, no longer vaporware

#15

Post by antirez »

swartkrans wrote: post #14
jrallison wrote: post #8

Earlier quoted context omitted.

It won't do well, but at least Antirez is up front about the shortcomings. The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).

Seems like given the above problems you would only want to use this with non-critical data of which you didn't care a great deal about its integrity. This doesn't describe a lot of use cases. It's not too hard to get memcached running for cluster of machines, nor is it really all that difficult to get started with cassandra for basic applications, although I haven't done it. I've heard ReThinkDB wants to be a serious…

Note that systems with asynchronous replication and normal failover procedures are all subject to the same rules as Redis Cluster, and I believe there is a great deal of people running RDBMs in this setup. So IMHO actually there are a lot of use cases.

Re: Redis cluster, no longer vaporware

#16

Post by seiji »

swartkrans wrote: post #14
jrallison wrote: post #8

Earlier quoted context omitted.

It won't do well, but at least Antirez is up front about the shortcomings. The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).

Seems like given the above problems you would only want to use this with non-critical data of which you didn't care a great deal about its integrity. This doesn't describe a lot of use cases. It's not too hard to get memcached running for cluster of machines, nor is it really all that difficult to get started with cassandra for basic applications, although I haven't done it. I've heard ReThinkDB wants to be a serious…

This doesn't describe a lot of use cases.

Do you have any idea how many people run master/slave mysql? That's async and will definitely give you data drift over time. There's an entire suite of Percona tools to detect and repair broken mysql datasets because mysql breaks data so often due to replication problems.

The world is much more async and much less consistent than anybody realizes (cash machines are even async), but everything still works pretty much okay. The last line of defense for solving irreconcilable consistency problems is customer service.

Re: Redis cluster, no longer vaporware

#18

Post by jbinto »

ryanpetrich wrote: post #2

Can't wait to see it get the Jepsen treatment.

I didn't get the context, so I looked it up:

http://aphyr.com/tags/Jepsen

> This article is part of Jepsen, a series on network partitions.

Covers MongoDB, redis, RabbitMQ, among others. All articles start with "call me maybe", thus the Jepsen reference.

Re: Redis cluster, no longer vaporware

#19

Post by itamarhaber »

chrisan wrote: post #3

Anyone know how AWS clusters Redis? I had alwas just assumed Redis released this a while ago and that is why AWS started to support Redis along with Memcache in their clustered ElastiCache product http://aws.amazon.com/about-aws/whats-new/2013/09/04/amazon-...

AFAIK (but I may be wrong here so if anyone knows better please feel free to correct me) the AWS cluster implementation is a single master and multiple read slaves. Failover is done manually with an API call and in an event of the master's failure, EC spins up a new (empty) master automatically before you can promote a slave in its place.

Re: Redis cluster, no longer vaporware

#20

Post by bkirwi »

antirez wrote: post #10
jrallison wrote: post #8

Earlier quoted context omitted.

It won't do well, but at least Antirez is up front about the shortcomings. The article itself states that Redis Cluster will lose acknowledged writes during partitions (no P), will be eventually consistent (no C), and won't be available during partitions (no A).

Yep, Jepsen is more suitable to check systems that claim either linerizability, or at least write safety, during partitions. I guess that a modified version of Jepsen could be used in order to validate the failure modes or to discover other unexpected ones that at human inspection look easy to reproduce in actual production environments. Also I don't know if Jepsen is good at this, but in theory it could be instrumen…

In theory, Jepsen or a Jepsen-like system should be able to check any of these failure modes.

On the other hand, it sounds like Redis Cluster offers few hard guarantees; instead, it promises that failures should be rare 'in practice'. Which is a fine thing for a tool to do, of course, but it makes things less amenable to the kind of stress-testing Jepsen does -- since running inside Jepsen's little universe is about as far from normal operation as you can get. If you already know that a system can fail in a certain way, getting Jepsen to reproduce that failure tells you very little.

If you'd like to make this kind of testing possible, it would be useful to state as many 'positive' rules as possible, which Redis Cluster should always respect -- things like "if a majority of nodes are fully connected, they should always accept writes" and "an unpartitioned cluster should always agree on the same value" -- alongside the documentation on ways it might fail. This way, clients can be assured of the 'bare minimum' that the system supports, and tools like Jepsen can give you more useful information.

Post reply on HN