出于存储安全的需要,近期新建了一个分布式复本卷来存储一些重要数据。服务器从gfserver20-29,然而使用没几天,一台服务器gfserver26的操作系统就崩溃了,一执行命令就报I/O error,应该是硬盘挂掉了。运维的同事帮忙更换了硬盘了,重新安装了操作系统。不幸的是复本卷的数据也被格式化了。幸好这个卷是复本卷,新的设备上线之后,可以重新进入集群,并恢复成原貌。这就是复本卷的优势。
下面记录一下恢复过程遇到的问题,方便下次遇到查询。
一 将设备重新加入集群
Gluster采用UUID来标识每个gluster实例,这个信息存储在/var/lib/glusterd/glusterd.info中,因此只要恢复之前的UUID,好么Gluster集群就认为其和原来是同一设备。当然最好主机名和IP与原来一样,当然不一样也完全没有关系。
在一台服务器上如gfserver20上查看gfserver26的历史UUID:grep gfserver26 /var/lib/glusterd/peers/*,记录下UUID的历史值。
在gfserver26上,修改/var/lib/glusterd/glusterd.info的UUID为其历史值。重启glusterd进程。
执行gluster peer probe gfserver20。重启后,正常情况就能同步到集群的peer信息。但我在执行中遇到了无法peer信息,在其他服务器上查看peer status时显示gfserver26状态为rejected。其解决方法是删除/var/lib/glusterd/目录下除glusterd.info文件的其他文件,然后重启gluster再peer probe。重启后就可以解决这个问题了。
通常加入集群后,自动就可以获得卷信息,如果没有获取到,可以执行gluster volume sync gfserver20 all来强制获取。
二 将新的brick加入集群
同理,每个卷也有一个UUID,因此只需要修改brick的属性,将卷的UUID为原来值,那么brick就认为自己属于集群和原来的brick是同一个。下面的脚本替换相应的卷名和brick后执行即可恢复brick的卷UUID
vol=msdat-vol
brick=/media1/media
setfattr -n trusted.glusterfs.volume-id -v 0x$(grep volume-id /var/lib/glusterd/vols/$vol/info | cut -d= -f2 | sed 's/-//g') $brick
三 同步数据
通常情况下,卷信息恢复后,复本卷会自动做修复操作。当然也可以强制开始。
gluster volume heal msdat-vol full
参考文档
http://www.gluster.org/community/documentation/index.php/Resolving_Peer_Rejected