pre-release repcached (data replication patch)

hirose at klab.org hirose at klab.org
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:
  http://lists.danga.com/pipermail/memcached/2007-September/005155.html

> > = 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.

overhead:
  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.

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

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

benchmark:
  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
  heavily.



> 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