Am 15.06.2017 um 08:26 schrieb Rory Campbell-Lange:
> On 15/06/17, Andreas Kretschmer (andreas@a-kretschmer.de) 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