Broken gluster ... Help required

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

 



On 07/04/2013 10:25 PM, HL wrote:
> On 04/07/2013 07:39 ??, Vijay Bellur wrote:
>> On 07/04/2013 07:36 PM, HL wrote:
>>> Hello list,
>>>
>>> I have a 2 node replica  clusterfs
>>>
>>> Volume Name: GLVol
>>> Type: Replicate
>>> Volume ID: 2106bc3d-d184-42db-ab6e-e547ff816113
>>> Status: Started
>>> Number of Bricks: 1 x 2 = 2
>>> Transport-type: tcp
>>> Bricks:
>>> Brick1: node01:/export/fm_glust
>>> Brick2: node02:/export/fe_glust
>>> Options Reconfigured:
>>> auth.allow: 172.16.35.*
>>> geo-replication.indexing: on
>>>
>>>
>>> After a cable faillure I Have an unstable system,
>>>
>>> gluster volume heal GLVol info split-brain
>>>
>>> Gives about 1000 of these entries ..
>>>
>>> 2013-07-04 16:46:10 <gfid:ce073ea9-a95a-4c5e-b2bd-7db1e26cbad7>
>>> 2013-07-04 16:46:10 <gfid:0d7ff6b2-5ed1-4584-b0e3-9f0c723463b8>
>>> 2013-07-04 16:46:10 /vz_data/mySQLDBS/var/lib/mysql/ib_logfile0
>>>
>>> I've found a script in the users list on how to deal with
>>> /vz_data/mySQLDBS/var/lib/mysql/ib_logfile0
>>> that is known path files
>>>
>>> but don't know how to deal with the hex entries ...  they seem to me as
>>> orphans ...
>>
>> The hex entries are "gfid"s used by GlusterFS for identifying files
>> and are not orphan objects. A gfid that cannot be resolved to a path
>> by the server immediately, would appear with the hex representation.
>>
>>>
>>> Is ok To delete them ???
>>
>> Unless the files are in split brain, it is not a good idea to delete
>> them. Letting the self-heal daemon heal these files would be a better
>> approach.
>>
>
> Thank's Vijay
>
> I am not sure I can follow
> as I stated
> the output of
> gluster volume heal GLVol info split-brain

I am sorry, I missed the split-brain part in the original post.

>
> was
>
> 2013-07-04 16:46:10 <gfid:ce073ea9-a95a-4c5e-b2bd-7db1e26cbad7>
> 2013-07-04 16:46:10 <gfid:0d7ff6b2-5ed1-4584-b0e3-9f0c723463b8>
> 2013-07-04 16:46:10 /vz_data/mySQLDBS/var/lib/mysql/ib_logfile0
>
> So it seems to me that they are in split-brain
>
> Other than that ..
> How can I make sure that  the self-heal daemon
> is running and is healing indeed the files
>
> gluster  volume status all
> shows
>
> Status of volume: GLVol
> Gluster process                        Port    Online    Pid
> ------------------------------------------------------------------------------
>
> Brick node01:/export/fm_glust                24009    Y    2614
> Brick node02:/export/fe_glust                24009    Y    2746
> NFS Server on localhost                    38467    Y    2752
> Self-heal Daemon on localhost                N/A    Y    2758
> NFS Server on node01                    38467    Y    2626
> Self-heal Daemon on node01                N/A    Y    2632

Volume status is the right way to determine if self-heal daemon is running.

>
>
> So
> Delete them or not???

To resolve split-brain, you will need to delete/mv one copy of the 
replica that you don't consider correct.

>
> If self healing is doing any progress
> My bricks are about 500G in size containg about 400K file entries
> the two bricks are connected with a dedicated 1G nic
> how long will it take to heal ???

Resolving split-brain needs manual intervention. You can use "volume 
heal <volname> info" to see the activity of self-heal daemon.

Regards,
Vijay


[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