Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ...
| От | Andreas Kretschmer |
|---|---|
| Тема | Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ... |
| Дата | |
| Msg-id | dd851809-e98a-f000-96bf-d9d017d1c4ff@a-kretschmer.de обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Repmgr + pgbouncer - Notification of master promotionto application level ... (Martin Goodson <kaemaril@googlemail.com>) |
| Ответы |
[GENERAL] Re: Repmgr + pgbouncer - Notification of master promotion toapplication level ...
|
| Список | pgsql-general |
Am 15.06.2017 um 11:57 schrieb Martin Goodson: > > > The issues I think I would have with pgbouncer at the application > level is ... > > 1) What if an application server is down when pgbouncer tries to > update where the database IP is pointing to? When it is brought back > into service could that create a split-brain scenario if it's still > pointing to the old master? Since the only STONITH here is 'I've told > you to talk to server X instead of server Y' what happens if somebody > doesn't get that message and the old master is still up and about > (e.g. the failover was caused by a transient error such as a power > issue or network issue that the 'old master' was able to quickly > recover from and come back online)? :) yeah, that's problematic here. > 2) We use a non-trivial number of application servers. Could that > create 'failover lag' due to the amount of time it takes to notify all > the pgbouncers to stop, change IP, and restart? possible, yes. > 3) Since we use a non-trivial number of application servers, the > administrative overhead of pushing all user password changes up to > each pgbouncer could be a bit of a pain (candidate for an automation > tool like ansible, perhaps?) use auth_query instead of auth_file. Regards, Andreas -- 2ndQuadrant - The PostgreSQL Support Company. www.2ndQuadrant.com
В списке pgsql-general по дате отправления: