| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info> |
| Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: High Availability: Hot Standby vs. Warm Standby |
| Date: | 2010-07-12 16:16:40 |
| Message-ID: | 4C3B3FE8.1030409@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Brad Nicholson wrote:
> One further thing to mention - all of these solutions are based on
> making the physical blocks available (actually, I'm not sure about
> Streaming replication in 9.0).
You're right here; the SR feature in 9.0 is essentially near real-time
partial WAL file shipping, and the WAL contains physical disk block
change data. If your master has data blocks corrupted, the next time
you do a base backup against it that corruption will be mirrored to the
standby too. I've mentioned on one of these lists recently that I like
to schedule a periodic pg_dump even if log shipping is the main backup
mechanism for a database, just so that corruption in the underlying
files is caught as early as possible by trying to read every block and
confirm it has valid data.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Kellerer | 2010-07-13 07:11:28 | Re: High Availability: Hot Standby vs. Warm Standby |
| Previous Message | Greg Smith | 2010-07-12 16:11:42 | Re: High Availability: Hot Standby vs. Warm Standby |