> On Mar 7, 2018, at 4:39 AM, Atin Mukherjee wrote:
>
> Please run 'gluster v get all cluster.max-op-version' and what ever value it
> throws up should be used to bump up the cluster.op-version (gluster v set all
> cluster.op-version ) . With that if you restart the
Please run 'gluster v get all cluster.max-op-version' and what ever value
it throws up should be used to bump up the cluster.op-version (gluster v
set all cluster.op-version ) . With that if you restart the rejected
peer I believe the problem should go away, if it doesn't I'd need to
investigate
> On Mar 5, 2018, at 6:41 PM, Atin Mukherjee wrote:
> I'm tempted to repeat - down things, copy the checksum the "good" ones agree
> on, start things; but given that this has turned into a balloon-squeezing
> exercise, I want to make sure I'm not doing this the wrong way.
Just following up on the below after having some time to track down the
differences.
On the bad peer, the `tier-enabled=0` line in .../vols//info was
removed after I copied it over and as mentioned, the cksum file changed to a
value that doesn't match the others. The logs only complain about
> On Mar 5, 2018, at 6:41 PM, Atin Mukherjee wrote:
>
>
>
> On Tue, Mar 6, 2018 at 6:00 AM, Jamie Lawrence
> wrote:
> Hello,
>
> So I'm seeing a rejected peer with 3.12.6. This is with a replica 3 volume.
>
> It actually began as the same
On Tue, Mar 6, 2018 at 6:00 AM, Jamie Lawrence
wrote:
> Hello,
>
> So I'm seeing a rejected peer with 3.12.6. This is with a replica 3 volume.
>
> It actually began as the same problem with a different peer. I noticed
> with (call it) gluster-2, when I couldn't make a
Hello,
So I'm seeing a rejected peer with 3.12.6. This is with a replica 3 volume.
It actually began as the same problem with a different peer. I noticed with
(call it) gluster-2, when I couldn't make a new volume. I compared
/var/lib/glusterd between them, and found that somehow the options