[Bucardo-general] Complex Bucardo install reaching limits

[Greg Sabino Mullane]

> To solve this "connected/disconnected" problem we have set up the laptops
> to each run their own bucardo server with their own client-specific syncs.
...
> We're currently using 4.99.11 and on my task list is to update to current
> head.

This would be my number one recommendation. There have been a lot of bug fixes 
and makedelta optimizations since 4.99.11. Version 5.3.0 was recently released - 
I would try that rather than head at the moment.

> I believe that the proper solution to our issues is to switch around so
> that we're running a single central bucardo process with a single set of
> syncs. However for this to be successful the "in the works" database-down
> detection would need to be complete, since we don't want a sync to stall or
> fail on down database (because most databases will be down most of the
> time). Instead, just to skip databases that are down, then catch them up
> when they come online. I know that's not available yet.

This should be working. I would test it first, but in theory if each remote 
DB has its own sync, then you should be able to set it up as described. If 
it doesn't work, file a bug report and we will get it going. However, it 
won't really do anything to solve the contention issue.

> In the meantime, are there any suggestions on how to overcome our current
> scaling limitations? Would it be useful to change over to a central
> burcardo server but still have client-specific syncs that continue to use
> makedelta? I don't really see how that would solve the current contention
> issue but maybe it would. Any other thoughts?

You could try switching the isolation_level, but other than that, it would 
really depend on the details of how the contention is happening. We could 
investigate some solutions such as lightweight locks or random sleeps, but 
it really depends on how the contention arises, e.g. are the clients 
conflicting with each other's updates, or is it mostly updates to the 
main db that are causing issues. Or perhaps it is the makedelta system causing 
contention. How often the syncs run and how long they take are factors as well. 
On that note, anything making the syncs faster will help as well - so splitting 
into multiple syncs would help, if your schema can handle that.

If you can describe things well enough, it would be great to generate a test 
file. You might check out a recently added one, t/50-star.t, which creates 
a setup very similar to yours - a central DB, and multiple syncs (I think 
the test has around 20). I get the occassional seriliazation failure when 
running the test, but it is fairly rare.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Digital signature
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20150103/b14c1671/attachment.sig>