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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
