|
Home > Archive > PostgreSQL Administration > October 2006 > Re: postgres in HA constellation
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: postgres in HA constellation
|
|
| Sebastian Reitenbach 2006-10-25, 8:24 am |
| Hi all,
>
> I think PITR would be a much better option to protect against this,
> since you could probably recover up to the exact point of failover.
>
> When it comes to the actual failover, take a look at the HA-linux
> project. They've got some stuff you could probably use (such as the
> heartbeat program). Another really good idea is to give the backup
> machine to kill the power to the primary machine, and not have either
> machine mount the shared storage at bootup.
As I am using carp on OpenBSD to setup HA cluster, I am very comfortable with
ucarp, the userland implementation for Linux. at boot up the default mount of
the database files is readonly and having the database not running, then
starting ucarp, and then only in case this machine becomes master, it remounts
the postgres data and shall start the database.
And I thought about that killing the power of the "lost" master after a
takeover too, to make sure hte machine will not come back unconditionally
later.
kind regards
Sebastian
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Jim C. Nasby 2006-10-25, 8:24 am |
| On Fri, Oct 06, 2006 at 06:34:25AM -0000, Sebastian Reitenbach wrote:
> As I am using carp on OpenBSD to setup HA cluster, I am very comfortable with
> ucarp, the userland implementation for Linux. at boot up the default mount of
> the database files is readonly and having the database not running, then
> starting ucarp, and then only in case this machine becomes master, it remounts
> the postgres data and shall start the database.
> And I thought about that killing the power of the "lost" master after a
> takeover too, to make sure hte machine will not come back unconditionally
> later.
Heh, I'd assumed you were on linux, but of course there's no reason you
couldn't setup HA on OpenBSD. The key is just to make sure that you
never bring up two servers on the same data directory.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
| |
| Andrew Sullivan 2006-10-25, 8:24 am |
| On Tue, Oct 10, 2006 at 10:11:08AM -0500, Jim C. Nasby wrote:
> couldn't setup HA on OpenBSD. The key is just to make sure that you
> never bring up two servers on the same data directory.
I think this highlights exactly what I'm trying to emphasise: in
actual, shared-nothing systems like this, there's no possible
guarantee of "never". There are possible guarantees of "very
rarely". The problem is, you're already trying to address a teeny
portion of the likely events on your machines. So you have to assume
that more than one thing might break at the same time, and have a
recovery plan for it. I submit that a recovery plan of "restore from
pg_dump" is usually not going to be enough if it was worth the cost
and hassle of setting up shared disk failover. YMMV, of course.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The fact that technology doesn't work is no bar to success in the marketplace.
--Philip Greenspun
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
|
|
|
|
|