[Gluster-users] Help with reconnecting a faulty brick
Ravishankar N
ravishankar at redhat.com
Thu Nov 16 12:07:41 UTC 2017
On 11/16/2017 12:54 PM, Daniel Berteaud wrote:
> Le 15/11/2017 à 09:45, Ravishankar N a écrit :
>> If it is only the brick that is faulty on the bad node, but
>> everything else is fine, like glusterd running, the node being a part
>> of the trusted storage pool etc, you could just kill the brick first
>> and do step-13 in "10.6.2. Replacing a Host Machine with the Same
>> Hostname", (the mkdir of non-existent dir, followed by setfattr of
>> non-existent key) of
>> https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/pdf/Administration_Guide/Red_Hat_Storage-3.1-Administration_Guide-en-US.pdf,
>> then restart the brick by restarting glusterd on that node. Read 10.5
>> and 10.6 sections in the doc to get a better understanding of
>> replacing bricks.
>
> Thanks, I'll try that.
> Any way in this situation to check which file will be healed from
> which brick before reconnecting ? Using some getfattr tricks ?
Yes, there are afr xattrs that determine the heal direction for each
file. The good copy will have non-zero trusted.afr* xattrs that blame
the bad one and heal will happen from good to bad. If both bricks have
attrs blaming the other, then the file is in split-brain.
-Ravi
>
> Regards, Daniel
>
> --
>
> Logo FWS
>
> *Daniel Berteaud*
>
> FIREWALL-SERVICES SAS.
> Société de Services en Logiciels Libres
> Tel : 05 56 64 15 32 <tel:0556641532>
> Matrix: @dani:fws.fr
> /www.firewall-services.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20171116/6c36b343/attachment.html>
More information about the Gluster-users
mailing list