[Bucardo-general] Missing records,
Greg Sabino Mullane
greg at endpoint.com
Thu Apr 14 17:50:50 UTC 2011
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');
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
Size: 163 bytes
Desc: not available
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20110414/543f170d/attachment.bin
More information about the Bucardo-general