Thread: pg_basebackup WAL -- invalid pages

pg_basebackup WAL -- invalid pages

From
"Darron"
Date:

Running PostgreSQL 9.2.1 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.4.5-8) 4.4.5, 64-bit

 

Having some issues with streaming replication. After creating a basebackup with pg_basebackup, I get the following in the logs when starting the backup as a steaming hot standby.

 

2012-12-03 20:27:08 GMT  21494  dLOG:  database system was interrupted while in recovery at log time 2012-11-29 21:32:38 GMT

2012-12-03 20:27:08 GMT  21494  dHINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.

2012-12-03 20:27:08 GMT  21494  dLOG:  entering standby mode

2012-12-03 20:27:08 GMT  21494  dDEBUG:  checkpoint record is at 1C/E28B7978

2012-12-03 20:27:08 GMT  21494  dDEBUG:  redo record is at 1C/E2000020; shutdown FALSE

2012-12-03 20:27:08 GMT  21494  dDEBUG:  next transaction ID: 0/1903870; next OID: 249837974

2012-12-03 20:27:08 GMT  21494  dDEBUG:  next MultiXactId: 1; next MultiXactOffset: 0

2012-12-03 20:27:08 GMT  21494  dDEBUG:  oldest unfrozen transaction ID: 673, in database 1

2012-12-03 20:27:08 GMT  21494  dDEBUG:  transaction ID wrap limit is 2147484320, limited by database with OID 1

2012-12-03 20:27:08 GMT  21494  dDEBUG:  resetting unlogged relations: cleanup 1 init 0

2012-12-03 20:27:08 GMT  21494  dDEBUG:  initializing for hot standby

2012-12-03 20:27:08 GMT  21494  dLOG:  consistent recovery state reached at 1C/E28B79D8

2012-12-03 20:27:08 GMT  21494  dLOG:  redo starts at 1C/E2000020

2012-12-03 20:27:08 GMT  21494  dDEBUG:  recovery snapshots are now enabled

2012-12-03 20:27:08 GMT  21494  dCONTEXT:  xlog redo  running xacts: nextXid 1903870 latestCompletedXid 1903869 oldestRunningXid 1903870

2012-12-03 20:27:08 GMT  21492  dLOG:  database system is ready to accept read only connections

2012-12-03 20:27:09 GMT  21494  dWARNING:  page 27 of relation base/103111746/231701662 does not exist

2012-12-03 20:27:09 GMT  21494  dCONTEXT:  xlog redo visible: rel 1663/103111746/231701662; blk 27

2012-12-03 20:27:09 GMT  21494  dPANIC:  WAL contains references to invalid pages

2012-12-03 20:27:09 GMT  21494  dCONTEXT:  xlog redo visible: rel 1663/103111746/231701662; blk 27

2012-12-03 20:27:09 GMT  21492  dLOG:  startup process (PID 21494) was terminated by signal 6: Aborted

2012-12-03 20:27:09 GMT  21492  dLOG:  terminating any other active server processes

2012-12-03 20:27:09 GMT  21493  dDEBUG:  logger shutting down

 

The Autovacumm launcher is running on the master postgres server, would that cause issues with pg_basebackup. Any ideas what the problem could be?

 

Thanks,

 

Darron

 



I am using the Free version of SPAMfighter.
SPAMfighter has removed 2 of my spam emails to date.

Do you have a slow PC? Try free scan!

Re: pg_basebackup WAL -- invalid pages

From
Lonni J Friedman
Date:
On Mon, Dec 3, 2012 at 12:44 PM, Darron <darron@realtyserver.com> wrote:
> Running PostgreSQL 9.2.1 on x86_64-unknown-linux-gnu, compiled by gcc
> (Debian 4.4.5-8) 4.4.5, 64-bit
>
>
>
> Having some issues with streaming replication. After creating a basebackup
> with pg_basebackup, I get the following in the logs when starting the backup
> as a steaming hot standby.
>
>
>
> 2012-12-03 20:27:08 GMT  21494  dLOG:  database system was interrupted while
> in recovery at log time 2012-11-29 21:32:38 GMT
>
> 2012-12-03 20:27:08 GMT  21494  dHINT:  If this has occurred more than once
> some data might be corrupted and you might need to choose an earlier
> recovery target.
>
> 2012-12-03 20:27:08 GMT  21494  dLOG:  entering standby mode
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  checkpoint record is at 1C/E28B7978
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  redo record is at 1C/E2000020;
> shutdown FALSE
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  next transaction ID: 0/1903870;
> next OID: 249837974
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  next MultiXactId: 1; next
> MultiXactOffset: 0
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  oldest unfrozen transaction ID:
> 673, in database 1
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  transaction ID wrap limit is
> 2147484320, limited by database with OID 1
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  resetting unlogged relations:
> cleanup 1 init 0
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  initializing for hot standby
>
> 2012-12-03 20:27:08 GMT  21494  dLOG:  consistent recovery state reached at
> 1C/E28B79D8
>
> 2012-12-03 20:27:08 GMT  21494  dLOG:  redo starts at 1C/E2000020
>
> 2012-12-03 20:27:08 GMT  21494  dDEBUG:  recovery snapshots are now enabled
>
> 2012-12-03 20:27:08 GMT  21494  dCONTEXT:  xlog redo  running xacts: nextXid
> 1903870 latestCompletedXid 1903869 oldestRunningXid 1903870
>
> 2012-12-03 20:27:08 GMT  21492  dLOG:  database system is ready to accept
> read only connections
>
> 2012-12-03 20:27:09 GMT  21494  dWARNING:  page 27 of relation
> base/103111746/231701662 does not exist
>
> 2012-12-03 20:27:09 GMT  21494  dCONTEXT:  xlog redo visible: rel
> 1663/103111746/231701662; blk 27
>
> 2012-12-03 20:27:09 GMT  21494  dPANIC:  WAL contains references to invalid
> pages
>
> 2012-12-03 20:27:09 GMT  21494  dCONTEXT:  xlog redo visible: rel
> 1663/103111746/231701662; blk 27
>
> 2012-12-03 20:27:09 GMT  21492  dLOG:  startup process (PID 21494) was
> terminated by signal 6: Aborted
>
> 2012-12-03 20:27:09 GMT  21492  dLOG:  terminating any other active server
> processes
>
> 2012-12-03 20:27:09 GMT  21493  dDEBUG:  logger shutting down
>
>
>
> The Autovacumm launcher is running on the master postgres server, would that
> cause issues with pg_basebackup. Any ideas what the problem could be?

autovacuum is definitely not the cause of this.  That's a default
setting, and if it was problematic with pg_basebackup it would be well
documented.

Are you certain that the pg_basebackup ran successfully to completion?
Can you provide the exact command options you used when running it?
Are all the postgres servers running the same version of postgresql
with the same OS version?
Can you document the exact steps you took when extracting the
basebackup on the server?