Re: Proposal: Implement failover on libpq connect level.

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема Re: Proposal: Implement failover on libpq connect level.
Дата
Msg-id 20150820.001735.1312191060652873768.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
Ответы Re: Proposal: Implement failover on libpq connect level.  (Victor Wagner <vitus@wagner.pp.ru>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: Bug? ExecChooseHashTableSize() got assertion failed with crazy number of rows