Thread: PostgreSQL in a shared-disk enviroment

PostgreSQL in a shared-disk enviroment

From
th240265@pegasus.cc.ucf.edu
Date:
First time on any mailing list, hope this gets done right :-)

I am putting together a system at work, clustered w/ a san. The cluster will be
managed by SuSE Linux Enterprise Server.

I am curious as to what I can eek out of postgre in this kind of enviroment. My
main concern would be failover, though load balancing would be a nice-to-have.

My first thought is this (for failover).
One primary machine, one failover.
Primary machine is nothing particularily special. Running w/ fsync = true
(which, correct me if I'm wrong, guarantees that by the time the db reports a
txn as finished, the txn is guaranteed to be on the disk & in the db).
Failover has a heartbeat monitor on the primary, if the primary goes down, the
failover starts up postgre (which then recovers the db, throws out bad txn's,
etc.) & takes over the primary's IP address. Notice here that postgre is NOT
running on the failover machine until the primary goes down.
Clients have a little extra code to wait if they can't connect to the db & see
if the failover comes up before kicking everyone out (client is custom, so no
problem there).

Perhaps not the best solution, but I know (?) it'll work. Maybe 10-20 seconds of
downtime in the case of a machine failure. Feel free to let me know of any
problems you see in that idea.

My questions are:
Can I do a hot-failover (keep postgre running on the failover machine and simply
let the failover take over the primary's IP w/out skipping a beat)?
Can I do a little load-balancing (failover as query-only, primary as
query/write. Put a little code into the client program to choose the db to use)?
Any other things I need to keep in mind when running two instances of postgre on
the same db? (Do I need to keep WAL's seperate or combined. Should they share
config files? Is running two instances of postgre on the same db just a really
bad idea & I should stick to what I know will work above?)

At this stage of the game, I'm not terribly interested in commercial
solutions/replication/etc. If I have to stick to my first scenario, that is fine
for the time being.

Any thoughts?

Thanks!
Thomas Meeks


Re: PostgreSQL in a shared-disk enviroment

From
Tom Lane
Date:
th240265@pegasus.cc.ucf.edu writes:
> Primary machine is nothing particularily special. Running w/ fsync = true
> (which, correct me if I'm wrong, guarantees that by the time the db reports a
> txn as finished, the txn is guaranteed to be on the disk & in the db).
> Failover has a heartbeat monitor on the primary, if the primary goes down, the
> failover starts up postgre (which then recovers the db, throws out bad txn's,
> etc.) & takes over the primary's IP address. Notice here that postgre is NOT
> running on the failover machine until the primary goes down.

This will work; it's not different from the normal crash/restart scenario.

> Can I do a hot-failover (keep postgre running on the failover machine and simply
> let the failover take over the primary's IP w/out skipping a beat)?

This will NOT work.

> Any other things I need to keep in mind when running two instances of postgre on
> the same db?

There's only one thing to keep in mind: don't try it.

BTW, "Postgres" is spelled and pronounced "Postgres", not "postgre".

            regards, tom lane