Postgres Pro
Downloads
Home   >   mailing lists

Re: Weird error when setting up streaming replication - Mailing list pgsql-general

From Quentin Hartman
Subject Re: Weird error when setting up streaming replication
Date
Msg-id CAJ48qNYWbnfn4jE5Y+FZuxO9D0xYzKweb1-t7m9WSAxNdCTZ8A@mail.gmail.com
Whole thread Raw
In response to Re: Weird error when setting up streaming replication  (Quentin Hartman <qhartman@direwolfdigital.com>)
Responses Re: Weird error when setting up streaming replication  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
Tree view
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@direwolfdigital.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.paquier@gmail.com> wrote:
On Fri, Aug 9, 2013 at 8:55 AM, Quentin Hartman
<qhartman@direwolfdigital.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


pgsql-general by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: How to avoid Force Autovacuum
Next
From: Don Parris
Date:
Subject: Re: How To Install Extension Via Script File?