On Thu, Sep 8, 2011 at 20:40, Thom Brown <thom@linux.com> wrote:
> Hi all,
>
> I've come across a PostgreSQL set up where there are 2 servers, each
> with the same version of PostgreSQL on, both mounting the same SAN
> onto their respective file systems. It was intended that only 1 of
> the servers would be running an instance of PostgreSQL at a time as
> they both point to the same pgdata. This was dubbed a "high
<snip>
> Would there be a way to prevent this abhorrent scenario from coming
> into existence? One idea is to have a configuration option to be
> strict about the presence of a pid file in the data directory, and
> force manual intervention, but I'm not sure this would solve the
> problem in most cases where this problem exists as someone would have
> had to specifically sought out the option and set it. It might also
> encourage some to just delete the pid file thinking that would make
> the nasty errors go away.
There are plenty of clustering products out there that are really
designed for one thing pimarily, and that's dealing with this kind of
fencing. The proper solution is to use one of those. There's no way we
can do what's required from inside postgresql, and I see no reason why
we should re-invent generic clustering software. (for example, if you
do this, we can't prevent the two kernels from corrupting the
filesystem on the shared storage, which we rely on working..)
Such software is often marketed as an "easy way to set up high
availability". It's easy to set up. It requires some actual expertise
to set up *right*. But once you've done that, it works well, and it
prevents this kind of situation to happen.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/