Re: hostorder and failover_timeout for libpq
| От | Ildar Musin |
|---|---|
| Тема | Re: hostorder and failover_timeout for libpq |
| Дата | |
| Msg-id | CAONYFtPL=v8M=rfc3MwE8gF1zwfQEUAa21qXVJFutFs3Oe0ksA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: hostorder and failover_timeout for libpq (Surafel Temesgen <surafel3000@gmail.com>) |
| Ответы |
Re: hostorder and failover_timeout for libpq
(Michael Paquier <michael@paquier.xyz>)
|
| Список | pgsql-hackers |
Hello Surafel,
On Fri, Sep 14, 2018 at 2:03 PM Surafel Temesgen <surafel3000@gmail.com> wrote:
Hey ,
Here are a few comment.
+ <varlistentry id="libpq-connect-falover-timeout"
xreflabel="failover_timeout">
Here's a typo: ="libpq-connect-falover-timeout"
+ {"failover_timeout", NULL, NULL, NULL,
+ "Failover Timeout", "", 10,
Word is separated by hyphen in internalPQconninfoOption lable as a
surrounding code
+ If the value is <literal>random</literal>, the host to connect to
+ will be randomly picked from the list. It allows load balacing between
+ several cluster nodes.
I Can’t think of use case where randomly picking a node rather than in
user specified order can load balance the cluster better. Can you
explain the purpose of this feature more?
Probably load-balancing is a wrong word for this. Think of it as a connection routing mechanism. Let's say you have 10 servers and 100 clients willing to establish read-only connection. Without this feature all clients will go to the first specified host (unless they hit max_connections limit). And with random `hostorder` they would be splited between hosts more or less evenly.
And in the code I can’t see
a mechanism for preventing picking one host multiple time
The original idea was to collect all ip addresses that we get after resolving specified hostnames, put those addresses into a global array, apply random permutations to it and then use round robin algorithm trying to connect to each of them until we succeed. Now I'm not sure that this approach was the best. There are two concerns:
1. host name can be resolved to several ip addresses (which in turn can point to either the same physical server with multiple network interfaces or different servers). In described above schema each ip address would be added to the global array. This may lead to a situation when one host gets higher chance of being picked because it has more addresses in global array than other hosts.
2. host may support both ipv4 and ipv6 connections, which again leads to extra items in global array and therefore also increases its chance to be picked.
Another approach would be to leave `pg_conn->connhost` as it is now (i.e. not to create global addresses array) and just apply random permutations to it if `hostorder=random` is specified. And probably apply permutations to addresses list within each individual host.
At this point I'd like to ask community what in your opinion would be the best course of action and whether this feature should be implemented within libpq at all? Because from my POV there are factors that really depend on network architecture and there is probably no single right solution.
Kind regards,
Ildar
В списке pgsql-hackers по дате отправления: