For clarity "no return" from 'gluster volume heal <volname> info':
# gluster volume heal vm-storage info
Brick 10.0.231.50:/mnt/lv-vm-storage/vm-storage
Number of entries: 0
Brick 10.0.231.51:/mnt/lv-vm-storage/vm-storage
Number of entries: 0
Brick 10.0.231.52:/mnt/lv-vm-storage/vm-storage
Number of entries: 0
On Thu, Feb 25, 2016 at 12:02 PM, Steve Dainard <sdainard@xxxxxxxx> wrote:
I haven't done anything more than peer thus far, so I'm a bit confused as to how the volume info fits in, can you expand on this a bit?Failed commits? Is this split brain on the replica volumes? I don't get any return from 'gluster volume heal <volname> info' on all the replica volumes, but if I try a gluster volume heal <volname> full I get: 'Launching heal operation to perform full self heal on volume <volname> has been unsuccessful'.I have 5 volumes total.'Replica 3' volumes running on gluster01/02/03:vm-storageiso-storageexport-domain-storageenv-modulesAnd one distributed only volume 'storage' info shown below:From existing host gluster01/02:type=0count=4status=1sub_count=0stripe_count=1replica_count=1disperse_count=0redundancy_count=0version=25transport-type=0volume-id=26d355cb-c486-481f-ac16-e25390e73775username=eb9e2063-6ba8-4d16-a54f-2c7cf7740c4cpassword=op-version=3client-op-version=3quota-version=1parent_volname=N/Arestored_from_snap=00000000-0000-0000-0000-000000000000snap-max-hard-limit=256features.quota-deem-statfs=onfeatures.inode-quota=ondiagnostics.brick-log-level=WARNINGfeatures.quota=onperformance.readdir-ahead=onperformance.cache-size=1GBperformance.stat-prefetch=onbrick-0=10.0.231.50:-mnt-raid6-storage-storagebrick-1=10.0.231.51:-mnt-raid6-storage-storagebrick-2=10.0.231.52:-mnt-raid6-storage-storagebrick-3=10.0.231.53:-mnt-raid6-storage-storageFrom existing host gluster03/04:type=0count=4status=1sub_count=0stripe_count=1replica_count=1disperse_count=0redundancy_count=0version=25transport-type=0volume-id=26d355cb-c486-481f-ac16-e25390e73775username=eb9e2063-6ba8-4d16-a54f-2c7cf7740c4cpassword=op-version=3client-op-version=3quota-version=1parent_volname=N/Arestored_from_snap=00000000-0000-0000-0000-000000000000snap-max-hard-limit=256features.quota-deem-statfs=onfeatures.inode-quota=onperformance.stat-prefetch=onperformance.cache-size=1GBperformance.readdir-ahead=onfeatures.quota=ondiagnostics.brick-log-level=WARNINGbrick-0=10.0.231.50:-mnt-raid6-storage-storagebrick-1=10.0.231.51:-mnt-raid6-storage-storagebrick-2=10.0.231.52:-mnt-raid6-storage-storagebrick-3=10.0.231.53:-mnt-raid6-storage-storageSo far between gluster01/02 and gluster03/04 the configs are the same, although the ordering is different for some of the features.On gluster05/06 the ordering is different again, and the quota-version=0 instead of 1.From new hosts gluster05/gluster06:type=0count=4status=1sub_count=0stripe_count=1replica_count=1disperse_count=0redundancy_count=0version=25transport-type=0volume-id=26d355cb-c486-481f-ac16-e25390e73775username=eb9e2063-6ba8-4d16-a54f-2c7cf7740c4cpassword=op-version=3client-op-version=3quota-version=0parent_volname=N/Arestored_from_snap=00000000-0000-0000-0000-000000000000snap-max-hard-limit=256performance.stat-prefetch=onperformance.cache-size=1GBperformance.readdir-ahead=onfeatures.quota=ondiagnostics.brick-log-level=WARNINGfeatures.inode-quota=onfeatures.quota-deem-statfs=onbrick-0=10.0.231.50:-mnt-raid6-storage-storagebrick-1=10.0.231.51:-mnt-raid6-storage-storagebrick-2=10.0.231.52:-mnt-raid6-storage-storagebrick-3=10.0.231.53:-mnt-raid6-storage-storageAlso, I forgot to mention that when I initially peer'd the two new hosts, glusterd crashed on gluster03 and had to be restarted (log attached) but has been fine since.Thanks,SteveOn Thu, Feb 25, 2016 at 11:27 AM, Mohammed Rafi K C <rkavunga@xxxxxxxxxx> wrote:
On 02/25/2016 11:45 PM, Steve Dainard wrote:
Hello,
I upgraded from 3.6.6 to 3.7.6 a couple weeks ago. I just peered 2 new nodes to a 4 node cluster and gluster peer status is:
# gluster peer status <-- from node gluster01
Number of Peers: 5
Hostname: 10.0.231.51
Uuid: b01de59a-4428-486b-af49-cb486ab44a07
State: Peer in Cluster (Connected)
Hostname: 10.0.231.52
Uuid: 75143760-52a3-4583-82bb-a9920b283dac
State: Peer in Cluster (Connected)
Hostname: 10.0.231.53
Uuid: 2c0b8bb6-825a-4ddd-9958-d8b46e9a2411
State: Peer in Cluster (Connected)
Hostname: 10.0.231.54 <-- new node gluster05
Uuid: 408d88d6-0448-41e8-94a3-bf9f98255d9c
State: Peer Rejected (Connected)
Hostname: 10.0.231.55 <-- new node gluster06
Uuid: 9c155c8e-2cd1-4cfc-83af-47129b582fd3
State: Peer Rejected (Connected)
Looks like your configuration files are mismatching, ie the checksum calculation differs on this two node than the others,
Did you had any failed commit ?
Compare your /var/lib/glusterd/<volname>/info of the failed node against good one, mostly you could see some difference.
can you paste the /var/lib/glusterd/<volname>/info ?
Regards
Rafi KC
I followed the write-up here: http://www.gluster.org/community/documentation/index.php/Resolving_Peer_Rejected and the two new nodes peer'd properly but after a reboot of the two new nodes I'm seeing the same Peer Rejected (Connected) State.
I've attached logs from an existing node, and the two new nodes.
Thanks for any suggestions,Steve
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users