peer status rejected (connected)

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

 



On 06/08/13 21:25, Kaushal M wrote:
> Toby,
> What versions of gluster are on the peers? And does the cluster have
> just two peers or more?

Version 3.3.1.
The cluster has/had two nodes; we're trying to replace one with another one.

> On Tue, Aug 6, 2013 at 4:32 PM, Toby Corkindale
> <toby.corkindale at strategicdata.com.au> wrote:
>> ----- Original Message -----
>>> From: "Toby Corkindale" <toby.corkindale at strategicdata.com.au>
>>> To: gluster-users at gluster.org
>>> Sent: Tuesday, 6 August, 2013 6:26:59 PM
>>> Subject: Re: peer status rejected (connected)
>>>
>>> On 06/08/13 18:12, Toby Corkindale wrote:
>>>> Hi,
>>>> What does it mean when you use "peer probe" to add a new host, but then
>>>> afterwards the "peer status" is reported as "Rejected" yet "Connected"?
>>>> And of course -- how does one fix this?
>>>>
>>>> gluster> peer status
>>>> Number of Peers: 1
>>>>
>>>> Hostname: 192.168.10.32
>>>> Uuid: 32497846-6e02-4b68-b147-6f4b936b3373
>>>> State: Peer Rejected (Connected)
>>>
>>> It's worth noting that the attempt to probe the peer was listed as
>>> successful though:
>>>
>>> gluster> peer probe mel-storage04
>>>
>>> Probe successful
>>> gluster> peer status
>>> Number of Peers: 1
>>>
>>> Hostname: mel-storage04
>>> Uuid: 6254c24d-29d4-4794-8159-3c2b03b34798
>>> State: Peer Rejected (Connected)
>>>
>>
>>
>> After searching around some more, I saw that this issue is usually caused by two peers joining, when one has a very out of date volume list.
>> And indeed, in the log files I see messages about checksums failing to agree on volumes being exchanged.
>>
>> The odd thing is, this is a fresh server, running the same version of glusterfs.
>> I tried stopping the services entirely, rm -rf /var/lib/glusterfs/*, and then started up again and tried probing that peer -- and received the same Rejection.
>> I'm confused as to how it could possibly be getting a different volume checksum, when it didn't even have its own copy.
>>
>> Does the community have any suggestions about resolving this?
>>
>> See also, inability to remove or replace bricks in separate message - which might be related, although the errors occur even if run on the cluster without this problematic peer attached at all.
>>
>> -Toby



[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