[Bucardo-general] KID dies with 'could not serialize access due to concurrent update' (prevents replication)
Greg Sabino Mullane
greg at endpoint.com
Fri Dec 9 04:15:29 UTC 2011
On Wed, Dec 07, 2011 at 02:06:11AM -0500, Bill McGonigle wrote:
...
> None of our code is setting transactions to SERIALIZABLE, and I've seen such
> warnings before in the bucardo log (which seem to have been transient - I
> see the code just sleeps and tries again). But in this case, it's halting
> the works, and my "KID Total delta count" is only growing. Is this bucardo
> stepping on itself? If so, is there a way to get it to be less parallel
> so that it can finish one transaction?
That's a fairly common warning on busy systems, and there is little that
can be easily done to solve it. The larger the number of deltas, the
longer a Bucardo sync transaction will take, and the greater the chance
of a serialization error. Bucardo needs to be in serialiable mode to
ensure a consistent snapshot during all of its querying/deleting/inserting.
It is not Bucardo interfering with itself (unless you have the same table
involved in different active syncs.) It is also unrelated to uptime.
You came across one way to solve this: block other processes that are
updating the tables in question at the same time. There is a brute force
way to try and get around this problem via Bucardo itself. If you create
a file named /tmp/bucardo-force-lock-foobar, where foobar is the name
of your sync, Bucardo will attempt to lock all the tables involved in
the sync at the start of the transaction. This will solve most serialization
errors (at the obvious high cost of locking out other processes!). The
default lock level is EXCLUSIVE. You can change this by putting the desired
lock level inside the file (its existence is enough to trigger the locking,
of course, so the lock mode inside of it is optional).
Another "solution" is to use Postgres 9.1, which has a greatly improved
serialization mode which may prevent some serialization errors from
occurring in the first place.
I would be remiss is stating that yet another solution is Bucardo 5, which
does things a lot more efficiently than Bucardo 5, which means greatly
reduced transaction times, which means less chance for serialization
errors.
--
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/20111208/2af31a03/attachment.bin
More information about the Bucardo-general
mailing list