GlusterFS分裂大脑无路可走，这是什么意思？

我只是在检查我的glusterfs卷的状态，有一个带有无路径的裂脑条目的卷：

# gluster volume heal private_uploads info
Brick server01:/var/lib/glusterfs/brick01/uploads/
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
Number of entries: 2

Brick server02:/var/lib/glusterfs/brick01/uploads/
<gfid:42d62418-1be9-4f96-96c4-268230316869> - Is in split-brain
<gfid:4c0edafb-0c28-427c-a162-e530280b3396> - Is in split-brain
Number of entries: 2

这是什么意思？我如何解决它？

我正在运行GlusterFS 3.5.9：

# gluster --version
glusterfs 3.5.9 built on Mar 28 2016 07:10:17
Repository revision: git://git.gluster.com/glusterfs.git

什么是裂脑？

如RedHat提供的“ 管理裂脑的官方文档”中所述，裂脑是一种状态，即由于维护范围相互重叠的两个单独数据集而导致的数据或可用性不一致，可能是由于网络设计中的服务器，或基于服务器未相互通信和同步数据的故障情况。这是适用于复制配置的术语。

请注意，这是“由于服务器之间无法相互通信和同步数据而导致的故障状态”（由于任何可能性），但这并不意味着您的节点可能会丢失连接。对等端可能仍处于群集中并且已连接。

裂脑类型：

我们有三种不同类型的裂脑，据我所知，您是入门裂脑。解释三种类型的裂脑：

• 数据裂脑：在不同的副本对中，裂脑下的文件内容是不同的，并且无法自动修复。

• 元数据裂脑：，文件的元数据（例如，用户定义的扩展属性）不同，因此无法自动修复。

• 条目裂脑：当文件在每个副本对上具有不同的gfid时，就会发生这种情况。

什么是GFID？

GlusterFS内部文件标识符（GFID）是一个uuid，对于整个集群中的每个文件都是唯一的。这类似于普通文件系统中的索引节点号。文件的GFID存储在名为的xattr中trusted.gfid。要找到GFID的路径，我强烈建议您阅读GlusterFS提供的这篇官方文章。

如何解决输入裂脑？

有多种方法可以防止裂脑，但要解决此问题，必须删除相应的gfid-link文件。gfid-link文件位于砖块顶级目录的.glusterfs目录中。顺便提一下，请注意，在删除gfid-links之前，您必须确保不存在指向该Brick上文件的硬链接。如果存在硬链接，则必须将其删除。然后，您可以通过运行以下命令来使用自我修复过程。

同时，要查看处于裂脑状态的卷上的文件列表，可以使用：

# gluster volume heal VOLNAME info split-brain

您还应该注意，对于复制的卷，当程序块脱机并重新联机时，需要进行自我修复才能重新同步所有副本。

要检查卷和文件的修复状态，可以使用：

# gluster volume heal VOLNAME info

由于您使用的是3.5版，因此没有自动修复功能。因此，在执行了前面提到的步骤之后，您需要触发自我修复。为此：

• 仅在需要修复的文件上：

  # gluster volume heal VOLNAME

• 在所有文件上：

  # gluster volume heal VOLNAME full

我希望这会帮助您解决问题。请阅读官方文档以获取更多信息。干杯。

我认为文档非常清晰，它甚至给了您一个类似的例子。

对于Gluesterfs的修复命令，例如

gluster卷恢复** VOLNAME **裂脑最新-mtime ** FILE **

FILE可以是从卷的根部看到的完整文件名（或文件的gfid-string表示形式）

因此，您无需为此担心。

而作为转换GFID到路说：

GlusterFS内部文件标识符（GFID）是一个uuid，对于整个集群中的每个文件都是唯一的。

该脚本可能会告诉您哪个文件名属于哪个gfid，但是发生了脑裂，它可能没有文件名。

您正在运行3.5，并且没有半自动修复cmd，因此您可能需要手动修复冲突，这通常意味着需要确定要删除的gfid文件。

我如何解决它？

可以在这里找到裂脑分辨率。万一没有太大帮助，这里的手动方法应该起作用。对于这种情况，我认为这篇文章也很有帮助。

如何避免脑裂。

针对网络分区的保护是通过法定投票算法完成的。如果主机发生故障，或者出现裂脑情况，其中节点继续运行，但无法再相互通信，则群集中的其余一个或多个节点会争用将SCSI保留位置放置在见证驱动器上。如果是裂脑，见证人将帮助确定哪些持有数据副本的主机应接管控制权。

一些例子。

VMware VSAN允许运行见证节点驱动器的2节点群集，该见证驱动器运行在3rd主机或云中。资源

StarWind Virtual SAN仅使用Microsoft故障转移群集服务在2节点设置中运行，该服务还包含仲裁投票机制，可避免出现裂脑问题。资源

对于这两者，心跳网络都用于服务/监视节点与仲裁之间的通信。为了避免出现脑裂，我认为必须使用冗余的心跳线通道。

群集的两个节点断开连接时会发生裂脑。每个节点都认为另一个节点不起作用。

要解决此问题，您必须了解为什么两个节点不再互相通信。