[Bucardo-general] Missing records,

[Greg Sabino Mullane]

On Thu, Apr 14, 2011 at 09:48:22AM +0800, Kaveh Mousavi Zamani wrote:
> Checking delta and track tables is a great idea. But unfortunate for me, we
> run "bucardo.bucardo_purge_delta" and "bucardo.bucardo_purge_q_table" every
> month and track and delta tables are clean of any useful information.

No, you want to run those often. Many places run those every five minutes!

> All 7 missing records, are from a period of time (in the same minute) that
> slave DB had many problems

Well, it's possible there is a race condition somewhere.

> In a very simple way, is this the flow of process in bucardo?
> 
> Begin Master Transaction
> Begin Slave Transaction
>     Read From Master
>     Update Salve
>     Update Master
> Commit Slave
> Commit Master

Yes, except the last two are reversed. So it's possible that the a row for 
bucardo_track was created indicating that slave was updated, when in fact 
it was not because at some point after the master commit, but before the 
target commit, the target fails. The literal source code is:

$self->glog('Issuing final commit for source and target');
$sourcedbh->commit();
$targetdbh->commit();

As an immediate band-aid, you can flip those two commits around. That way, 
we don't update the master until the kid has finished. That's a lot safer, 
as the only drawback to the kid finishing but not the master is having 
the rows copied over again. Thanks for the report: even if it's not what 
happened in your case, this is a bug that should get fixed.

If you can find the bucardo logs from that period of time, that may help 
figure out what is going on as well.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20110414/543f170d/attachment.bin