我刚刚检查了我的 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
答案1
什么是裂脑？
正如在关于管理裂脑的官方文档由 RedHat 提供，裂脑是指由于维护两个范围重叠的独立数据集而导致数据或可用性不一致的状态，这种不一致可能是由于网络设计中的服务器造成的，也可能是由于服务器之间无法通信和同步数据的故障情况造成的。这是一个适用于复制配置的术语。
注意说“服务器之间无法通信和同步数据而导致的故障情况”- 无论如何 - 但这并不意味着您的节点可能会丢失连接。Peer 可能仍在集群中并已连接。
裂脑类型：
我们有三种不同类型的裂脑，据我所知，你的是入门级裂脑。解释一下三种类型的裂脑：
数据裂脑：脑裂文件的内容在不同的副本对中有所不同，无法自动修复。
元数据裂脑：, 文件的元数据（例如，用户定义的扩展属性）不同，无法自动修复。
进入裂脑：当文件在每个副本对上都有不同的 gfid 时，就会发生这种情况。
什么是GFID？
GlusterFS 内部文件标识符 (GFID)是整个集群中每个文件唯一的 uuid。这类似于普通文件系统中的 inode 编号。文件的 GFID 存储在名为 的 xattr 中trusted.gfid。要从 GFID 查找路径，我强烈建议您阅读这篇官方文章由 GlusterFS 提供。
如何解决入口裂脑？
有多种方法可以防止发生裂脑，但要解决它，必须删除相应的 gfid-link 文件。gfid-link 文件位于 brick 顶层目录中的 .glusterfs 目录中。顺便说一句，请注意，在删除 gfid-link 之前，您必须确保该 brick 上不存在指向文件的硬链接。如果存在硬链接，您也必须删除它们。然后，您可以通过运行以下命令来使用自我修复过程。
同时，要查看卷上处于裂脑状态的文件列表，您可以使用：
# gluster volume heal VOLNAME info split-brain
您还应该注意，对于复制的卷，当一个块离线并重新在线时，需要自我修复来重新同步所有副本。
要检查卷和文件的修复状态，您可以使用：
# gluster volume heal VOLNAME info
由于您使用的是 3.5 版，因此没有自动修复功能。因此，在完成前面提到的步骤后，您需要触发自我修复。具体操作如下：
仅针对需要修复的文件：
# gluster volume heal VOLNAME在所有文件上：
# gluster volume heal VOLNAME full
我希望这能帮助您解决问题。请阅读官方文档以获取更多信息。干杯。
答案2
当集群中的两个节点断开连接时，就会发生脑裂。每个节点都认为另一个节点没有工作。
要解决这个问题，你必须了解为什么你的两个节点不再互相通信。
答案3
我认为文档很清楚，它甚至给了你一个类似的例子。
对于 Gluesterfs 的修复命令，例如
gluster 卷修复 **VOLNAME** 裂脑最新修改时间 **FILE**
FILE 可以是从卷根目录看到的完整文件名（或）文件的 gfid 字符串表示
所以你不必担心这个。
并作为将 GFID 转换为路径说：
GlusterFS 内部文件标识符 (GFID) 是整个集群中每个文件唯一的 uuid。
这脚本可能会告诉您哪个文件名属于哪个 gfid，但是发生了大脑分裂，它可能没有文件名。
您正在运行 3.5 并且没有半自动修复命令，因此您可能需要手动修复冲突，这通常意味着决定需要删除哪个 gfid 文件。
答案4
我如何解决它？
裂脑解决方案可以这里。如果这没有太大帮助，手动操作方法这里应该可以完成这项工作。对于这种情况，我明白文章也有帮助。
如何避免裂脑。
通过仲裁投票算法可以防止网络分区。如果主机发生故障，或者出现裂脑情况（节点继续运行但无法再相互通信），集群中剩余的一个或多个节点将争相在见证驱动器上放置 SCSI 预留。在出现裂脑的情况下，见证将帮助决定哪个持有数据副本的主机应该接管控制权。
一些例子。
VMware VSAN 允许运行双节点集群，并在第三台主机或云中运行见证驱动器。来源
StarWind Virtual SAN 使用 Microsoft 故障转移群集服务仅在 2 节点设置中运行，还包含仲裁投票机制以避免裂脑问题。来源
对于两者，Heartbeat 网络用于服务/监控节点和仲裁之间的通信。为了避免裂脑，我认为必须使用冗余 Heartbeat 通道。