[Gluster-users] failing commits

[lejeczek]

On 01/02/17 14:44, Atin Mukherjee wrote:
> I think you have hit 
> https://bugzilla.redhat.com/show_bug.cgi?id=1406411 which 
> has been fixed in mainline and will be available in 
> release-3.10 which is slated for next month.
>
> To prove you have hit the same problem can you please 
> confirm the following:
>
> 1. Which Gluster version are you running?
> 2. Was any of the existing brick down?
> 2. Did you mounted the volume? If not you have two ways 
> (1) bring up the brick and restart glusterd followed by 
> add-brick or (2) if the existing brick(s) is bad for some 
> reason, restarting glusterd and mounting the volume 
> followed by a look up and then attempting add-brick should 
> succeed.
>
>
a chance to properly investigate it has been lost I think.
I all started with one peer I missed was not migrated from 
3.7 to 3.8 and unfortunately it was a system I could not 
tamper with until late evening, which is now.
This problem though occurred after I already upgraded that 
gluster to 3.8. I even removed that failing node's bricks 
and detached it, re-attached it and still, those errors I 
described earlier... until now when I restarted that one 
last one peer... now all seems ok, well, at least I don't 
see those errors any more.

Should I now be looking at something particular more closely?
b.w.
L.


> On Wed, Feb 1, 2017 at 7:49 PM, lejeczek 
> <peljasz at yahoo.co.uk <mailto:peljasz at yahoo.co.uk>> wrote:
>
>     hi,
>
>     I have a four peers gluster and one is failing, well,
>     kind of..
>     If on a working peer I do:
>
>     $ gluster volume add-brick QEMU-VMs replica 3
>     10.5.6.49:/__.aLocalStorages/0/0-GLUSTERs/0GLUSTER-QEMU-VMs
>     force
>     volume add-brick: failed: Commit failed on whale.priv
>     Please check log file for details.
>
>     but:
>
>     $ gluster vol info QEMU-VMs
>     Volume Name: QEMU-VMs
>     Type: Replicate
>     Volume ID: 8709782a-daa5-4434-a816-c4e0aef8fef2
>     Status: Started
>     Snapshot Count: 0
>     Number of Bricks: 1 x 3 = 3
>     Transport-type: tcp
>     Bricks:
>     Brick1:
>     10.5.6.100:/__.aLocalStorages/1/0-GLUSTERs/1GLUSTER-QEMU-VMs
>     Brick2: 10.5.6.17:/__.aLocalStorages/1/0-GLUSTERs/QEMU-VMs
>     Brick3:
>     10.5.6.49:/__.aLocalStorages/0/0-GLUSTERs/0GLUSTER-QEMU-VMs
>     # <= so it is here, also this command on that failing
>     peers reports correctly.
>
>     Interestingly,
>
>     $ gluster volume remove-brick
>
>     removes no errors, but this change is not propagated
>     to the failing peer. Vol info still reports its brick
>     is part of the volume.
>
>     And the failing completely part: every command on
>     failing peer reports:
>
>     $ gluster volume remove-brick QEMU-VMs replica 2
>     10.5.6.49:/__.aLocalStorages/0/0-GLUSTERs/0GLUSTER-QEMU-VMs
>     force
>     Removing brick(s) can result in data loss. Do you want
>     to Continue? (y/n) y
>     volume remove-brick commit force: failed: Commit
>     failed on 10.5.6.32. Please check log file for details.
>     Commit failed on rider.priv Please check log file for
>     details.
>     Commit failed on 10.5.6.17. Please check log file for
>     details.
>
>     I've been watching logs but honestly, don't know which
>     one(s) I should paste in here.
>     b.w.
>     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>
>
>
>
>
> -- 
>
> ~ Atin (atinm)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170201/adf11e6c/attachment.html>