[Gluster-users] Why is it not possible to mount a replicated gluster volume with one Gluster server?

Joe Julian joe at julianfamily.org
Tue Sep 1 16:09:18 UTC 2015



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?

>>>> Is there a particular reason for this, or is it a misconfiguration?
>>>>
>>>>
>>>>
>>>> 2015-08-31 21:01 GMT+02:00 Joe Julian <joe at julianfamily.org>:
>>>>
>>>>> 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
>>>>> Gluster-users at gluster.org
>>>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>>>>
>>>>
>>>> _______________________________________________
>>>> Gluster-users mailing list
>>>> Gluster-users at gluster.org
>>>> http://www.gluster.org/mailman/listinfo/gluster-users
>>>>
>>



More information about the Gluster-users mailing list