Hi all,
the first beta of Redis 3.0.0, or should I say "Redis Cluster"? is
out! Our road to get 3.0.0 stable starts officially today.
In this release what I tried to do is to refine the basic operations
in order to provide a software that is ready for "developer
evaluation". There are still a few issues open that will be fixed in
the course of the next betas, but 3.0.0-beta1 is surely something you
can test, evaluate, and develop for. It is also API freeze from the
point of view of the client, and introduces one of the first API break
since months (hash tags), with the exception of multi-keys operations
that could be enabled in the future for keys in the same hash slot,
but should not break clients compatibility in any way.
Also the Cluster Tutorial was improved a bit, and it is still the
entry point for new Cluster users together with the cluster
specification for more advanced users:
http://redis.io/topics/cluster-tutorial
http://redis.io/topics/cluster-spec
This release does not feature only Redis Cluster support, but also a
major speedup, since it introduces a new object called EMBSTR, that is
an SDS string and a Redis object structure encoded in the same
allocation, reducing cache misses. However the focus is definitely on
the cluster and it is a very "poor" release otherwise, as other major
releases usually provide much more enhancements: most of the next
improvements outside the cluster are are deserved for the 3.2 release,
that will be a "back to fundamentals" release.
Next steps: beta-2 will be focused a lot on writing unit tests for
Redis Cluster. It is possible that a completely new testing framework
will be written specifically for Redis Cluster, and that running the
two test suits for Redis standalone and the cluster version will
require executing different commands: Redis Cluster tests are likely
to be slow and many users may not care about cluster.
I saw new things in the area of clients: Jedis included support for
Redis Cluster, and Predis improved the support that was already
present. Thank you for your work guys!
However make sure to avoid using key names containing {} characters
while testing those clients, the hash slot thing was added just a few
days ago so clients must fix the algorithm. Redis-rb-cluster is
already fixed and can be used with hash slots already.
From the point of view of support for multiple DC setups, this is
still an ongoing effort. You can already clone every master node in
other DCs but there is currently no mechanism preventing those slaves
from trying to get promoted when a master is failing. The idea is to
have the ability to configure a set of instances as "fixed", so
they'll only switch master when a configuration change is detected,
but will never try to get elected. However this is not enough, and
redis-trib should provide support to "mass-configure" all those slaves
as masters when switching to a new datacenter is needed (but this will
be as simple as sending CLUSTER FAILOVER to every slave). I would love
to get feedbacks about this, how do you plan to use multi-DC setups?
IMPORTANT: keep in mind that if you start evaluating Redis for
development or production, before the release of the stable version
you'll get direct support from me every time you find an issue. Fixing
issues in Redis Cluster will be considered critical and high priority
even if the release is in beta.
The next beta, beta-2, will be released between 10 and 12 March 2014.
Have fun!
Salvatore
--
Salvatore 'antirez' Sanfilippo
open source developer - GoPivotal
http://invece.org
To "attack a straw man" is to create the illusion of having refuted a
proposition by replacing it with a superficially similar yet
unequivalent proposition (the "straw man"), and to refute it
-- Wikipedia (Straw man page)