On Thu, Mar 3, 2011 at 11:18 AM, Felipe Cerqueira <skylaz...@gmail.com>wrote:
> The replication only works with binary mode. Did you set it up? > Oh, no, I guess that would help. I must of missed that in the docs. I was running Memcached 1.2.8, so I just installed 1.4.5 and enabled binary in the Perl code with: $memc->memcached_behavior_set( MEMCACHED_BEHAVIOR_BINARY_PROTOCOL() => 1 ); $memc->memcached_behavior_set( MEMCACHED_BEHAVIOR_NUMBER_OF_REPLICAS() => 1 ); If I write a sequence of keys using memcached_set( $key, 1 ) in a loop I only see (with memcached -vv) SET on the one server per key (the "primary" based on how it's hashed). But, then when I exit the program (closing the connection) the LAST key I wrote gets written to the replicant(s). Do I need to flush or something like that after every set call? > And, remember, this feature is only for replication data, not > consulting (get). > The docs seem to indicate otherwise, and indeed if I kill the "primary" where a key was set and attempt to read then it reads from the replicant. MEMCACHED_BEHAVIOR_NUMBER_OF_REPLICAS If you just want "a poor mans HA", you may specify the numbers of replicas libmemcached should store of each item (on different servers). This replication does not dedicate certain memcached servers to store the replicas in, but instead it will store the replicas together with all of the other objects (*on the 'n' next servers specified in your server list*). MEMCACHED_BEHAVIOR_RANDOMIZE_REPLICA_READ Allows randomizing the replica reads starting point. *Normally the* *read is done from primary server and in case of miss the read is done from primary + 1, then primary + 2 all the way to 'n' replicas*. If this option is set on the starting point of the replica reads is randomized between the servers. This allows distributing read load to multiple servers with the expense of more write traffic. -- Bill Moseley mose...@hank.org
