I am suspecting it to be new quota-version introduced in the volume info file which may have resulted in a checksum mismatch resulting into peer rejection. But we can confirm it from log files and respective info file content.
On Saturday 23 July 2016, B.K.Raghuram <[email protected]> wrote: > Unfortunately, the setup is at a customer's place which is not remotely > accessible. Will try and get it by early next week. But could it just be a > mismatch of the /var/lib/glusterd files? > > On Fri, Jul 22, 2016 at 8:07 PM, Atin Mukherjee <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Glusterd logs from all the nodes please? >> >> >> On Friday 22 July 2016, B.K.Raghuram <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >>> When we upgrade some nodes from 3.6.1 to 3.7.13, some of the nodes give >>> a peer status of "peer rejected" while some dont. Is there a reason for >>> this discrepency and will the steps mentioned in >>> http://gluster-documentations.readthedocs.io/en/latest/Administrator%20Guide/Resolving%20Peer%20Rejected/ >>> work for this as well? >>> >>> Just out of curiosity, why the line "Try the whole procedure a couple >>> more times if it doesn't work right away." in the link above? >>> >> >> >> -- >> Atin >> Sent from iPhone >> > > -- Atin Sent from iPhone
_______________________________________________ Gluster-users mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-users
