一、问题重现
我们已有9台部署有glusterfs3.7.2的服务器(qserver0, qserver1, … qserver8)，现在想新加入3台服务器(qserver9, qserver0, qserver11)。11台机器的ip分别是：192.168.0.130, 192.168.0.131, …, 192.168.0.141。我们一直都通过以下方式来安装glusterfs:
-
step1：将以下内容新建到文件
/etc/yum.repos.d/glusterfs-epel.repo中Place this file in your /etc/yum.repos.d/ directory
[glusterfs-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel-releasever/ basearch/
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub
[glusterfs-noarch-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes.
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel-$releasever/noarch
enabled=1
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub
[glusterfs-source-epel]
name=GlusterFS is a clustered file-system capable of scaling to several petabytes. - Source
baseurl=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/EPEL.repo/epel-$releasever/SRPMS
enabled=0
skip_if_unavailable=1
gpgcheck=1
gpgkey=http://download.gluster.org/pub/gluster/glusterfs/3.7/LATEST/rsa.pub step2:用以下命令安装
glusterfs
sudo yum install glusterfs-server但此时的LATEST版本已经是glusterfs3.7.18了。
为保持一致性，我们直接将旧的9台机器update到gluster3.7.18。然后再从qserver8中添加qserver11节点：
sudo gluster peer probe 192.168.0.141此时查看peer状态
sudo gluster peer statusqserver8机器上如下： 
qserver11机器上如下：
[当时没有截图，汗。。。]也是State: Peer Rejected (Connected)的状态
二、问题探索
发现1：
通过对比qserver0~qserver8和qserver11中的/var/lib/glusterfs中的内容，我们发现qserver0~qserer8中的/var/lib/glusterfs/vols/{vol_name}/cksum的值都相同，但qserver11中的cksum值和他们不同。
怀疑1：cksum的不同是问题的根源，考虑手动修改cksum
发现2：
我在qserver11上手动将cksum修改为和qserver8一致，再重新启动glusterd：
sudo systemctl restart glusterd发现重启服务失败，/var/log/glusterfs/etc-glusterfs-glusterd.vol.log中记录错误如下： 
初步发现此时只能将/var/lib/glusterfs整个文件夹删除再重新启动
结论1：一旦通过qserver8将qserver11 porbe之后，qserver11上的glusterd就无法重启了。所以不能手动修改qserver11的cksum，考虑曲线救国，修改qserver0~qserver8上的cksum
发现3：
先对qserver8进行尝试
修改
qserver8的cksum和qserver11上的一致，再重启qserver8上的glusterd，发现qserver8上的cksum又恢复了原来的值。由此可知，glusterd在重启时会计算并重写cksum。进一步阅读
glusterfs-3.7.18源码，发现cksum是对/var/lib/glusterfs/vols/{vol_name}/info的内容进行计算。对比
qserver8和qserver11的/var/lib/glusterfs/vols/{vol_name}/info内容，发现qserver11中缺少一行quota-version=0
怀疑2：glusterfs-3.7.2的info内容会存在quota-version=0,但glusterfs-3.7.18的info内容并不会存在quota-version=0。而glusterfs在从3.7.2升级到3.7.18时，并不会更新已存在的info的内容，从而导致了这种不一致。
发现4：
将qserver8中的info中的quota-version=0全部删去，再重新probe qserver11。发现 qserver8和qserver11正常连接：Status: Peer in Cluster(Connected) qserver8和qserver0~qserver7连接异常： State: Peer Rejected (Connected)
结论2：由此我们可以印证，确实是因为info不一致导致cksum不一致，再导致rejected(connected)
发现5：
就在我考虑将qserver0~qserver7也都像qserver8那样修改时，发现一个问题：
sudo gluster volume status {vol_name}qserver8上的volume信息出错了，也就是说qserver8其实是脱离了qserver0~qserver7了。如果将qserver0~qserver7也都修改了，虽然qserver0~qserver8和qserver11互相peer in cluster了，但他们原来的volume都异常了
结论3：我们只能再次回归到qserver11上，看看为什么怀疑1中发现的qserver11就无法重启了。只要解决了qserver11重启， 问题也就解决了
发现6：
通过修改glusterfs的日志打印级别至DEBUG
sudo vim /usr/lib/systemd/system/glusterd.service对照/var/log/glusterfs/etc-glusterfs-glusterd.vol.log和glustetfs-3.7.18的源代码，log中提示是因为无法找到qserver2。找到glusterfs-3.7.18中对应的源码，知道glusterd在启动的时候，会将/var/lib/glusterd/vols/{vol_name}/中的brick信息的hostname，用peers来解析。
因为peers中只有probe失败之后的qserver8信息，自然无法解析qserver2
结论4：只要补全qserver11中/var/lib/glusterd/peers中的信息即可
三、问题解决
step1：
qserver8:
sudo gluster peer probe 192.168.0.141step2:
qserver11:
根据qserver8上的内容将qserver8上的 /var/lib/glusterd/peers信息补全
step3:
qserver11:
将/var/lib/glusterd/vols/{vol_name}/info中的quota-version=0去掉
step4:
qserver11:
sudo systemctl restart glusterd