[Bucardo-general] Newbie Questions

[Greg Sabino Mullane]

>> [MCP]
>> Responsible for communication with the outside world.

> So it's the thing that's LISTENing?

Well, they all listen - it's how they talk to each other, but 
the MCP is the one listening for the Bucardo "triggerkick" triggers, 
as well as communication via the 'bucardo' program.

> Since reads the DB on startup, does that mean I have to 
> kick it if I add new tables to be replicated?

No - all "ping" tables are auto-kicked on Bucardo startup, mostly 
to cover the case that something happened while Bucardo was down 
an unable to receive the triggerkick notices.

>> [CTL]
>> May be short-lived or persistent (configuratble).

Also, 'configurable'. :)

> Oh? Which is preferable, and why? I would assume that persistent 
> would be preferable in a high transaction environment, less so in 
> a low transaction environment. And by "transactions" I mean 
> "replicable events".

Yes. For low activity, you do not want persistent, as it just ties up 
resources waiting around for something to happen. It's not really 
a lot of resources though, so all in all it's usually easier just to 
leave it as persistent until a problem is seen.

>> [KID]
> Again, I assume the choice should be determined by the 
> volume of replication events.

Yes.

>> Bucardo 4 (B4) had multiple kids per controller (for multiple targets). 
>> Bucardo 5 (B5) does things a little different so currently it is one 
>> kid per controller. That may change. :)
> 
> Hrm. Sounds like maybe it no longer needs to be a separate process, eh?

Not quite. As the kid can be in the middle of a long database activity, 
it's nice to have something that can be easily signalled and can (for 
example) reap the kid if needed. While that job could be moved onto the 
MCP, it gets a little out of its design goal of being a simple 
postmaster-like process that farms out the real work to child processes.
Also, we may go back to multiple kids someday. For true multi-master 
situations it does not make sense, as a single kid has to access all the 
databases, but there might be cases such as one-master, multiple-kids where it 
still might be an overall win. Measurement and testing showed that to 
be a pretty big "might", but I'd also like to keep it separate for any 
future ideas that pop up.

> Thanks, very useful. I've added a Wiki page with this stuff:

Thanks!

>> Tell us your parameters! :)
> 
> Two masters, one in Seattle and one in Portland. Our main requirement 
> is to be able to do maintenance in one data center without the other 
> one needing to go down. It's okay if replication is paused during maintenance, 
> as long as they sync back up quickly when it's done. Relatively small 
> databases (up to around 50G to start) with relatively little transaction 
> volume (a few thousand inserts, updates, and deletes per day).

Yeah, that should be no problem at all.

> I guess I can have Bucardo replicate its own database, eh? 
> That would keep things pretty simple.

It could, but I usually advise something simpler such as WAL-shipping 
or an occasional pg_dump.

> Sure. But if there isn't too much transaction volume, a downtime of a few 
> hours or even a day wouldn't be a big deal, I assume.

Right. It's all about the number of rows that have changed. Anything 
under 100,000 rows is probably not going to be much of a problem.

> How stable is 5.0 if I were to target it? Do you have a release date in 
> mind? Seems like it has been close for a long time…

Sigh. Yeah, the release seems asymptotic. It is pretty darn stable for 
simple use cases, it's some of the edge cases that we are trying to 
iron out. One of the last big things is some changes to the conflict 
resolution system. Right now, because we disable triggers, there is 
potential for violation of foreign keys in certain situations. I have 
ideas on a solution, but no time to implement yet. It may or may not 
hold up a release of version 5. There are some small bugs in the TODO 
list that *are* going to hold up B5, so any help there is appreciated.
There are some outstanding issues raised on the mailing list as well; 
most should be in the TODO, but those should all be considered blockers 
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
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20120917/4f8163c1/attachment.sig>