Hi Daniel,
Redis doesn't do synchronous replication because it's not what typical
users of the DB want (particularly for the use-cases Redis is common
for). If you need to guarantee that a particular transaction has been
processed before continuing a procedure, you can watch for the value
to propagate to your preferred quorum of slaves. If you want fully
synchronous multi-node replication for every operation in a datastore,
you want Zookeeper or something that implements Paxos.
MongoDB's strategies for these topics are something else altogether -
the "fire-and-forget" criticism there came from Mongo not persisting
to disk on a single node before returning an "OK" (by default). See
the fsync options on AOF for how to tune Redis with regard to this
question.
As an aside: the CAP theorem is a tool to guide decision-making, not a
concrete featureset for databases to implement. It's there to help us
point out that pretty much any real-life distributed system will have
tradeoffs between availability and consistency at different levels of
granularity. See for example Redis's configuration setting of
'slave-read-only', which can be used to make consistency/availability
tradeoff decisions during a master/slave transition.
Cheers,
--bpo
> --
> 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?hl=en.
> For more options, visit
https://groups.google.com/groups/opt_out.
>
>