On Thu, 5 Oct 2017 21:24:36 +0200 Valentin Vidic <[email protected]> wrote:
> On Thu, Oct 05, 2017 at 08:55:59PM +0200, Jehan-Guillaume de Rorthais wrote: > > It doesn't seems impossible, however I'm not sure of the complexity around > > this. > > > > You would have to either hack PAF and detect failover/migration or create a > > new RA that would always be part of the transition implying your PAF RA to > > define if it is moving elsewhere or not. > > > > It feels the complexity is quite high and would require some expert advices > > about Pacemaker internals to avoid wrong or unrelated behaviors or race > > conditions. > > > > But, before going farther, you need to realize a failover will never be > > transparent. Especially one that would trigger randomly outside of your > > control. > > Yes, I was thinking more about manual failover, for example to upgrade > the postgresql master. RA for pgbouncer would wait for all active > queries to finish and queue all new queries. Once there is nothing > running on the master anymore, another slave is activated and pgbouncer > would than resume queries there. OK. Then for a manual and controlled switchover, I suppose the best option is to keep things simple and add two more steps to your blueprint: * one to pause the client connection before the "pcs resource move --master --wait <rsc_id> [node]" * one to resume them as soon as the "pcs resource move" finised. Obviously, this could be scripted to make controls, checks and actions faster. _______________________________________________ Users mailing list: [email protected] http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
