Re: Proposal: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Proposal: Implement failover on libpq connect level.
Date
Msg-id 20150820.001735.1312191060652873768.t-ishii@sraoss.co.jp
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
Responses Re: Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
List pgsql-hackers
> Here we are discussing load-balancing on the client level, not on the
> statement level.

I see.

> Suppose that we have 100 readonly clients and 3 standby servers + master.
> If all clients specify all four servers in the their connect strings,
> and connect randomly to them, each server would have approximately 25
> clients.
> 
> But once connection is established, each client works with one
> server (at least until communication failure occurs and it would call
> PQreset. In this case it has to reprepare statements anyway).

One downside of this is, if one of the standby servers is not
responding, every time clients will be blocked by the server before
giving up the connection trial. This could last for hours (for
example, the network cable is plugged out). I think round robin DNS is
better because the DNS server will drop the entry corresponding broken
server (or any solution which has similar capability). After all, this
type of client side solutions are not very stable in a real world
environment IMO (I heard the same opinion regarding HAProxy).

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Next
From: Kevin Grittner
Date:
Subject: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows