Look into heartbeat:
http://www.linux-ha.org/HeartbeatProgram
The idea is that you have a virtual address to be "the database", and that
the primary server configures itself for this address as well as whatever
address it would normally have. Then, when you want to switch servers
(maybe because the primary has died, or because you want to do some
maintenance to keep it from dying) the second server takes over the
database address with a bunch of ARP packets. Your application sees its
postgres connections have died and so gracefully (right?) tries to
reconnect, and as long as the primary server is no longer trying to regain
control of that virtual address (which it usually isn't, because either
you've configured it not to or because it's dead) then everything proceeds
just fine on the backup server.
On Wed, 10 Jan 2007, dcrespo wrote:
Thank you, Ben, for your reply.
I have read the FAQ of DRBD, but I'm still wondering how an application
accessing a database server knows when to switch to the mirror (setting
this one as the master). I think I should have an application that
provides the connection transparently which determines where to
connect. But for that, it must be running in another computer besides
the cluster (the two computers).
I'm a newbie, so maybe this was a newbie question message.
Thanks
Daniel
Ben wrote:
If you only want to use one database at a time you might look into using
DRBD. It's a linux block-level package that is like raid-1 over the
network.
On Tue, 9 Jan 2007, dcrespo wrote:
Hi everybody,
I have two computers with a Postgres Database each. I want one of them
to be the replica of the other one; let's say I want a Master to Master
replication in order to use either one (but only one at a time) as the
main database: in case of failure, switch. The ideal synchronization
way would be Synchronous. However, these two computers are going to be
next to each other, so the asynchronous synchronization would be fast
enough (I don't really know. Can you tell so?) for the case synchronous
sync is not available.
What I have found so far is Daffodil and Slony-I. Daffodil's name
doesn't even appear in Postgresql.org, which is not the case for
Slony-I. So there's a big point in favor to Slony-I.
Has anybody researched on this that can point me in the right
direction?
Thanks a lot,
Daniel Crespo
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
