is there a 15 second blank time in master-slave replication?

[Shaojie Liu]

i'm trying to initiate a memcachedb with millions of data. 

while i do SET operation on master, i will double check the slave by GET.   the pesudo php code reads like:

for ($i=0; $i<VERYLARGE; $i++){
 $val = 'RANDOM';
 $obj->setMaster($key.$i, $val);
 $val2 = $obj->getSlave($key.$i);
 if ($val != $val2) {
   print "Warning.....................!";  //warning lines
   sleep(1);
   $i--;
 }
}



what i found is, there are usurally several recursive warning lines,  taking 15 second or so. and then go on. 


we are using version 1.0.3,  the master/slave machines are pretty idle and light-weight loaded.

[Steve Chu]

How about your ACK policy and group topology? Does it replicate over WLAN?
If you run with the default ACK policy, the master will ask for at
lease one ack from clients who can participate in election. This ack
timeout value in 1.0.3 version is 20ms. If master can not get a ack
reply, it will flush the transaction log buffer, and make it durable.
In this case, the client will fall behind with master, but when client
find out these gaps, it will ask for retransmission, then the client
catch up with the master.

--
Steve Chu
http://stvchu.org

[Shaojie Liu]

glad to see the reply, steve.

 

we use default ACK, and the repl happens in a gigabit LAN.

So,  if a repl delay detected at slave side,  two questions are:

1) how fast can it be detected?

2) what will BDB do? can this catching-up(or re-sync) process take more than seconds?

 

i know these questions might be out of range of memcachedb, and i do remember i have ever read somewhere, that there are two ways to implement BDB replication, Api and Repl manager.

[Steve Chu]

On Thu, Oct 9, 2008 at 11:11 PM, Shaojie Liu <liuso...@gmail.com> wrote:
> glad to see the reply, steve.
>
> we use default ACK, and the repl happens in a gigabit LAN.
> So, if a repl delay detected at slave side, two questions are:
> 1) how fast can it be detected?

This is determined by a bdb config: DB_ENV->rep_get_request.

> 2) what will BDB do? can this catching-up(or re-sync) process take more
> than seconds?

Maybe. The BDB people do not say clearly. 1.0.3 version is based on
bdb 4.6, and rep_get_request is calculated with request times, this
has been changed in bdb 4.7 while with timeout values.

>
> i know these questions might be out of range of memcachedb, and i do
> remember i have ever read somewhere, that there are two ways to implement
> BDB replication, Api and Repl manager.

Yes, MemcacheDB's replication is based on Repl manager.