Re: pg 8.3 replication causing corruption - Mailing list pgsql-general

From Bob Hatfield
Subject Re: pg 8.3 replication causing corruption
Date
Msg-id CAKikJcK2GCcXVKkXpbP3cod9h54aGcDTa00DtGVnG-f4kea_gQ@mail.gmail.com
Whole thread Raw
In response to Re: pg 8.3 replication causing corruption  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: pg 8.3 replication causing corruption
List pgsql-general
>> Should replication cause corruption on the secondary when stopping/starting
>> the primary?  (pg 8.3.12, windows 2008 R2 on both servers)
>
> No, it shouldn't. Any duplicate keys would represent a serious error.
>
> It sounds like you're using warm standby, but when you say run
> pg_start_backup() AFTER each nightly backup I admit to being confused.
>

Thanks for your response. Perhaps a quick process flow would help clarify:

Scenario 1 (no errors):
a) create warm standby and let run throughout the day (works great)
b) at the end of the day, trigger the secondary and run a reindex for
testing (no errors)

Scenario 2 (errors):
a) create warm standby and let run throughout the day (works great)
b) nightly backup: shutdown pg on primary, do a file system copy (for
backup later), start pg again on primary
c) the next morning, trigger the secondary and run a re-index for
testing (ERRORS as described in thread)

Side note: the data copied in 2.b is fine and also passes a full re-index.

Scenario 3 (work around - not a very good one):
a) create warm standby and let run throughout the day (works great)
b) nightly backup: shutdown pg on primary, do a file system copy (for
backup later), start pg again on primary
c) the next morning, re-create the warm standby  (this is where I may
have confused you with doing a pg_start_backup after nightly backups)

Thanks!

pgsql-general by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Are file system level differential/incremental backups possible?
Next
From: Ondrej Ivanič
Date:
Subject: Re: Drill-downs and OLAP type data