pre-release repcached (data replication patch)

hirose at hirose at
Mon Nov 5 13:53:38 UTC 2007

> What type of overhead are we looking at? Do you have benchmark  
> numbers? Wouldn't this cause memcached to lock while its replicating  
> an object? Do the nodes communicate to make sure data is in sync?

quote form:

> > = replication lag =
> >
> > see above, client does only access to master node. so replication
> > lag is no matter.
> >
> >   replication sequence:
> >     1. client requests SET command to master
> >     2. master stores to own area.
> >     3. master send key/vaue to slave by memcached protocol
> >     4. master DO NOT wait receiving "STORED" from slave (asynchronous)
> >     5. master return "STORED" to client
> >
> > There is no get-back-old-data problem, even if master goes down during
> > between step of 2 and 4. because client does not receive "STORED"
> > response from master, so client will retry after a while.

  above step 3 is overhead. I think this overhead is small because
  master just send set command to slave and DO NOT wait "STORED"
  response from slave.

  see abobe, no need to lock for usual data replication.

data synchronous:
  I assume that client access to master not slave.

  in my private benchmark, result of memcached and repcached are
  same. (40,000 set/sec 45,000 get/sec)
        (connect -> set -> disconnect -> connect -> set -> ...)
  I plan to improve benchmark program to stress {mem,rep}cached more

> The approach I took when I wrote memcached proxy was that clients  
> could connect to proxy for doing things such as set,delete, etc. The  
> idea being you have a proxy on each host running local copy of  
> memcached, in parallel the proxy makes 2 async requests to local/ 
> remote server, reads client <-> local, disconnects client when done  
> while commands are pushed across to remote (combining the multiple  
> sets into larger packets for write buffer).

our repcached is:
  - no outer proxy process. include proxy function in memcached
    process for less overhead.
  - keep connecting between master and slave for replication.

HIROSE Masaaki

More information about the memcached mailing list