-Atin Sent from one plus one On Sep 1, 2015 9:39 PM, "Joe Julian" <[email protected]> wrote: > > > > On 09/01/2015 02:59 AM, Atin Mukherjee wrote: >> >> >> On 09/01/2015 02:34 PM, Joe Julian wrote: >>> >>> >>> On 08/31/2015 09:03 PM, Atin Mukherjee wrote: >>>> >>>> On 09/01/2015 01:00 AM, Merlin Morgenstern wrote: >>>>> >>>>> this all makes sense and sounds a bit like a solr setup :-) >>>>> >>>>> I have now added the third node as a peer >>>>> sudo gluster peer probe gs3 >>>>> >>>>> That indeed allow me to mount the share manually on node2 even if >>>>> node1 is >>>>> down. >>>>> >>>>> BUT: It does not mount on reboot! It only successfully mounts if >>>>> node1 is >>>>> up. I need to do a manual: sudo mount -a >>>> >>>> You would need to ensure that at least two of the nodes are up in the >>>> cluster in this case. >>> >>> Atin, why? I've never had that restriction. >>> >>> It sounds to me like the mount's trying to happen before any bricks are >>> available and/or glusterd is listening. >> >> In a 3 node cluster if two of the nodes are already down and the other >> is rebooted then the GlusterD instance wouldn't start the brick process >> until it receives the first handshake from one of its peer and for that >> you would need your 2nd node to be up as well. This why its recommended >> to have a 3rd dummy node (without any bricks) added to a existing 2 node >> cluster. > > > Again I ask, is this a departure from prior behavior? Not really, its there from long time. IIRC, this change was done when quorum feature was introduced. KP can correct me. > > >>>>> Is there a particular reason for this, or is it a misconfiguration? >>>>> >>>>> >>>>> >>>>> 2015-08-31 21:01 GMT+02:00 Joe Julian <[email protected]>: >>>>> >>>>>> On 08/31/2015 10:41 AM, Vijay Bellur wrote: >>>>>> >>>>>>> On Monday 31 August 2015 10:42 PM, Atin Mukherjee wrote: >>>>>>> >>>>>>>> > 2. Server2 dies. Server1 has to reboot. >>>>>>>> > >>>>>>>> > In this case the service stays down. It is inpossible to >>>>>>>> remount the >>>>>>>> share without Server1. This is not acceptable for a High Availability >>>>>>>> System and I believe also not intended, but a misconfiguration or >>>>>>>> bug. >>>>>>>> This is exactly what I gave as an example in the thread (please read >>>>>>>> again). GlusterD is not supposed to start brick process if its other >>>>>>>> counter part hasn't come up yet in a 2 node setup. The reason it has >>>>>>>> been designed in this way is to block GlusterD on operating on a >>>>>>>> volume >>>>>>>> which could be stale as the node was down and cluster was operational >>>>>>>> earlier. >>>>>>>> >>>>>>> For two node deployments, a third dummy node is recommended to ensure >>>>>>> that quorum is maintained when one of the nodes is down. >>>>>>> >>>>>>> Regards, >>>>>>> Vijay >>>>>>> >>>>>> Have the settings changed to enable server quorum by default? >>>>>> >>>>>> _______________________________________________ >>>>>> Gluster-users mailing list >>>>>> [email protected] >>>>>> http://www.gluster.org/mailman/listinfo/gluster-users >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Gluster-users mailing list >>>>> [email protected] >>>>> http://www.gluster.org/mailman/listinfo/gluster-users >>>>> >>> > > _______________________________________________ > Gluster-users mailing list > [email protected] > http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
