[Bucardo-general] Simple question regarding master-master

Fri Jun 14 13:49:46 UTC 2013

Thanks for the code Mitchell. One quick question: which version of bucardo
and under which OS you are using? I tried it on debian wheezy (and the
packaged bucardo 4.99.5) and I get errors like below:
Unknown option: log-destination
Unknown option: no-exit-on-nosync
Unknown option 'conflict_strategy'

are you using the version from github?

On Fri, Jun 14, 2013 at 3:31 PM, Mitchell Perilstein <
Mitchell.Perilstein at trueposition.com> wrote:

> Again, not saying it's right, but it's roughly something like this. Names
> changed, error checks not shown, repeated for a number of tables and
> databases, etc..
>
>     bucardo add database    source_xx host=tplocalvirt user=myuser db=xx
> dbport=5432
>     bucardo add database    --force target_xx host=mypeerhost user=myuser
> db=xx dbport=5432
>     bucardo add table       $ALLMYTABLES db=source_xx herd=xxherd
>     bucardo add dbgroup     xxgroup source_xx:source target_xx:target
>     bucardo start           --log-destination=syslog -no-exit-on-nosync
>     bucardo add sync        xx_sync herd=xxherd conflict_strategy=latest
> onetimecopy=1 dbs=xxgroup
>     bucardo set syslog_facility=local6
>     bucardo set mcp_dbproblem_sleep=0.5
>     bucardo set isolation_level='read uncommitted'
>     bucardo set statement_chunk_size=1000
>     bucardo activate sync   xx_sync
>
>
>
> On 06/14/2013 09:12 AM, Athanasios Kostopoulos wrote:
>
>> Thanks for the reply Mitchell. So you do something along the lines of:
>> in master1:
>> bucardo add dbgroup master1:source master2:target
>> and fire off the relative sync
>> and on master2:
>> bucardo add dbgroup master2:source master1:target
>> and fire off the relative sync?
>>
>>
>> On Fri, Jun 14, 2013 at 3:02 PM, Mitchell Perilstein <
>> Mitchell.Perilstein@**trueposition.com<Mitchell.Perilstein at trueposition.com>>
>> wrote:
>>
>>    We're running differently from Rosser's one-bucardo suggestion--which
>>> does make sense.  We're dual master but we need both boxes to be as
>>> identical as possible partly because the process has to be repeatable on
>>> many pairs and also because we bounce our apps on occasion but want the
>>> DBs
>>> to stay in sync.  So we have bucardo on each box, with each local bucardo
>>> writing to its remote peer.  So it's a criss-cross arrangement.
>>>
>>> For our purpose, at least, this also gets us a little bit of HA: even if
>>> our application layer and bucardo are down on one box, as long as its
>>> database is running, the fully-up peer box will continue writing its
>>> changes to the partly down box.
>>>
>>> I'm not saying our approach is correct, but it's working for us.
>>>
>>>
>>>
>>> On 06/14/2013 07:17 AM, Rosser Schwarz wrote:
>>>
>>> Bucardo only needs to be installed on one host, although obviously, that
>>> won't provide HA capability. Typically, in a master-master scenario, it's
>>> installed on one of the masters. In the event either of the masters then
>>> goes down, the Bucardo daemon wouldn't have anything to do anyway, so HA
>>> for it is pretty moot.
>>>
>>>
>>> On Fri, Jun 14, 2013 at 3:44 AM, Athanasios Kostopoulos <
>>> athanasios.kostopoulos@**classmarkets.com<athanasios.kostopoulos at classmarkets.com>>
>>> wrote:
>>>
>>>
>>>   In continuation to my previous email?
>>> For example the following approach might be effective:
>>> - install bucardo on master1
>>> - setup replication as follows: master1: master - master2: slave
>>> - verify that replication works
>>> If the above are correct then:
>>> - install bucardo on master2
>>> - setup replication as follows: master2: master - master1: slave
>>> - verify replication works
>>> Will the previous be enough or I am missing a fundamental piece here
>>> (perhaps not needing to run bucardo on two different hosts and use one
>>> setup (say on master one) and two replication streams. How will this
>>> handle
>>> failover?
>>>
>>>
>>> On Thu, Jun 13, 2013 at 5:43 PM, Athanasios Kostopoulos <
>>> athanasios.kostopoulos@**classmarkets.com<athanasios.kostopoulos at classmarkets.com>>
>>> wrote:
>>>
>>>
>>>   Dear all,
>>> first of all, thanks for the hard work that has been put into bucardo. I
>>> am a novice and I have the following perhaps trivial question:
>>> when wanting to create a master-master setup, do I need to install
>>> bucardo (e.g. bucardo install) on both of the masters? I am on Debian 7
>>> wheezy with bucardo 4.99.7, installed from the Debian repositories.
>>> Thanks
>>> in advance for any answers to my perhaps trivial question.
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Bucardo-general mailing listBucardo-general at bucardo.**orghttps://
>>> mail.endcrypt.com/**mailman/listinfo/bucardo-**general<http://mail.endcrypt.com/mailman/listinfo/bucardo-general>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Bucardo-general mailing listBucardo-general at bucardo.**orghttps://
>>> mail.endcrypt.com/**mailman/listinfo/bucardo-**general<http://mail.endcrypt.com/mailman/listinfo/bucardo-general>
>>>
>>>
>>>
>>>
>>> Confidentiality Notice: This e-mail (including any attachments) is
>>> intended only for the recipients named above. It may contain confidential
>>> or privileged information and should not be read, copied or otherwise
>>> used
>>> by any other person. If you are not a named recipient, please notify the
>>> sender of that fact and delete the e-mail from your system.
>>>
>>>
>
> Confidentiality Notice: This e-mail (including any attachments) is
> intended only for the recipients named above. It may contain confidential
> or privileged information and should not be read, copied or otherwise used
> by any other person. If you are not a named recipient, please notify the
> sender of that fact and delete the e-mail from your system.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.endcrypt.com/pipermail/bucardo-general/attachments/20130614/66ca9d4f/attachment.html>