From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Arnaud Lesauvage" <thewild(at)freesurf(dot)fr> |
Cc: | "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "Postgres general mailing list" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL and Windows 2003 DFS Replication |
Date: | 2006-07-28 20:30:56 |
Message-ID: | b42b73150607281330i71de468ch438a776f966c6c96@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/28/06, Arnaud Lesauvage <thewild(at)freesurf(dot)fr> wrote:
> Csaba Nagy wrote:
> > I found that PITR using WAL shipping is not protecting against all
> > failure scenarios... it sure will help if the primary machine's hardware
> > fails, but in one case it was useless for us: the primary had a linux
> > kernel with buggy XFS code (that's what I think it was, cause we never
> > found out for sure) and we did use XFS for the data partition, and at
> > one point it started to get corruptions at the data page level. The
> > corruption was promptly transferred to the standby, and therefore it was
> > also unusable... we had to recover from a backup, with the related
> > downtime. Not good for business...
> >
> OK, but corruption at the data page level is a very unlikely
> event, isn't it ?
yes, and that is not a pitr problem, that is a data corruption
problem. i am very suspicious that slony style replication would
provide any sort of defense against replicating from a machine which
is changing bytes from a to b, etc. i think the best defense against
*that* sort of problem would be synchronous replication via pgpool.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-07-28 20:30:57 | Re: Questions about update, delete, ctid... |
Previous Message | gustavo halperin | 2006-07-28 17:41:12 | Re: automatic and randomally population |