[Bucardo-general] Replication scenario and Bucardo application

[Greg Sabino Mullane]

On Fri, 2007-12-07 at 08:52 -0500, Robert Scott Davis wrote:

> In summary the fielded systems can be connected to internet and in  
> "real-time" be replicating with the central server and in some cases  
> there can be some fielded systems that are not connected to the  
> internet and operating with other client systems in a LAN that at some  
> point would be connected to the internet and would want to replicate  
> with the central server.
> 
> Is the use of bucardo viable for this situation.

Yes, Bucardo is actually a pretty good solution for such an "extremely
asynchronous" solution. While it doesn't do more than two master
databases at once, what you describe is more of a star network of
masters, which Bucardo can handle with the "makedelta" flag. Basically,
Bucardo uses triggers to add rows to a queue indicating that specific
rows have changed and that they need to be synced. When doing a
master-master sync, triggers are disabled and (quite naturally) the
queue row is not created on the side that changes. However, if the
makedelta flag is on, Bucardo will add a 'fake' entry to the queue table
itself, as well as an internal tip saying "I've already synced this row
with server X". Thus, the when server Y comes along to do a
master-master, it sees there is a new row and syncs it. So, the row goes
from server X to the main server to server Y.

The danger comes when the conflict resolutions collides, such that
servers X and Y both feel they have the "right" value for a row and keep
overwriting each other via the master intermediary. This can be worked
around, and only applies to servers that are updating the exact same
record and both think they, not the master server are authoritative.
Short of going fully synchronous, there is no real way to completely
avoid such a problem, as conflict resolution routines often need access
to the original database at resolution time, so even a Bucardo that did
master-master-master would not help. But being careful in conflict
resolution will stop if from occurring in practice.

-- 
Greg Sabino Mullane greg at endpoint.com
End Point Corporation 610-983-9073

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: This is a digitally signed message part
Url : https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20071207/4e1d4345/attachment.bin