Proposal: Implement failover on libpq connect level.
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.
Commercial RDBMS, such as Oracle, employ more flexible approach. They
allow to specify multiple servers in the connect string, so if primary
server is not available, client library tries to connect to other ones.
This approach allows to use geographically distributed failover clusters
and also is a cheap way to implement load-balancing (which is not
possible with IP address migration).
Proposed change
===============
Allow to specify multiple hosts in the libpq connect string. Make libpq
attempt to connect to all host simultaneously or in random order
and use of the server which successfully establishes connection first.
Syntax
------
Libpq connect string can be either set of the keyword=value pairs
or an URL.
In the first form it can be just allowed to specify keyword host
multiple times.
"host=main-server host=standby1 host=standby2 port=5432 dbname=database"
In the second form host can be specified either in the first part of URL
or in the query parameters.
postgresql://user@host/database
postgresql:///database?host=hostname&user=username
If host is specified as a parameter, it is also possible to allow
multiple host parameters without breaking existing syntax.
postgresql:///database?host=main-server&host=standby1&host=standby2
In order to implement load-balancing clusters, additional parameters
should be added readonly=boolean and loadbalancing=boolean
Support for this syntax extensions is added to the PQconnectdb,
PQconnectdbParams, PQConnectStart and PQConnectStartParams,
but not PQsetdb/PQsetdblogin functions.
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.
If the loadbalancing parameter is true, it tries servers sequentially in
the random order.
If the parameter readonly is false, after authenticating with server it
executes show transaction_read_only, to find out whether current
connection is to the master or to the hot standby, and connection is
considered successful only if server allows read write transactions.
This allows to have clients which write to the database and clients
which perform read-only access. Read-only clients would be load-balanced
between the master and slave servers, and read-write clients connect only to
the master (whichever server has this role at the moment of connection).
Information of the alternate servers should be stored in the PGconn structure.
Function PQreset should be able to take advantage of new syntax and
possibly open connection to the new master, if failover occurred
during lifetime of the connection.
Possible drawbacks
==================
Compatibility
-------------
Proposed patch requires no modifications to the server or protocol, and
modification of synchronous function (PQconnectdb, PQconnectdbParams)
doesn't introduce incompatible changes to the client library.
Even if connect string with multiple host would be erroneously used
with version of libpq, which do not support this feature, it is not an
error. It just use last host specified in the connect string.
There could be some compatibility problems with asynchronous connections
created with PQConnectStart functions. Problem is that we are trying
to establish several connections at once, and there are several sockets
which should be integrated into application event loop.
Even if we would try servers in some particular order (such as randomized
order during load balancing), file descriptor of socket can change during
execution PQConnectPoll, and existing applications are not prepared to it.
Performance impact
------------------
Performance impact seems to be negligible.
1. If connect string contain only one host, the only complication is the
maintenance of the data structure, which possible can hold more than
one host name. Connection process itself would not be affected.
2. If there is pure high-availability cluster, i.e. standby servers do
not accept client connections on the specified port, there is no extra
load on standby servers, and almost no (only several unsuccessful
connect calls) on client.
3. If there is load balancing cluster, there is no performance impacts
for read-only client, but each read-write client causes standby servers
to process extra connection to the point where server can report
read-only state of transaction (i.e. including SSL handshake and
postgresql authentication). Typically, in the situation where read-only
clients should be load-balanced using this feature, there are much more
read-only clients, than read-write ones. So some extra load related with
read-write connection seems to be justified by simplification of client
configuration.
--
Victor Wagner <vitus@wagner.pp.ru>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Victor Wagner 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.Commercial RDBMS, such as Oracle, employ more flexible approach. They
allow to specify multiple servers in the connect string, so if primary
server is not available, client library tries to connect to other ones.This approach allows to use geographically distributed failover clusters
and also is a cheap way to implement load-balancing (which is not
possible with IP address migration).
I wonder how useful this is at the present time.
If the primary goes down and the client gets connected to the standby,
it would have read-only access there. Most applications wouldn't cope
well with that.
Once we have multi-master replication that can be used for fail-over,
the picture will change. Then a feature like that would be very useful indeed.
"host=main-server host=standby1 host=standby2 port=5432 dbname=database"
It seems a bit arbitrary to require that all servers use the same port.
Maybe parameters like host2, port2, host3, port3 etc. might be better.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18 Aug 2015, at 10:32, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
Victor Wagner 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.Commercial RDBMS, such as Oracle, employ more flexible approach. They
allow to specify multiple servers in the connect string, so if primary
server is not available, client library tries to connect to other ones.This approach allows to use geographically distributed failover clusters
and also is a cheap way to implement load-balancing (which is not
possible with IP address migration).I wonder how useful this is at the present time.
If the primary goes down and the client gets connected to the standby,
it would have read-only access there. Most applications wouldn't cope
well with that.Once we have multi-master replication that can be used for fail-over,
the picture will change. Then a feature like that would be very useful indeed."host=main-server host=standby1 host=standby2 port=5432 dbname=database"
It seems a bit arbitrary to require that all servers use the same port.
Maybe parameters like host2, port2, host3, port3 etc. might be better.
Yours,
Laurenz Albe
i totally agree with laurenz.
in addition to that you have the “problem” of transactions. if you failover in the middle
of a transaction, strange things might happen from the application point of view.
the good thing, however, is that stupid middleware is sometimes not able to handle
failed connections. however, overall i think it is more of a danger than a benefit.
regards,
hans
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hans-Jürgen Schönig wrote:
in addition to that you have the “problem” of transactions. if you failover in the middle
of a transaction, strange things might happen from the application point of view.the good thing, however, is that stupid middleware is sometimes not able to handle
failed connections. however, overall i think it is more of a danger than a benefit.
Maybe I misunderstood the original proposal, but my impression was that the alternative
servers would be tried only at the time the connection is established, and there would be no
such problems as you describe.
Those could only happen if libpq automatically tried to reconnect upon failure without
the client noticing.
So the stupid middleware would get an error message, but the reconnect would actually work.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18 Aug 2015, at 11:19, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
Hans-Jürgen Schönig wrote:
in addition to that you have the “problem” of transactions. if you failover in the middle
of a transaction, strange things might happen from the application point of view.the good thing, however, is that stupid middleware is sometimes not able to handle
failed connections. however, overall i think it is more of a danger than a benefit.Maybe I misunderstood the original proposal, but my impression was that the alternative
servers would be tried only at the time the connection is established, and there would be no
such problems as you describe.
it would still leave the problem of having a read only on the other side unless you are using BDR or so.
regards,
hans
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 18, 2015 at 6:07 AM, PostgreSQL - Hans-Jürgen Schönig
<postgres@cybertec.at> wrote:
On 18 Aug 2015, at 11:19, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
Hans-Jürgen Schönig wrote:
in addition to that you have the “problem” of transactions. if you failover in the middle
of a transaction, strange things might happen from the application point of view.the good thing, however, is that stupid middleware is sometimes not able to handle
failed connections. however, overall i think it is more of a danger than a benefit.Maybe I misunderstood the original proposal, but my impression was that the alternative
servers would be tried only at the time the connection is established, and there would be no
such problems as you describe.it would still leave the problem of having a read only on the other side unless you are using BDR or so.
That doesn't make this a bad idea. Some people are using replication
solutions that can cope with this already (EDB has a proprietary
product, and I'm sure there are people using BDR, too) and, as the
solutions get better and more widely deployed, more people will want
to do it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 17 August 2015 at 23:18, Victor Wagner <vitus@wagner.pp.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Aug 18, 2015 at 12:53 PM, Jaime Casanova
<jaime.casanova@2ndquadrant.com> wrote:
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.
Sure, but pgbouncer is an extra hop, and has its own foibles. There's
real appeal to doing this in the client.
i agree that once/if we ever have multimaster included then this could
be a good idea
I think it has a lot of appeal *now*.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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.
If the loadbalancing parameter is true, it tries servers sequentially in
the random order.If the parameter readonly is false, after authenticating with server it
executes show transaction_read_only, to find out whether current
connection is to the master or to the hot standby, and connection is
considered successful only if server allows read write transactions.
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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
I wonder how extended protocol is handled by this proposal. Suppose
load balacing mode is enabled. PQprepare is executed on standby1. Then
PQexecPrepared gets called. This may be executed on standby2, which
will fail because there's no prepared statement created by the former
PQprepare call.
Even simple procotol is used, same thing can be said to SQL
PREPARE/EXECUTE/DEALLOCATE.
SQL BEGIN/COMMIT/ROLLBACK would be more interesting example in load
balancing mode.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015.08.18 at 08:32:28 +0000, Albe Laurenz wrote:
I wonder how useful this is at the present time.
If the primary goes down and the client gets connected to the standby,
it would have read-only access there. Most applications wouldn't cope
well with that.
It is supposed that somebody (either system administrator or some
cluster management software) have noticed failure of master and promoted
one of the standbys to master.
So, clients have only to find out which cluster node serves as master
just now.
Idea is that we don't need any extra administration actions such as IP
migration to do it. Clients have list of alternate servers and discover
which one to work with by trial and error.
I consider in my proposal following situations:
1. Warm standby - doesn't accept client connection at all unless
promoted to master.
2. Hot standby - we have two types of clients - one for which readonly
access is sufficient, and other that need to connect only to master.
In this case intention to write is explicitely stated in the connect
string (readonly=false) and connect procedure would check if node it
tries to connect allowed write.
It seems that most people discussing in this thread think in millisecond
time intervals (failure and immediate reconnect).
I was thinking about much longer time intervals - it would probaly take
seconds to cluster management software to notice server failure and
promote backup server to master, it might be possible for application to
spend minute or so trying to reconnect, but it would take
hours to change connect string on clients - it would require visit of
support enginer to each client terminal, if we are thinking of
distributed OLTP system such as point-of-sale network with thick
clients.
"host=main-server host=standby1 host=standby2 port=5432 dbname=database"
It seems a bit arbitrary to require that all servers use the same port.
Maybe parameters like host2, port2, host3, port3 etc. might be better.
I've thought about this approach. But PostgreSQL administration guide
insists that all servers in the cluster should have as identical
configuration as possible to simplify administration.
Moreover I've seldom have seen configurations where postgresql is
accepting connection on non-default port.
Using host1, host2 etc would have unintended connotations, such is "this
is first, main server". I think that client should treat all given
servers as equal and let cluster administration to choose which one
would accept connection.
--
Victor Wagner <vitus@wagner.pp.ru>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Aug 19, 2015 at 12:21 PM, Victor Wagner *EXTERN* <vitus@wagner.pp.ru>
wrote:
On 2015.08.18 at 08:32:28 +0000, Albe Laurenz wrote:
I wonder how useful this is at the present time.
If the primary goes down and the client gets connected to the standby,
it would have read-only access there. Most applications wouldn't cope
well with that.It is supposed that somebody (either system administrator or some
cluster management software) have noticed failure of master and promoted
one of the standbys to master.So, clients have only to find out which cluster node serves as master
just now.Idea is that we don't need any extra administration actions such as IP
migration to do it. Clients have list of alternate servers and discover
which one to work with by trial and error.I consider in my proposal following situations:
1. Warm standby - doesn't accept client connection at all unless
promoted to master.2. Hot standby - we have two types of clients - one for which readonly
access is sufficient, and other that need to connect only to master.
In this case intention to write is explicitely stated in the connect
string (readonly=false) and connect procedure would check if node it
tries to connect allowed write.It seems that most people discussing in this thread think in millisecond
time intervals (failure and immediate reconnect).
Why not have this as a separate parameter (*_timeout or something like
that)?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015.08.19 at 12:42:45 +0900, Tatsuo Ishii wrote:
I wonder how extended protocol is handled by this proposal. Suppose
load balacing mode is enabled. PQprepare is executed on standby1. Then
PQexecPrepared gets called. This may be executed on standby2, which
will fail because there's no prepared statement created by the former
PQprepare call.
Here we are discussing load-balancing on the client level, not on the
statement level.
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).
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Victor Wagner wrote:
I wonder how useful this is at the present time.
If the primary goes down and the client gets connected to the standby,
it would have read-only access there. Most applications wouldn't cope
well with that.
It is supposed that somebody (either system administrator or some
cluster management software) have noticed failure of master and promoted
one of the standbys to master.So, clients have only to find out which cluster node serves as master
just now.Idea is that we don't need any extra administration actions such as IP
migration to do it. Clients have list of alternate servers and discover
which one to work with by trial and error.
Yes, but that will only work reliably if the (read-only) standby does not
allow connections before it is promoted.
I consider in my proposal following situations:
1. Warm standby - doesn't accept client connection at all unless
promoted to master.2. Hot standby - we have two types of clients - one for which readonly
access is sufficient, and other that need to connect only to master.
In this case intention to write is explicitely stated in the connect
string (readonly=false) and connect procedure would check if node it
tries to connect allowed write.
I think that these are both valid use cases.
And as Robert said, there are people out using BDR or other proprietary
multi-master solutions, so there might well be an audience for this feature.
"host=main-server host=standby1 host=standby2 port=5432 dbname=database"
It seems a bit arbitrary to require that all servers use the same port.
Maybe parameters like host2, port2, host3, port3 etc. might be better.
I've thought about this approach. But PostgreSQL administration guide
insists that all servers in the cluster should have as identical
configuration as possible to simplify administration.Moreover I've seldom have seen configurations where postgresql is
accepting connection on non-default port.
We do it all the time.
Using host1, host2 etc would have unintended connotations, such is "this
is first, main server". I think that client should treat all given
servers as equal and let cluster administration to choose which one
would accept connection.
I don't think that my idea of "host", "host3" is very appealing myself,
but I still don't like your original proposal of having multiple "host"
parameters.
One problem with that is that this syntax is already allowed, but
your proposal would silently change the semantics.
Today, if you have multiple "host" parameters, the last one wins.
So with your modification in place, some connect strings that work today
would start behaving in unexpected ways.
Maybe a better idea would be:
host=db1.myorg.com,db2.myorg.com port=5432,2345
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015.08.19 at 12:29:51 +0530, Amit Kapila wrote:
It seems that most people discussing in this thread think in millisecond
time intervals (failure and immediate reconnect).Why not have this as a separate parameter (*_timeout or something like
that)?
Because it is not in the software configuration. It is in the people
heads. Or may be in the organizational configuration of the environments
we are talking about.
Each of us imagining some use-case for discussed feature. And these
cases are completely different, and have different typical time
interval.
I haven't explicitely stated my use cases in the proposal. So people
thinking in terms of their use cases, and this is very significant
feedback for me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Aug 19, 2015 at 12:35 PM, Victor Wagner <vitus@wagner.pp.ru> wrote:
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 hostssimultaneously,
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.
As far as I understand, failover gets initiated once the master server goes
down or is not accessible due to some reason, so for such cases if you
have the connection to both the servers then it might not work.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On 2015.08.19 at 07:15:30 +0000, Albe Laurenz wrote:
Idea is that we don't need any extra administration actions such as IP
migration to do it. Clients have list of alternate servers and discover
which one to work with by trial and error.Yes, but that will only work reliably if the (read-only) standby does not
allow connections before it is promoted.
It would just take a bit more time for client and a bit more load for
server - to make sure that this connection is read-write by
issuing
show transaction_read_only
statement before considering connection useful.
And as Robert said, there are people out using BDR or other proprietary
multi-master solutions, so there might well be an audience for this feature.
Unfortunately I have no experience with such solutions, so I'd greatly
appreciate feedback from those people.
I've modelled my proposal after another proprietary solution - Oracle
RAC.
One problem with that is that this syntax is already allowed, but
your proposal would silently change the semantics.
Today, if you have multiple "host" parameters, the last one wins.
So with your modification in place, some connect strings that work today
would start behaving in unexpected ways.
This is serious argument. But what the use case of these connect strings
now?
It seems to me that in most cases last host in the connect string would
be only host which accepts connections, so it wins anyway
Maybe a better idea would be:
host=db1.myorg.com,db2.myorg.com port=5432,2345
I've tried not to introduce new delimiters. But this syntax definitely
have some advantages. At least it allows to specify host-port pairs as
two parallel lists.
Other idea - allow to specify host-port pair as argument of host
parameter.
host=db1.myorg.com:5432
It is consistent with URL syntax and system administrators are used to
it. And with long list of hosts there is less chances to made an error
as host and corresponding port come together.
But your variant allows to handle hostaddr parameter same way as host
and port.
--
Victor Wagner <vitus@wagner.pp.ru>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015.08.19 at 12:55:15 +0530, Amit Kapila wrote:
I think that failover procedure should begin before first connection is
ever established.As far as I understand, failover gets initiated once the master server goes
down or is not accessible due to some reason, so for such cases if you
have the connection to both the servers then it might not work.
Master server might go down when client is not started yet.
And when client starts up, it has to find out which server to connect
now.
Consider point-of-sale terminals, bank offices or anything else, which
do not work round the clock. Clerk comes to his workplace in the
morning, switches on terminal and inserts her smartcard to authorize
with server. She doesn't need to know what server name is and where it
is located. Either application finds the server automatically, or
support engineer has to be called to fix things.
Moreover, in some situations restart of application (or even client
terminal) is acceptable price for failover, as long as there is no need
to manually fix the configuration.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Victor Wagner wrote:
Idea is that we don't need any extra administration actions such as IP
migration to do it. Clients have list of alternate servers and discover
which one to work with by trial and error.Yes, but that will only work reliably if the (read-only) standby does not
allow connections before it is promoted.It would just take a bit more time for client and a bit more load for
server - to make sure that this connection is read-write by
issuingshow transaction_read_only
statement before considering connection useful.
That's not very comfortable, and a lot of middleware software won't easily
learn the trick.
But even without that use case I think that the feature is probably
worth the effort.
[about having multiple "host" parameters in the connection string]
One problem with that is that this syntax is already allowed, but
your proposal would silently change the semantics.
Today, if you have multiple "host" parameters, the last one wins.
So with your modification in place, some connect strings that work today
would start behaving in unexpected ways.This is serious argument. But what the use case of these connect strings
now?It seems to me that in most cases last host in the connect string would
be only host which accepts connections, so it wins anyway
I'm not saying that it is particularly wide-spread and useful; it could
happen through careless editing of connection strings or by using a
connection service file entry
(http://www.postgresql.org/docs/current/static/libpq-pgservice.html)
and overriding the host parameter on the command line.
Maybe a better idea would be:
host=db1.myorg.com,db2.myorg.com port=5432,2345I've tried not to introduce new delimiters. But this syntax definitely
have some advantages. At least it allows to specify host-port pairs as
two parallel lists.Other idea - allow to specify host-port pair as argument of host
parameter.host=db1.myorg.com:5432
It is consistent with URL syntax and system administrators are used to
it. And with long list of hosts there is less chances to made an error
as host and corresponding port come together.
I don't think that is very attactive as it confuses the distinction between
"host" and "port". What would you do with
host=db1.myorg.com:2345 port=1234
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
