Am 15.06.2017 um 08:26 schrieb Rory Campbell-Lange:
On 15/06/17, Andreas Kretschmer (andreas@xxxxxxxxxxxxxxx) wrote:
Am 15.06.2017 um 01:18 schrieb Martin Goodson:
...Do people setup pgbouncer nodes on the database servers
themselves, on application servers, in the middle tier between the
application and database, and so forth, or some combination of the
three?
Usually we recommend to install pgbouncer on the app-servers.
If you have full control of the application you can try to integrate the
logic into the application (provide a list of servers, the new pg10-version
of libpg is working similar in this way:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=274bb2b3857cc987cfa21d14775cae9b0dababa5
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=721f7bd3cbccaf8c07cad2707826b83f84694832
)
Hi Andreas
The list of servers idea is a cool enhancement. However would pgbouncer
(or another client) be able to detect which of those servers were in slave
mode?
it is possible to detect which is the master. So, if you know the master
and you have a list of all, you knows also the standby's ;-)
Otherwise, if there is a temporary glitch in communications with the
master, a client (such as pgbouncer) could move to try inserts on a
slave.
Right. You can play with keepalives* - settings to avoid problems.
Andreas
--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
