> 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
