[Bucardo-general] Hot database synchronization

Adam Wendt thelsdj at gmail.com
Tue Mar 17 18:18:00 UTC 2009


--disable-triggers shows up in my pg_dump --help, it is what you guess, it
inserts disable trigger commands into the dump so that when you load the
dump no entries will be created in the delta table

As long as you use a simple conflict resolution method for the initial
synchronization like 'source' or 'latest' then it will just be a no-op and
the data will look exactly like it should when all done.

Adam
Adam Wendt Consulting

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

> Hello Adam and thank you for response.
>
> Most likely  I just imagine things, but I see some problems with your
> algorithm.
> Bellow I sumarized my questions to you.
> I would appreciate your futher clarifications.
>
> 4. Recreate bucardo tables on whichever site you run bucardo,
> goats/herd/sync (at this point bucardo should not be running)
> My understanding is that populating the sync table will cause creating
> triggers on site B because the type of replication was "swap". These
> triggers, if I will not explicitly disable them, will cause Bucardo to try
> to move data from B to A later.  I could disable triggers, but having about
> 30 replicated tables I consider that to be troublesome. I hope I could
> achieve the same result by setting the replication type to pushdelta during
> the process and  switching it  to "swap" later.
>
> 5. Site A. Do data only dump with --disable-triggers
> What does --disable-triggers mean? I am using Postgresql's pd_dump. I did
> not find such an option in its description. Should I use another utility? If
> --disable-triggers means to insert into the dump instructions to suppress
> all trigers during the restoration it would eliminate the problem in p.4.
>
> 9. Start bucardo! should be done
> At that point I expect to get a number of conflicts because Bucardo will
> replicate not only events that occur after the dump was created, but also
> those that occur  before and during the process of creating a dump. Could I
> hope that Bucardo will behave correctly without my intervention?
>
>
> Thank you,
> Lev Tannen
> (Sorry for my English)
>
>
> On Tue, Mar 17, 2009 at 1:14 PM, Adam Wendt <thelsdj at gmail.com> wrote:
>
>> 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/31b50f54/attachment.html 


More information about the Bucardo-general mailing list