[Bucardo-general] Master

Greg Sabino Mullane greg at endpoint.com
Sun Jul 28 02:10:54 UTC 2013

On Thu, Jul 25, 2013 at 09:25:40PM +0200, David E. Wheeler wrote:

> * In practice, for relatively static databases (say a couple thousand updates a day), 
> and using autokick (née ping), how much lag can we expect between the two data centers?

At that level, the lag is almost always related to the built-in sleeps. Lag is usually 
around 1 second average, 2 seconds tops unless something else is going on (e.g. a very 
large changeset, super busy server, pigeon network). You can tweak the sleeps downward 
to decrease the lag. On the todo is to replace some of those sleeps with proper polling.

> * If we want to shut down one of the servers for maintenance, we will point all traffic 
> at the other box. Is there an easy way to tell when all the databases on the node to 
> be shut down have had all their data synced over? Or would I just have to write a 
> scrip to check all of the delta table row counts until they are all zero?

No easy way, but in general the process is stop the apps / repoint traffic, then wait 
a minute or two. You could check the status of the most busy sync, that's a pretty 
good indicator. A script sound like a good idea, especially to make sure you manually 
kick any non-auto syncs you may have forgotten about. ISTR a script someone made once 
to kick all syncs and make sure they finished okay.

> In practice, are there any problems with a user writing data and then not seeing it 
> show up, because one request goes to one server to write, then reads from the other 
> before the sync finishes? Does this happen occasionally? Rarely? Often?

No experience with that, IMO if you are doing round-robin masters it really falls 
back to the app to do the right thing, e.g. write and read from the same db 
as much as possible. If it becomes a problem, you could train your app to make 
a db handle "sticky" for X seconds after a write, where X > average_lag_time.

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/20130727/e05ca019/attachment.sig>

More information about the Bucardo-general mailing list