<div dir="auto">But colocation of dbprobe won't pull trigger of webserver ? Or because that it is below in order - it will just restart services ?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020, 18:41 Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2020-03-11 at 16:08 +0200, Roman Hershkovich wrote:<br>
> Great, thank you very much for explanation. Regarding returning error<br>
> - i did not knew.<br>
> So, basically i can have a service, that will probe for master DB, in<br>
> case of its transfer - service will update /etc/hosts and return<br>
> error, which will be caught by pcs and it will restart whole<br>
> dependent set ? Sounds good.<br>
> But how i can do 2 "main resources" ? I have webserver AND<br>
> db_monitor. In case of failure of webserver - should all start on<br>
> node b, but in case of DB change - only underlying resources ...<br>
> Should i make webserver outside of set? <br>
<br>
If you want the webserver to move to another node after a single<br>
failure (of the webserver itself), set its migration-threshold to 1. If<br>
you want other resources to move with it, colocate them with the<br>
webserver.<br>
<br>
The db monitor won't affect that -- if the db monitor fails, anything<br>
ordered after it will restart.<br>
<br>
> On Wed, Mar 11, 2020 at 3:57 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank" rel="noreferrer">kgaillot@redhat.com</a>><br>
> wrote:<br>
> > On Wed, 2020-03-11 at 02:27 +0200, Roman Hershkovich wrote:<br>
> > > Yes.<br>
> > > I have only 1 APP active at same time, and so I want this app to<br>
> > be<br>
> > > restarted whenever DB changes. Another one is a "standby" APP,<br>
> > where<br>
> > > all resources are shut.<br>
> > > So i thought about adding some "service" script, which will probe<br>
> > a<br>
> > > DB , and in case if it finds a CHANGE - will trigger pcs to<br>
> > reload a<br>
> > > set of resources, where one of resource would be a systemctl<br>
> > file,<br>
> > > which will continue to run a script, so in case of next change of<br>
> > DB<br>
> > > - it will restart APP set again. Is it sounds reasonable? (i<br>
> > don't<br>
> > > care of errors. I mean - i do, i want to log, but i'm ok to see<br>
> > them)<br>
> > <br>
> > That sounds fine, but I'd trigger the restart by returning an error<br>
> > code from the db-monitoring script, rather than directly attempt to<br>
> > restart the resources via pcs. If you order the other resources<br>
> > after<br>
> > the db-monitoring script, pacemaker will automatically restart them<br>
> > when the db-monitoring script returns an error.<br>
> > <br>
> > > In addition - i thought maybe bringing PAF here could be useful -<br>
> > but<br>
> > > this is even more complex ... <br>
> > <br>
> > If bringing the db into the cluster is a possibility, that would<br>
> > probably be more reliable, with a quicker response too.<br>
> > <br>
> > In that case you would simply order the dependent resources after<br>
> > the<br>
> > database master promotion. pcs example: pcs constraint order<br>
> > promote<br>
> > DB-RSC then start DEPENDENT-RSC<br>
> > <br>
> > > On Tue, Mar 10, 2020 at 10:28 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank" rel="noreferrer">kgaillot@redhat.com</a><br>
> > ><br>
> > > wrote:<br>
> > > > On Tue, 2020-03-10 at 21:03 +0200, Roman Hershkovich wrote:<br>
> > > > > DB servers are not in PCS cluster. Basically you say that i<br>
> > need<br>
> > > > to<br>
> > > > > add them to PCS cluster and then start them? but in case if<br>
> > DB1<br>
> > > > fails<br>
> > > > > - DB2 autopromoted and not required start of service again><br>
> > > > > <br>
> > > > > Regarding colocation rule - i'm kind of missing logic how it<br>
> > > > works -<br>
> > > > > how i can "colocate" 1 of 2 APP servers to be around a master<br>
> > DB<br>
> > > > ? <br>
> > > > <br>
> > > > If I understand correctly, what you want is that both apps are<br>
> > > > restarted if the master changes?<br>
> > > > <br>
> > > > I'm thinking you'll need a custom OCF agent for the app<br>
> > servers.<br>
> > > > The<br>
> > > > monitor action, in addition to checking the app's status, could<br>
> > > > also<br>
> > > > check which db is master, and return an error if it's changed<br>
> > since<br>
> > > > the<br>
> > > > last monitor. (The start action would have to record the<br>
> > initial<br>
> > > > master.) Pacemaker will restart the app to recover from the<br>
> > error.<br>
> > > > <br>
> > > > That is a little hacky because you'll have errors in the status<br>
> > > > every<br>
> > > > time the master moves, but maybe that's worth knowing in your<br>
> > > > situation<br>
> > > > anyway.<br>
> > > > <br>
> > > > > On Tue, Mar 10, 2020 at 8:42 PM Strahil Nikolov <<br>
> > > > > <a href="mailto:hunter86_bg@yahoo.com" target="_blank" rel="noreferrer">hunter86_bg@yahoo.com</a>> wrote:<br>
> > > > > > On March 10, 2020 7:31:27 PM GMT+02:00, Roman Hershkovich <<br>
> > > > > > <a href="mailto:warpik@gmail.com" target="_blank" rel="noreferrer">warpik@gmail.com</a>> wrote:<br>
> > > > > > >I have 2 DB servers (master/slave with replica) and 2 APP<br>
> > > > servers.<br>
> > > > > > >2 APP servers managed by pacemaker  (active/passive) , but<br>
> > i<br>
> > > > want<br>
> > > > > > also<br>
> > > > > > >to<br>
> > > > > > >monitor "which DB is master".  I can't use VIP (which<br>
> > could be<br>
> > > > > > sticked<br>
> > > > > > >on<br>
> > > > > > >master DB) - it is very limited virtual environment.<br>
> > > > > > ><br>
> > > > > > >Is it possible to create a rule or some other scenario, so<br>
> > in<br>
> > > > case<br>
> > > > > > if<br>
> > > > > > >master moved - pacemaker will restart APP (app does not<br>
> > > > support<br>
> > > > > > >failover) ?<br>
> > > > > > <br>
> > > > > > Hi Roman,<br>
> > > > > > <br>
> > > > > > If you set an order rule that  starts  first the master <br>
> > and<br>
> > > > then<br>
> > > > > > the app, during a failover  the app will be stoped  and<br>
> > once<br>
> > > > the<br>
> > > > > > master  is switched  (slave is promoted) the  app will be<br>
> > > > started<br>
> > > > > > again.<br>
> > > > > > <br>
> > > > > > Also you can consider  a  colocation rule that all  apps<br>
> > are <br>
> > > > > > started  where  the master  DB is running  -  so the<br>
> > lattency<br>
> > > > will<br>
> > > > > > be minimal.<br>
> > > > > > <br>
> > > > > > Best Regards,<br>
> > > > > > Strahil Nikolov<br>
> > _______________________________________________<br>
> > Manage your subscription:<br>
> > <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
> > <br>
> > ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
-- <br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank" rel="noreferrer">kgaillot@redhat.com</a>><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div>