[Bucardo-general] Simple question regarding master-master
Mitchell Perilstein
Mitchell.Perilstein at trueposition.com
Fri Jun 14 14:33:50 UTC 2013
Hm, works for me. (despite one vs two dashes, oops).
# bucardo start --log-destination=syslog -no-exit-on-nosync
Checking for existing processes
Removing /var/run/bucardo/fullstopbucardo
Starting Bucardo
# bucardo --version
bucardo version 4.99.7
Regarding your error below, did you do a "bucardo set search_path ...."?
On 06/14/2013 10:08 AM, Athanasios Kostopoulos wrote:
> I have banged a quick shell script using Mitchell's advice and pseudocode
> (thanks again, this has been of tremendous help) but now I see that it
> "freezes" on activate sync. The following is from log.bucardo:
> (4138) [Fri Jun 14 14:49:56 2013] MCP Created VAC 5154
> (5154) [Fri Jun 14 14:49:56 2013] VAC New VAC daemon. PID=5154
> (5154) [Fri Jun 14 14:49:56 2013] VAC Warning! VAC was killed at line 4729:
> DBD::Pg::db do failed: ERROR: invalid value for parameter "search_path":
> "bucardo,bucardo, public"
> DETAIL: schema "bucardo" does not exist at /usr/share/perl5/Bucardo.pm
> line 4729.
> Can't call method "disconnect" without a package or object reference at
> /usr/share/perl5/Bucardo.pm line 6336.
> Issuing rollback() due to DESTROY without explicit disconnect() of
> DBD::Pg::db handle dbname=bucardo;port=5432;host=localhost at
> /usr/share/perl5/Bucardo.pm line 4729.
>
> anyone has an idea what might be the probable cause?
>
>
> On Fri, Jun 14, 2013 at 3:49 PM, Athanasios Kostopoulos <
> athanasios.kostopoulos at classmarkets.com> wrote:
>
>> 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.
>>>
>>>
>>>
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/305e0e2a/attachment.html>
More information about the Bucardo-general
mailing list