[Bucardo-general] Alternative to onetimecopy with bucardo 5.1.2

[Greg Sabino Mullane]

On Fri, Jan 09, 2015 at 12:01:29PM +0100, sym39 wrote:
> -One machine "A" with one database that already have data, some
> clients regularly fill the database
> -Another machine "B" with the same database schema, all tables
> empty, nobody fills the database
...
> What I am trying to do is :
> 1. To initialize machine "B" with "A", when machine "B" can be
> assimilated as slave, and "A" as master (As said above, nobody tries
> to add lines to it when A is up, only A database is filled by the
> clients)
> 2. To make sure I can change role, ie, if machine A fails, machine B
> becomes the master and is filled with data, and when machine A is up
> (so it is the slave and B stay master) and there should be no gap in
> A databases (especially for big tables)

It sounds like what you need is a multi-source sync, in which the 
conflict resolution doesn't matter, as nobody will be writing to B.
So you want something like this:

bucardo add sync foobar relgroup=myrels dbs=A:source,B:source

To initially populate B, you should setup Bucardo first, so that 
the bucardo triggers on A are in place, then use pg_dump plus 
psql to bulk copy the data from A to B. Something like:

pg_dump -h A mydb --data-only | psql mydb -h B

Once A comes back up, all the changes that accumulated on B 
will be copied by Bucardo onto A.

> -Not really related - Should I create some specific sync for "big"
> tables, or is it better to have only one sync for all tables? I saw
> that having only one sync for all tables avoid tables to be filled
> when a conflict is detected (may be more about automatic conflicts
> resolution in another post ...)

In your particular case, with no activity on B and thus no chance of 
conflicts, I would keep it all in one sync. But it is generally better 
to have multiple syncs for unrelated tables - within reason. This is 
so the syncs finish faster and locks are held for a shorter amount of 
time, thus reducing serialization errors. I would only separate out 
very large and/or busy tables this way, however - no sense in having 
50 syncs for 50 tables if a single sync completes in a second or 
two with no problems.

-- 
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/20150115/a0568dbd/attachment.sig>