From: | Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com> |
---|---|
To: | Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Implement failover on libpq connect level. |
Date: | 2015-08-18 16:53:28 |
Message-ID: | CAJGNTeNb8jsEy3soYC-Pv0gvrz5+Jy--BTz9vBbBCvxC1uxMBw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-jdbc |
On 17 August 2015 at 23:18, Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> 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.
>
This is not completely true, you can always use something like
pgbouncer or other middleware to change the server to which clients
connect. you still need to solve the fact that you will have a
read-only server at the other side.
something like repmgr + pgbouncer will work fine.
i agree that once/if we ever have multimaster included then this could
be a good idea
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-18 17:01:29 | Re: Proposal: Implement failover on libpq connect level. |
Previous Message | Robert Haas | 2015-08-18 16:47:28 | Re: WIP: SCRAM authentication |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-18 17:01:29 | Re: Proposal: Implement failover on libpq connect level. |
Previous Message | Robert Haas | 2015-08-18 16:37:58 | Re: Proposal: Implement failover on libpq connect level. |