[Bucardo-general] Hot database synchronization

[Adam Wendt]

Here is how I do it:

(assuming all of postgresql on site b is lost)

1. If bucardo db was on Site A then remove the old sync/goat/herd etc
2. Site A. Dump a schema only backup and exclude the bucardo namespace so
you aren't copying triggers
3. Site B. Load schema, just table definitions, leave out constraints and
indexes as they will slow down load from backup
4. Recreate bucardo tables on whichever site you run bucardo,
goats/herd/sync (at this point bucardo should not be running)
5. Site A. Do data only dump with --disable-triggers
6. Transfer backup to Site B.
7. Site B. Load backup
8. Site B. Load indexes/constraints and vacuum analyze full if you like
doing that sort of thing
9. Start bucardo! should be done

Adam
Adam Wendt Consulting

On Tue, Mar 17, 2009 at 9:04 AM, Lev Tannen <levtannen at gmail.com> wrote:

> Hello,
> Scenario:
> Two Postgresql sites (A and B) with master to master to master replication
> running for sometime. Site B crashed. I would like  to restore restore it
> from and to synchronize it with A. I want to do this without stopping the
> site A.
> Could anybody point my to a posting with a detail instruction on how to do
> this please.
>
> In the case there is no  detailed instruction, bellow is my understanding
> on how this should be done. Please point me where I am wrong or what I have
> missed.
>
> Thank you,
> Lev
>
> Steps.
>
> 1. On A site. Create a backup using pg_dump (pg_dumpall). Write down a
> backup start time.
> 2. On A site. Delete all records from bucardo_delta with starting date
> before the backup time.
> Note this step is not necessary, but useful to prevent excessive inserts
> later.
> 3. Recreate and repopulate the Bucardo database if it was destroyed (For
> example if it resided on  site B)
> 4. Change "swap" to "pushdelta" and set site A as the source and site B as
> the target).
> 5. Change the type of conflict resolution to "source win".
> 6. On B site. Use the backup to recreate or to replicate site B.
> 7. Start Bucardo. Wait until it replicate A to B. (If necessary issue a
> kick).
> 8. Return to "swap".
>
> I believe that will work, but I have some question.
> When bucardo starts replication from A to B it can encountert 3 types of
> conflicts.
> 1. The row that it tries to delete does not exists. This is probably not a
> conflict at all.
> 2. The row it tries to update had a value that differs from of what is
> expected. Setting the conflict resolution type to "source win" should handle
> this.
> 3. The row it tries to insert  already exists. The correct behavior in this
> case would be to ignore the conflict and do nothing or to delete and
> reinsert the row. My question is how to persuate Bucardo to behave one of
> this way.
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Bucardo-general mailing list
> Bucardo-general at bucardo.org
> https://mail.endcrypt.com/mailman/listinfo/bucardo-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20090317/0bddd4b7/attachment.html