<div dir="ltr">Let me give the full picture about our solution. It will then make it easy to have the discussion.<div><br><div>We are looking at providing N + 1 Redundancy to our application servers, i.e. 1 standby for upto N active (currently N<=5). Each server will have some unique configuration. The standby will store the configuration of all the active servers such that whichever server goes down, the standby loads that particular configuration and becomes active. The server that went down will now become standby. </div><div>We have bundled all the configuration that every server has into a resource such that during failover the resource is moved to the newly active server, and that way it takes up the personality of the server that went down. To put it differently, every active server has a 'unique' resource that is started by Pacemaker whereas standby has none.<div><br></div><div>Our servers do not write anything to an external database, all the writing is done to the CIB file under the resource that it is currently managing. We also have some clients that connect to the active servers (1 client can connect to only 1 server, 1 server can have multiple clients) and provide service to end-users. Now the reason I say that split-brain is not an issue for us, is coz the clients can only connect to 1 of the active servers at any given time (we have to handle the case that all clients move together and do not get distributed). So even if two servers become active with same personality, the clients can only connect to 1 of them. (Initial plan was to go configure quorum but later I was told that service availability is of utmost importance and since impact of split-brain is limited, we are thinking of doing away with it).</div><div><br></div><div>Now the concern I have is, once the split is resolved, I would have 2 actives, each having its own view of the resource, trying to synchronize the CIB. At this point I want the one that has the clients attached to it win.</div><div>I am thinking I can implement a monitor function that can bring down the resource if it doesn't find any clients attached to it within a given period of time. But to understand the Pacemaker behavior, what exactly would happen if the same resource is found to be active on two nodes after recovery?</div><div><br></div><div>-Thanks<br></div><div>Nikhil</div><div><br><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 3:49 AM, Digimer <span dir="ltr"><<a href="mailto:lists@alteeve.ca" target="_blank">lists@alteeve.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20/06/16 05:58 PM, Dimitri Maziuk wrote:<br>
> On 06/20/2016 03:58 PM, Digimer wrote:<br>
><br>
>> Then wouldn't it be a lot better to just run your services on both nodes<br>
>> all the time and take HA out of the picture? Availability is predicated<br>
>> on building the simplest system possible. If you have no concerns about<br>
>> uncoordinated access, then make like simpler and remove pacemaker entirely.<br>
><br>
> Obviously you'd have to remove the other node as well since you now<br>
> can't have the single service access point anymore.<br>
<br>
</span>Nikhil indicated that they could switch where traffic went up-stream<br>
without issue, if I understood properly.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Digimer<br>
Papers and Projects: <a href="https://alteeve.ca/w/" rel="noreferrer" target="_blank">https://alteeve.ca/w/</a><br>
What if the cure for cancer is trapped in the mind of a person without<br>
access to education?<br>
<br>
_______________________________________________<br>
Users mailing list: <a href="mailto:Users@clusterlabs.org">Users@clusterlabs.org</a><br>
<a href="http://clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://clusterlabs.org/mailman/listinfo/users</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
</div></div></blockquote></div><br></div>