On 30-Jul-2013 10:26 PM, "Jay Vyas" <jayunit100 at gmail.com> wrote: > > It appears that some peer probes only work in one direction. > Why is that the case? > A peer already at a higher op-version possibly could have volumes which have newer features enabled. A cluster operating at a lower op-version wouldn't be able to support these volumes and hence will reject a peer of at a higher op-version. The other way round, with the cluster operating at higher op-version and the peer being probed operating at the lower op-version can succeed, provided that the peer supports the higher op-version. > I guess the mystery lies in the "op" version value. Not sure what that refers to - im using 3.4git, so I assume all versions should be the same even though the build dates are slightly off, because i build from source on all servers. > > Example.. > > [root at hbase-regionserver3 ~]# gluster peer probe hbase-head > peer probe: failed: Peer hbase-head is already at a higher op-version > This is the first type of probing described. > [root at hbase-regionserver3 ~]# exit > > [root at hbase-master ~]# gluster peer probe hbase-regionserver3 > peer probe: success > This is the second case. > > > -- > Jay Vyas > http://jayunit100.blogspot.com > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-users As I was writing this mail, I found a potential problem. With the current implementation, a freshly installed peer will start operating with the highest possible op-version, to be able to use all the new features at once. Because of this a newly installed peer, will not be able to join a freshly upgraded cluster. An upgraded peer will operate at the saved op-version if found, or the minimum op-version. This is to allow for the safe upgrade of all peers in a cluster, one at a time. Even after all peers are upgraded, the cluster will not move to the higher op-version automatically. The cluster op-version will be bumped only when a new feature is enabled. This is to allow older clients to continue working with the volumes in the cluster. There are 2 workarounds to this for now, 1. Enable a new feature on any volume in the cluster, which will bump up the cluster op-version and allow it to probe the new peer. 2. Remove the 'operating-version' line from /var/lib/glusterd/glusterd.infofile on the new peer. This will cause the peer to start operating at the minimum possible op-version, and it can then be probed. (Now that I've written this here, I need to document this some place, probably the gluster wiki.) ~kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130731/be3da3d8/attachment-0001.html>
