contrecord is requested

Started by Scott Marloweover 8 years ago4 messagesgeneral
Jump to latest
#1Scott Marlowe
scott.marlowe@gmail.com

So we have a db we're trying to rewind and get synced to the master.
pg_rewind says it doesn't need rewinding, and when we try to bring it
up, it gets this error:

"contrecord is requested by 2E7/40000028"

And fails to get back up.

Is this a known issue? Possible bug in the continuation record code?

The only references I can find for it are in the xlogreader code.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2Michael Paquier
michael@paquier.xyz
In reply to: Scott Marlowe (#1)
Re: contrecord is requested

On Tue, Sep 12, 2017 at 5:27 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

So we have a db we're trying to rewind and get synced to the master.
pg_rewind says it doesn't need rewinding, and when we try to bring it
up, it gets this error:

"contrecord is requested by 2E7/40000028"

And fails to get back up.

The consistency recovery point defined by pg_rewind was not reached then.

Is this a known issue?

Never heard of this one.

Possible bug in the continuation record code?

That looks like a possibility. This complains is about the fact that
the XLOG page header cannot be found where it should. You may want to
check your WAL segments.
--
Michael

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#3Jeff Janes
jeff.janes@gmail.com
In reply to: Scott Marlowe (#1)
Re: contrecord is requested

On Mon, Sep 11, 2017 at 1:27 PM, Scott Marlowe <scott.marlowe@gmail.com>
wrote:

So we have a db we're trying to rewind and get synced to the master.
pg_rewind says it doesn't need rewinding, and when we try to bring it
up, it gets this error:

"contrecord is requested by 2E7/40000028"

And fails to get back up.

Is this a known issue? Possible bug in the continuation record code?

The only references I can find for it are in the xlogreader code.

I've seen this twice lately and both times it was user error.

One time someone who shall remain nameless made a replica of a remote QA
server using "pg_basebackup -R ...", but then copied the *.conf files
**including recovery.conf** from the running replica of the the remote
production server into the new directory for the replica of the remote QA
server. So primary_conninfo had been overwritten to point to the wrong
master server.

The other time someone who shall also remain nameless accidentally fully
opened up a newly cloned (from a cold backup, I think) of an dummy
benchmarking server, instead of putting it into standby. And then tried to
shut it down and re-open it as a standby without doing a full refresh. But
of course it was too late to do that.

Cheers,

Nameless

#4Scott Marlowe
scott.marlowe@gmail.com
In reply to: Jeff Janes (#3)
Re: contrecord is requested

On Tue, Sep 12, 2017 at 10:19 AM, Jeff Janes <jeff.janes@gmail.com> wrote:

On Mon, Sep 11, 2017 at 1:27 PM, Scott Marlowe <scott.marlowe@gmail.com>
wrote:

So we have a db we're trying to rewind and get synced to the master.
pg_rewind says it doesn't need rewinding, and when we try to bring it
up, it gets this error:

"contrecord is requested by 2E7/40000028"

And fails to get back up.

Is this a known issue? Possible bug in the continuation record code?

The only references I can find for it are in the xlogreader code.

I've seen this twice lately and both times it was user error.

One time someone who shall remain nameless made a replica of a remote QA
server using "pg_basebackup -R ...", but then copied the *.conf files
**including recovery.conf** from the running replica of the the remote
production server into the new directory for the replica of the remote QA
server. So primary_conninfo had been overwritten to point to the wrong
master server.

The other time someone who shall also remain nameless accidentally fully
opened up a newly cloned (from a cold backup, I think) of an dummy
benchmarking server, instead of putting it into standby. And then tried to
shut it down and re-open it as a standby without doing a full refresh. But
of course it was too late to do that.

Thanks will check on that.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general