hi fellas, same old same in log of the probing peer I see: ... 2017-08-29 13:36:16.882196] I [MSGID: 106493] [glusterd-handler.c:3020:__glusterd_handle_probe_query] 0-glusterd: Responded to priv.xx.xx.priv.xx.xx.x, op_ret: 0, op_errno: 0, ret: 0 [2017-08-29 13:36:16.904961] I [MSGID: 106490] [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] 0-glusterd: Received probe from uuid: 2a17edb4-ae68-4b67-916e-e38a2087ca28 [2017-08-29 13:36:16.906477] E [MSGID: 106010] [glusterd-utils.c:3034:glusterd_compare_friend_volume] 0-management: Version of Cksums CO-DATA differ. local cksum = 4088157353, remote cksum = 2870780063 on peer 10.5.6.17 [2017-08-29 13:36:16.907187] I [MSGID: 106493] [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] 0-glusterd: Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 ... Why would adding a new peer make cluster jump to check checksums on a vol on that newly added peer? Is it why the peer gets rejected? That peer I'm hoping to add, was a member of the cluster in the past but I did "usual" wipe of /var/lib/gluster on candidate peer. a hint, solution would be great to hear. L.
Could you please send me "info" file which is placed in "/var/lib/glusterd/vols/<vol-name>" directory from all the nodes along with glusterd.logs and command-history. Thanks Gaurav On Tue, Aug 29, 2017 at 7:13 PM, lejeczek <peljasz at yahoo.co.uk> wrote:> hi fellas, > same old same > in log of the probing peer I see: > ... > 2017-08-29 13:36:16.882196] I [MSGID: 106493] > [glusterd-handler.c:3020:__glusterd_handle_probe_query] 0-glusterd: > Responded to priv.xx.xx.priv.xx.xx.x, op_ret: 0, op_errno: 0, ret: 0 > [2017-08-29 13:36:16.904961] I [MSGID: 106490] > [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] > 0-glusterd: Received probe from uuid: 2a17edb4-ae68-4b67-916e-e38a2087ca28 > [2017-08-29 13:36:16.906477] E [MSGID: 106010] > [glusterd-utils.c:3034:glusterd_compare_friend_volume] 0-management: > Version of Cksums CO-DATA differ. local cksum = 4088157353, remote cksum > 2870780063 on peer 10.5.6.17 > [2017-08-29 13:36:16.907187] I [MSGID: 106493] > [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] 0-glusterd: > Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 > ... > > Why would adding a new peer make cluster jump to check checksums on a vol > on that newly added peer? Is it why the peer gets rejected? > That peer I'm hoping to add, was a member of the cluster in the past but I > did "usual" wipe of /var/lib/gluster on candidate peer. > > a hint, solution would be great to hear. > L. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170830/a602fda1/attachment.html>
On 30/08/17 07:18, Gaurav Yadav wrote:> > Could you please send me "info" file which is placed in > "/var/lib/glusterd/vols/<vol-name>" directory from all the > nodes along with > glusterd.logs and command-history. >I've send you some logs, thanks. One more possibly interesting fact - now when fourth(rejected) peer was detached I still see in "/var/lib/glusterd/vols/<vol-name>" vol-name.client.10.5.6.17..... (which is IP of the rejected peer) and the same with .rpmsave Only on two out of three peers which constitute a healthy cluster. One peer does not have these files. I wonder - was it upgrade from 3.8 to 3.10 that caused this problem. Can these file be deleted? And if yes would this be enough?> Thanks > Gaurav > > On Tue, Aug 29, 2017 at 7:13 PM, lejeczek > <peljasz at yahoo.co.uk <mailto:peljasz at yahoo.co.uk>> wrote: > > hi fellas, > same old same > in log of the probing peer I see: > ... > 2017-08-29 13:36:16.882196] I [MSGID: 106493] > [glusterd-handler.c:3020:__glusterd_handle_probe_query] > 0-glusterd: Responded to priv.xx.xx.priv.xx.xx.x, > op_ret: 0, op_errno: 0, ret: 0 > [2017-08-29 13:36:16.904961] I [MSGID: 106490] > [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] > 0-glusterd: Received probe from uuid: > 2a17edb4-ae68-4b67-916e-e38a2087ca28 > [2017-08-29 13:36:16.906477] E [MSGID: 106010] > [glusterd-utils.c:3034:glusterd_compare_friend_volume] > 0-management: Version of Cksums CO-DATA differ. local > cksum = 4088157353, remote cksum = 2870780063 on peer > 10.5.6.17 > [2017-08-29 13:36:16.907187] I [MSGID: 106493] > [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] > 0-glusterd: Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 > ... > > Why would adding a new peer make cluster jump to check > checksums on a vol on that newly added peer? Is it why > the peer gets rejected? > That peer I'm hoping to add, was a member of the > cluster in the past but I did "usual" wipe of > /var/lib/gluster on candidate peer. > > a hint, solution would be great to hear. > L. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > <mailto:Gluster-users at gluster.org> > http://lists.gluster.org/mailman/listinfo/gluster-users > <http://lists.gluster.org/mailman/listinfo/gluster-users> > >
On 30/08/17 07:18, Gaurav Yadav wrote:> > Could you please send me "info" file which is placed in > "/var/lib/glusterd/vols/<vol-name>" directory from all the > nodes along with > glusterd.logs and command-history. > > Thanks > Gaurav > > On Tue, Aug 29, 2017 at 7:13 PM, lejeczek > <peljasz at yahoo.co.uk <mailto:peljasz at yahoo.co.uk>> wrote: > > hi fellas, > same old same > in log of the probing peer I see: > ... > 2017-08-29 13:36:16.882196] I [MSGID: 106493] > [glusterd-handler.c:3020:__glusterd_handle_probe_query] > 0-glusterd: Responded to priv.xx.xx.priv.xx.xx.x, > op_ret: 0, op_errno: 0, ret: 0 > [2017-08-29 13:36:16.904961] I [MSGID: 106490] > [glusterd-handler.c:2606:__glusterd_handle_incoming_friend_req] > 0-glusterd: Received probe from uuid: > 2a17edb4-ae68-4b67-916e-e38a2087ca28 > [2017-08-29 13:36:16.906477] E [MSGID: 106010] > [glusterd-utils.c:3034:glusterd_compare_friend_volume] > 0-management: Version of Cksums CO-DATA differ. local > cksum = 4088157353, remote cksum = 2870780063 on peer > 10.5.6.17 > [2017-08-29 13:36:16.907187] I [MSGID: 106493] > [glusterd-handler.c:3866:glusterd_xfer_friend_add_resp] > 0-glusterd: Responded to 10.5.6.17 (0), ret: 0, op_ret: -1 > ... > > Why would adding a new peer make cluster jump to check > checksums on a vol on that newly added peer? >really. I mean, no brick even exists on newly added peer, it's just been probed, why this?: [2017-08-30 13:17:51.949430] E [MSGID: 106010] [glusterd-utils.c:3034:glusterd_compare_friend_volume] 0-management: Version of Cksums CO-DATA differ. local cksum = 4088157353, remote cksum = 2870780063 on peer 10.5.6.17 10.5.6.17 is a candidate I'm probing from a working cluster. Why gluster wants checksums and why checksums would be different? Would anybody know what is going on there?> Is it why the peer gets rejected? > That peer I'm hoping to add, was a member of the > cluster in the past but I did "usual" wipe of > /var/lib/gluster on candidate peer. > > a hint, solution would be great to hear. > L. > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > <mailto:Gluster-users at gluster.org> > http://lists.gluster.org/mailman/listinfo/gluster-users > <http://lists.gluster.org/mailman/listinfo/gluster-users> > >