special procedure required when running pg_basebackup from a standby?

From: Lonni J Friedman <netllama(at)gmail(dot)com>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: special procedure required when running pg_basebackup from a standby?
Date: 2013-01-14 02:05:01
Message-ID: CAP=oouFA5JyH=QcEvugtEfy=goHm-Z+tDvH0RfftCT+7S-B-Bg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greetings,
I'm running postgres-9.2.2 in a Linux-x86_64 cluster with 1 master and
several hot standby servers. Since upgrading to 9.2.2 from 9.1.x a
few months ago, I switched from generating a base backup on the
master, to generating it on a dedicated slave/standby (to reduce the
load on the master). The command that I've always used to generate
the base backup is:
pg_basebackup -v -D /tmp/bb0 -x -Ft -U postgres

However, I've noticed that whenever I use the base backup generated
from the standby to create a new standby server, many of the indexes
are corrupted. This was never the case when I was generating the
basebackup directly from the master. Now, I see errors similar to the
following when running queries against the tables that own the
indexes:
INDEX "debugger_2013_01_dacode_idx" contains unexpected zero page at block 12
HINT: Please REINDEX it.
INDEX "smoke32on64tests_2013_01_suiteid_idx" contains unexpected zero
page at block 111
HINT: Please REINDEX it.

I've confirmed that the errors/corruption doesn't exist on the server
that is generating the base backup (I can run the same SQL query which
fails on the new standby, successfully). Also reindexing the index
does fix the problem. So it seems that I'm potentially
misunderstanding some part of the process. My setup process is to
simply untar the basebackup in the $PGDATA directory, and copy over
all the WAL logs into $PGDATA/pg_xlog.

thanks for any pointers.

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2013-01-14 02:22:50 Re: INSERT... WHERE
Previous Message Robert James 2013-01-14 02:00:39 INSERT... WHERE