Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ...
От | Andreas Kretschmer |
---|---|
Тема | Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ... |
Дата | |
Msg-id | 937adff6-1a25-5ce1-6cc9-6cade9b552d9@a-kretschmer.de обсуждение исходный текст |
Ответ на | Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ... (Rory Campbell-Lange <rory@campbell-lange.net>) |
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: