Re: bdr_init_copy fails when starting 2nd BDR node

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: John Casey <john(dot)casey(at)innovisors(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: bdr_init_copy fails when starting 2nd BDR node
Date: 2015-01-19 11:07:54
Message-ID: CAMsr+YGTzsBX+by5enyS8Vdz1kYJqMF-YtVNP=M=xHrHjtbpHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 4 January 2015 at 02:52, John Casey <john(dot)casey(at)innovisors(dot)com> wrote:

> I'm still experiencing similar problems. I'm not certain what parameter you
> are referring to when you say 'ehost'. Otherwise, I did want to clarify a
> couple of things. I have tried several combinations, each one fails in
> various ways. So ...
>
> (1) What is the exact syntax when calling bdr_init_copy from new nodes when
> your database name is not 'postgres' and your user name is not 'postgres'.
> Please note if you supply local or remote host/port in the command.
>

Use a connection string to identify the remote and the local ends. e.g.:

bdr_init_copy --remote-dbname="host=node1 dbname=mydb" \
--local-dbname="dbname=mydb" \
-D datadir

Both --remote-dbname and --local-dbname are libpq connection strings.

> (2) Should you do a pg_ctl start on new node before trying to execute
> bdr_init_copy. If I don't I get the error I posted earlier.

No, you should not and must not start the server before running
bdr_init_copy.

(In the current development version of BDR this has all gone away, and
bdr_init_copy will make a base backup for you).

In response to

Browse pgsql-general by date

  From Date Subject
Next Message François Beausoleil 2015-01-19 11:58:21 Re: Partitioning
Previous Message Kyotaro HORIGUCHI 2015-01-19 11:00:51 Re: Partitioning