> On 26 Nov 2015, at 11:52 AM, Jehan-Guillaume de Rorthais <[email protected]> > wrote: > > Hi guys, > > While working on our pgsqlms agent[1], we are now studying how to control all > the steps of a switchover process from the resource agent. > > The tricky part here is the 2nd step of a successful swithover with PostgreSQL > (9.3+): > (1) shutdown the master first > (2) make sure the designated slave received **everything** from the old > master
How can you achieve (2) if (1) has already occurred? There’s no-one for the designated slave to talk to in the case of errors... > (3) promote the designated slave as master > (4) start the old master as slave (4) is pretty tricky. Assuming you use master/slave, its supposed to be in this state already after the demote in step (1). If you’re just using clones, then you’re in even more trouble because pacemaker either wouldn’t have stopped it or won’t want to start it again. See more below. > As far as we understand Pacemaker, migrate-to and migrate-from capabilities > allows to distinguish if we are moving a resource because of a failure or for > a > controlled switchover situation. Unfortunately, these capabilities are ignored > for cloned and multi-state resources… Yeah, this isn’t really the right use-case. You need to be looking more at the promote/demote cycle. If you turn on notifications, then in a graceful switchover (eg. the node is going into standby) you will get information about which node has been selected to become the new master when calling demote on the old master. Perhaps you could ensure (2) while performing (1). Its not ideal, but you could have (4) happen in the post-promote notification. Notify actions aren’t /supposed/ to change resource state but it has been done before. > > Because of this restriction, we currently don't know from the resource agent > code if we should check the designated slave received everything from the old > master (controlled switchover) or not (we lost the master). In case of > controlled switchover, if the designated slave did not received everything > from > the master, we must abort the switchover. > > A workaround we could imagine would be to set a special cluster attribute > manually (using crm_attribute) to signal the agent we are going to make a > controlled switchover. > > But I bet the cleaner way would be to use migrate-to and migrate-from > capabilities. Did we miss something about them? Is there some plan to support > moving a Master/Slave role using migrate-to and migrate-from at some point? > Any > other proposal? ideas? > > [1] see "multistate" folder in https://github.com/dalibo/pgsql-resource-agent > > Regards, > -- > Jehan-Guillaume de Rorthais > Dalibo > > _______________________________________________ > Developers mailing list > [email protected] > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list [email protected] http://clusterlabs.org/mailman/listinfo/developers
