----- Original Message -----
Hey,
I want to be noisy on this to make sure there are no other work going
on
wrt to replication.
We don't have any replication features built-in yet for memcached, and
I
am working on a new component on the F1 server that requires it.
What are the exact requirements/SLA? Never losing data, or just losing
it "less often"?
There are two leads:
1 - use memcache, and set up a poor's man replication system
2 - use membase and benefit from their peer-to-peer replication system
for 2/, it requires to write a new hashing algorithm (vbucket) in the
client, as none has it yet. or write a client from scratch using
libmembase. Adding it to pylibmc is quite painful because it would
require changing libmemcached itself.
pylibmc is what we want to use for F1, and later in other projects,
because it's compatible with the socket patching gevent does
And after a discussion with the pylibmc author on IRC, I am inclined
to
try 1/ because he told me that lib has a non documented replica
feature
that allows the client to send replicas to several servers,
asynchronously if wanted.
1/ still has a lot of the operational drawbacks that regular memcache has;
that vbuckets article you posted is great and describes some of the problems
(adding a new server, consistency issues, etc).
I think our choice depends on the actual data storage requirements/SLA.
If it works and it's stable, I'll post examples to the dev guide and
send a new mail here.
If it doesn't I'd probably experiment w/ a membase client and see how
we
can set up membase servers.
I think we're going to have lunch with the membase guys sometime soon
(they had reached out to mrz and he passed off to us) so if you have
any specific questions for them, let me know.
This work might be applicable to tab memcache storage, too.
thanks,