<div dir="ltr">Great, thank you very much for explanation. Regarding returning error - i did not knew.<br>So, basically i can have a service, that will probe for master DB, in case of its transfer - service will update /etc/hosts and return error, which will be caught by pcs and it will restart whole dependent set ? Sounds good.<br>But how i can do 2 "main resources" ? I have webserver AND db_monitor. In case of failure of webserver - should all start on node b, but in case of DB change - only underlying resources ...<br>Should i make webserver outside of set? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 3:57 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com">kgaillot@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 be<br>
> restarted whenever DB changes. Another one is a "standby" APP, where<br>
> all resources are shut.<br>
> So i thought about adding some "service" script, which will probe a<br>
> DB , and in case if it finds a CHANGE - will trigger pcs to reload a<br>
> set of resources, where one of resource would be a systemctl file,<br>
> which will continue to run a script, so in case of next change of DB<br>
> - it will restart APP set again. Is it sounds reasonable? (i don't<br>
> care of errors. I mean - i do, i want to log, but i'm ok to see 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 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 - 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 the<br>
database master promotion. pcs example: pcs constraint order 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">kgaillot@redhat.com</a>><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 need<br>
> > to<br>
> > > add them to PCS cluster and then start them? but in case if 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 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 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 since<br>
> > the<br>
> > last monitor. (The start action would have to record the initial<br>
> > master.) Pacemaker will restart the app to recover from the 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">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">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 i<br>
> > want<br>
> > > > also<br>
> > > > >to<br>
> > > > >monitor "which DB is master".  I can't use VIP (which 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 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  and<br>
> > then<br>
> > > > the app, during a failover  the app will be stoped  and 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 are <br>
> > > > started  where  the master  DB is running  -  so the lattency<br>
> > will<br>
> > > > be minimal.<br>
> > > > <br>
> > > > Best Regards,<br>
> > > > Strahil Nikolov<br>
-- <br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div>