Re: Why is it not possible to mount a replicated gluster volume with one Gluster server?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxxxxxxxxx>:

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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users


_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users



_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users



[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux