Re: Weird error when setting up streaming replication

From: Quentin Hartman <qhartman(at)direwolfdigital(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Weird error when setting up streaming replication
Date: 2013-08-09 16:54:41
Message-ID: CAJ48qNYWbnfn4jE5Y+FZuxO9D0xYzKweb1-t7m9WSAxNdCTZ8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

OK, figured this out. I had it start copying the pg_xlog directory as well
when doing the initial sync. I realized this is also the first time I've
setup replication from scratch using 9.2. All my other 9.2 pairs were setup
on either 9.0 or 9.1, and have been upgraded from there with replication
already in place. Previously, and still according to that article in the
wiki, the pg_xlog directory was specifically excluded. Does anyone know why
this behavior may have changed?

On Fri, Aug 9, 2013 at 9:33 AM, Quentin Hartman <
qhartman(at)direwolfdigital(dot)com> wrote:

> This pair of servers aren't replacing anything, they are new, empty
> servers. Before starting the slave at all, I'm copying the entire data
> filestructure over to it via rsync. I'm doing almost exactly what is
> described here:
> http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial#Binary_Replication_in_6_Steps. The only different is that I've tweaked the paths on the rsync to be
> appropriate to my system layout. I've even gone so far as to delete
> everything in the data dir except for the pg_xlog directory before syncing
> everything over to make sure it wasn't caused by something not getting
> overwritten when it was supposed to.
>
>
> On Thu, Aug 8, 2013 at 6:23 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> > wrote:
>
>> On Fri, Aug 9, 2013 at 8:55 AM, Quentin Hartman
>> <qhartman(at)direwolfdigital(dot)com> wrote:
>> > 2013-08-08 23:47:30 GMT LOG: WAL file is from different database system
>> > 2013-08-08 23:47:30 GMT DETAIL: WAL file database system identifier is
>> > 5909892614333033983, pg_control database system identifier is
>> > 5909892824786287231.
>> It looks that you are not able to detect valid checkpoint records when
>> replaying WAL because your new system has been initialized with a
>> fresh initdb, symbolized by the errors above. You should build your
>> new node using a base backup or a snapshot of the data folder of the
>> node you are trying to replace.
>> --
>> Michael
>>
>
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Don Parris 2013-08-09 16:56:02 Re: How To Install Extension Via Script File?
Previous Message Kevin Grittner 2013-08-09 16:06:22 Re: How to avoid Force Autovacuum