On 2015.08.19 at 08:28:32 +0530, Amit Kapila wrote:
> On Tue, Aug 18, 2015 at 9:48 AM, Victor Wagner <vitus@wagner.pp.ru> wrote:
> >
> >
> > Behavoir
> > --------
> >
> > If PQconnectdb encounters connect string with multiple hosts specified,
> > it attempts to establish connection with all these hosts simultaneously,
> > and begins to work with server which responds first, unless
> > loadbalancing parameter is true.
> >
> >
> I think here you are mixing the behaviour for load balancing solution and
> failover solution. It seems to me that for client-side failover solution
> (which is also known as Transparent Application Failover), the connection
> attempt to second server should be done after the first connection is
> broken as that provide more flexibility.
I think that failover procedure should begin before first connection is
ever established.
When client application starts, it has no way of knowing current state
of the server cluster - which of servers is working as master now.
Application uses connect string, placed into its configuration file
long time ago, and changing this configuration might require special
permissions, user of application doesn't have. But user typically know
how to restart application or reboot his terminal. So, for the
spatially distributed networks with thick clients we can handle only
initial connections, not connection resets. At least application author
always can implement restoration of connection as closing old
connection and establishing new.
So, when application first establishes connection it have to be prepared
to connect any of alternate hosts.
I don't think that making connections in sequential order provide big
flexibility. But it can greatly increase startup time, because connect
to host which is physically down fails after significant timeout. While
application waits for first connect to fail, it might complete session
initialization with working server several times.
Of course, connecting to servers in sequential order is simpler to
implement, and allows even more mixing of load balancing with failover,
because code would be same.
> Although both ideas (load balancing and failover) seems worth discussing,
> they are separate features and can be worked on separately. It will be
> easier to sort out the details as well that way.
Really load balancing comes almost for free if we implement connect to
alternate server for failover purposes. I'm not sure that in case of hot
standby, where only readonly transactions can be loadbalanced,
loadbalancing is very useful. And included it in the proposal only
because it is very cheap to implement in this form,
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
