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