Re: Shared disk storage

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Bruno Wolff III <bruno(at)wolff(dot)to>, Peter Nixon <listuser(at)peternixon(dot)net>, pgsql-general(at)postgresql(dot)org
Subject: Re: Shared disk storage
Date: 2005-09-06 22:01:41
Message-ID: 20050906220141.GY60481@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Sep 06, 2005 at 02:58:52PM -0500, Bruno Wolff III wrote:
> On Tue, Sep 06, 2005 at 13:47:42 -0500,
> "Jim C. Nasby" <jnasby(at)pervasive(dot)com> wrote:
> > On Tue, Sep 06, 2005 at 10:13:33AM -0500, Bruno Wolff III wrote:
> > > On Mon, Sep 05, 2005 at 12:20:24 +0300,
> > > Peter Nixon <listuser(at)peternixon(dot)net> wrote:
> > > > Hi List
> > > >
> > > > Does anyone have any comments, HOWTOs and experience running multiple
> > > > Postgres servers with a shared disk (SAN) in a Hot standby configuration?
> > > >
> > > > Can someone please point me in the direction of any docs on this subject?
> > >
> > > Be sure to have some failsafe to prevent two servers from running at the
> > > same time on the same data. If that ever happens your database will be hosed.
> >
> > I thought PostgreSQL already had such a safeguard? Or is it only against
> > starting two backends against the same PGDATA on the same machine?
>
> Yes, but it is more likely to have problems when there are two machines
> involved. One is that the file may not be on the cross mounted file
> system (on FC4 it is in /var/run) and even if it is on the cross mounted
> file system, there is a good chance the lock file will appear to be stale
> because the process id is for the other machine. I am not sure if there are
> other gotchas, but you definitely want to be careful, since a mistake is
> going to defeat the purpose of having the hot spares.

Maybe it would be better to keep this in PGDATA (or even a duplicate
copy). Holding a write lock on the file should also help ensure that you
can tell if it's stale or not.

I realize this probably still isn't perfect, but it's probably better
than forcing users to find an external means of locking out the other
backend.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-09-06 22:05:38 Re: SLOOOOOOOW
Previous Message Ian Harding 2005-09-06 21:51:42 Re: SLOOOOOOOW