[Bucardo-general] Newbie Questions

Greg Sabino Mullane greg at endpoint.com
Fri Sep 21 20:39:21 UTC 2012


> No, I mean if Bucardo has been running a while, and I need to change 
> its configuration (add new dbs, goats, whatever), do I need to kick 
> it in order for it to pick up the configuration changes?

Yes: you can do 'bucardo reload_config' for that purpose (config changes 
only), and a 'bucardo reload' to pick up new syncs and the like. I don't 
think we have a way yet to smoothly add new syncs: right now reload 
basically causes the MCP to stop all existing syncs, forget everything 
it knows, reload from the database, and start again.

> This reminds me, though. I'm planning to build a system with two masters, 
> each in its own data center. There will be several databases, all replicated 
> between the two DCs. But some will depend on each other. For example, a 
> "customers" table in a "main" database might need to be replicated to other 
> databases in the same cluster, so that they can conveniently do JOINs and such. 
> That would be a master/slave (god I hate these terms) configuration. I assume 
> that this is not a big deal for Bucardo, that it can do a variety of different 
> types of replications in a single instance, yes?

You can use Bucardo's preferred terms "source" and "target". We just keep 
master and slave around for backwards compatibility. :)

Yes, Bucardo can handle things like that: each sync is completely distinct, 
and can have any combination of databases as needed. As of about a week ago, 
you can even replicate within the same database (especially useful with 
the customname feature!)

> > It could, but I usually advise something simpler such as WAL-shipping 
> > or an occasional pg_dump.
> 
> Well, if Bucardo is already there and running, why not just use it, too? 
> With trigger-based NOTIFYs, it doesn't seem as if it would add much overhead 
> in addition to what it's already doing for the system, would it?

*shrug* It's a little more overhead, but doable. We should probably concoct 
a standard recipe on the wiki for doing so (e.g. to handle the non-PK 
tables).

> Sounds important.

It is, but it's also more edgy of an edge case that it first appears.

> These?
> 
> * Fix quoting bug reported by Sean M. Pappalardo
> * Fix need for password argument when using md5
> * Get Drizzle tests verified as working
> * Get bucardo-report working again
> * Note 8.2 minimum requirement somewhere (probably from COPY (select))
> * Get some solid tests for the makedelta system
> * Fix bug with checking wrong tables in databases on startup reported to list
> 
> Where will I find context for these? They appear to be more notes to yourself. 
> Which I can appreciate, but not be much help with. :-)

I will try to flush those out a little bit. I should point out that the 
8.2 requirement is no longer true: I successfully tested a 8.1 target 
yesterday. But we do want to note the minimum source database and 
target databases.

> If you could put together a canonical list with context, I could likely put in a 
> little time to fix some of them. Would be great to have a list of things to be 
> done for 5.0, so that anyone could see where things stand and how things 
> are progressing. Maybe use GitHub issues and a milestone? I find it pretty 
> useful for a personal project I work on.

Thanks for the help offer! I'm wary of yet another aspect of Bucardo project 
management, as I have very little time to throw at it some weeks. Maybe 
yourself or David Christensen could spearhead that effort? I'd be happy to 
answer quick questions on IRC to help out.

-- 
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/20120921/68562133/attachment.sig>


More information about the Bucardo-general mailing list