
Redis Sentinel properties and fail scenarios - mmastrac
http://antirez.com/news/80
======
bri3d
This analysis does a good job of laying out what the software does, but
there's no reason why Redis needs to work in this unexpected and confusing
way.

Handling replication failures (especially those due to crashed nodes) in in-
memory databases is hardly a new problem and there are formally described
protocols and solutions available which do not require permanent storage and
avoid many of the drawbacks of the Redis Sentinel.

IMO Redis throughout its life has had an identity issue: is it an in-memory
cache, a 'data structures server' like the documentation used to say, a
persistent key-set/key-value/key-? database, or a clustered/distributed
systems solution? Like MongoDB, Redis has ended up used in a lot of
inappropriate environments because of its confusing, mixed messaging.

I personally think Redis is great as a "data structures server" but would
never trust it as a single source of truth or persistent store. When I've used
it in the past to perform and cache set operations (for example, generating
and caching view-privacy lists using set intersections), it's been excellent,
but we've frequently had to re-populate the Redis store from our source of
truth due to bugs or hardware outage / network partition scenarios which Redis
doesn't yet handle well.

~~~
resca79
thanks for sharing your experience. Did you used persistence features of redis
or just the configuration base? like memcache?

~~~
bri3d
In the specific privacy-list usecase, were very early users of Redis (2009
timeframe).

We used RDB persistence for a while but eventually our load got too high for
the fork()-and-snapshot model to work for us.

When AOF was introduced we tried using it but the initial few releases were
_extremely_ buggy to the point that it lost data and confused us more than it
provided persistence.

We eventually decided that since we were using Redis as a glorified cache
anyway (not a source of truth), we might as well leave it to the in-memory
only configuration and make our state-restoration system faster and more
robust.

I've never used Redis as a source of truth / persistent data store because
when I'm evaluating a database to use as a persistent source of truth, it
needs to have a strong story around storage durability, replication, node
failure recovery, and CAP tradeoffs / partition tolerance specifically.

NOTE:

I've used Redis since 2009, of course (still do!), and was just expounding on
the anecdote from my parent post.

All that's changed in terms of persistence for my use cases is that AOF tends
to be fairly workable and not very buggy anymore, and that using a snapshot-
slave makes the RDB snapshot approach more workable. Because the
replication/clustering story has never offered any good guarantees around node
failure or partition tolerance, I haven't used Redis as a source of truth - I
simply use the persistence features to prevent needing to repopulate/re-warm
my cache and list+graph store in the event of an outage.

~~~
resca79
I have figured out what you say redis, but has changed a lot since 2009.

Basically I'm a rails developer so my I usually prefer ActiveRecord.. Mysql or
Postgres. However I have noticed that redis is becoming a very good
alternative to the persistent storage in term of hot cache(like twitter) when
you have heavy writes not only for cache the data after the first read(like
rails in memcache).

Another interesting feature, in the next release, is the support for
geospatial

------
jsherer
I'm a big fan of Salvatore's analyses. They are straightforward from the
perspective of somebody who knows the ins-and-outs of their system(s). We need
more of this.

