redis cluster - multiple DC support?

[Jon Haddad]

Hey all,

I was wondering if one of the design goals of redis cluster is to support multiple datacenters, where all the data from one DC is completely replicated to another DC?  

I ask because we're planning on setting up a second datacenter soon, and we're heavy users of sorted sets.  We use redis as the primary DB for this feature.  (unread message lists in a messaging system)

Jon

[Josiah Carlson]

Multiple datacenter support is not one of the design goals of Redis cluster.

If you are using intersections/unions of sorted sets, note that Redis cluster may subject you to certain limitations you're not used to.

Quick question: are you trying to replicate one, several, or many DBs to another DC? If it's just one or a handful, you could just replicate them directly (over an SSH tunnel with compression enabled is generally a huge win in terms of bandwidth and security).

 - Josiah

P.S. If you see Clark around the office, tell him that Josiah says hey :)

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+u...@googlegroups.com.
To post to this group, send email to redi...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/groups/opt_out.

[Jon Haddad]

Bummer.  We don't do any intersection operations - we would just like to have a HA setup with redis and > N datacenters.  Master / slave doesn't really work for that.

We've been toying with taking the redis guts and building something that would be more in line with our goals, which would support quorum reads / writes, multiple DC support, and fully masterless.  We'll see if we ever have time to explore that.  

[Josiah Carlson]

If you are thinking about that kind of functionality, might I recommend instead building your quorum bits and pieces outside Redis? Twitter has a package called twemproxy (https://github.com/twitter/twemproxy) whose purpose is to minimize backend connections in sharded scenarios. Starting with it as a base gives you free sharding, connection handling, etc. If you add quorum support, you then only need to borrow some of the ideas behind Redis sentinel (modified as necessary to fit your needs) for handling failover and master election. Then, you can run a collection of proxy servers, which handle sharding, failover, etc.

Before you brush this off as crazy and not workable, take a look at Slony for Postgres. It's a different database, but a lot of the same features were built in a similar context.

 - Josiah

[Jon Haddad]

The problem with sentinel is that I'm not really interested in having a master / slave relationship.  I'm looking for a very different networking layer that wouldn't be solved from twemproxy.

Take a look at the cassandra architecture from a networking standpoint - that's what I'd like to see.

Fortunately it would be possible (not easy) to put a networking layer on top of redis that could allow for the behavior I'm looking for - highly available w/ partition tolerance (rather than consistent)

[Josiah Carlson]

Right now, I don't believe any Cassandra-like setups for Redis exist. Could you build it? Sure. But if all of your data fits in memory anyway, I'm sure Cassandra would cache it all, and may have reduced, but reasonably comparable throughput... plus all of the features you seem to want, without any work.

Just playing devil's advocate.

 - Josiah