Re: Postgres Replication - Mailing list pgsql-general

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
>