> On 18 Aug 2015, at 10:32, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>
> Victor Wagner wrote:
>> Rationale
>> =========
>>
>> Since introduction of the WAL-based replication into the PostgreSQL, it is
>> possible to create high-availability and load-balancing clusters.
>>
>> However, there is no support for failover in the client libraries. So, only
>> way to provide transparent for client application failover is IP address
>> migration. This approach has some limitation, i.e. it requires that
>> master and backup servers reside in the same subnet or may not be
>> feasible for other reasons.
>>
>> Commercial RDBMS, such as Oracle, employ more flexible approach. They
>> allow to specify multiple servers in the connect string, so if primary
>> server is not available, client library tries to connect to other ones.
>>
>> This approach allows to use geographically distributed failover clusters
>> and also is a cheap way to implement load-balancing (which is not
>> possible with IP address migration).
>
> I wonder how useful this is at the present time.
>
> If the primary goes down and the client gets connected to the standby,
> it would have read-only access there. Most applications wouldn't cope
> well with that.
>
> Once we have multi-master replication that can be used for fail-over,
> the picture will change. Then a feature like that would be very useful indeed.
>
>> "host=main-server host=standby1 host=standby2 port=5432 dbname=database"
>
> It seems a bit arbitrary to require that all servers use the same port.
>
> Maybe parameters like host2, port2, host3, port3 etc. might be better.
>
> Yours,
> Laurenz Albe
i totally agree with laurenz.
in addition to that you have the “problem” of transactions. if you failover in the middle
of a transaction, strange things might happen from the application point of view.
the good thing, however, is that stupid middleware is sometimes not able to handle
failed connections. however, overall i think it is more of a danger than a benefit.
regards,
hans
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
