GlusterFS脑裂需手动识别并修复：先用heal info split-brain判断类型，再结合getfattr、stat和changelog交叉验证定位最新健康副本，最后用split-brain bigger-file或source-brick命令修复，GFID一致是关键前提。

能手动解决，但必须先确认哪个副本是“最新健康”的——GlusterFS 不提供自动比对时间戳或内容哈希的命令，全靠你结合 getfattr、stat 和业务上下文判断。

怎么识别当前是哪种脑裂类型

直接运行 gluster volume heal <volume> info split-brain，输出里出现的路径是挂载点下的相对路径（比如 /data/file.txt），不是 brick 上的绝对路径。重点看三类信号：

• 如果某行只显示一个 GFID（十六进制字符串），没文件名，说明是 GFID 级别不一致，大概率是目录类型错配（一边是 dir，一边是 file）
• 如果显示 file: xxx Choices:test-client-0,test-client-1，说明 AFR 已识别冲突，但没法定夺该用谁
• 如果 getfattr -n replica.split-brain-status <mount-path> 返回 data-split-brain:yes，表示数据内容不一致；metadata-split-brain:yes 表示权限/时间戳等元数据不一致

怎么定位“最新健康副本”在哪块 brick 上

不能只看 mtime —— GlusterFS 的写事务可能让某个 brick 写成功但 post-op 阶段失败，导致扩展属性残留，stat 时间不准。必须交叉验证：

• 在每个 brick 对应的物理路径下（比如 /bricks/vol1/brick1/data/file.txt），运行 stat -c "%y %s" <file> 看修改时间和大小
• 用 getfattr -d -e hex -m trusted.afr.<volname>-client-<idx> <brick-file> 查看每个副本的 changelog 扩展属性值，重点关注最后 8 字节（entry 变化）和中间 8 字节（metadata 变化）是否为 0x00000000；非零说明该 brick 上此 FOP 未完成
• 如果某 brick 上 trusted.afr.dirty 值为 0x00000000 00000000 00000000，且 stat 时间最新、大小匹配预期，那它大概率是完整副本

怎么强制用指定 brick 的副本覆盖其他副本

确认源 brick 后，必须在挂载点路径下操作，不是 brick 路径。假设挂载点是 /mnt/gluster，脑裂文件显示为 /mnt/gluster/app/config.json，而你确定 brick1 上的版本最可靠：

• 执行 gluster volume heal <volume> split-brain bigger-file app/config.json —— 这条命令会选所有副本中 size 最大的那个作为源，**不看内容或时间戳**
• 如果大小一样，就得用 split-brain source-brick：先查出 brick 编号（gluster volume info <volume> 输出里的 Brick1: host:/path 对应 client-0），再运行 gluster volume heal <volume> split-brain source-brick client-0 app/config.json
• 注意：source-brick 模式要求目标文件在该 brick 上存在且非空，否则报错 Invalid argument
• 执行后立刻用 gluster volume heal <volume> info split-brain 检查是否消失；若还在，说明有 GFID 或类型错配，得进 brick 手动删+同步

brick 层面手动同步的底线操作

当 CLI 命令失败，或 info 输出里出现目录级 GFID 冲突（比如 /app/logs 和它下面的 /app/logs/error.log 同时列出来），就必须登录 brick 服务器操作：

• 停掉该卷： gluster volume stop <volume>（避免 heal 进程干扰）
• 在“源 brick”上打包：tar -cf /tmp/fix-logs.tar -C /bricks/vol1/brick1 app/logs
• 在其他 brick 上清空并解压：rm -rf /bricks/vol1/brick2/app/logs && tar -xf /tmp/fix-logs.tar -C /bricks/vol1/brick2/
• 恢复前务必校验 GFID：用 getfattr -n trusted.gfid <file> 确认所有 brick 上同名文件 GFID 一致，否则挂载点仍不可见
• 重启卷：gluster volume start <volume>，再触发一次 gluster volume heal <volume>

GFID 不一致是最容易被忽略的环节——哪怕文件内容、权限、时间戳全对上了，只要 GFID 不同，GlusterFS 就认为是两个独立文件，heal 命令不会合并，挂载点也可能只显示其中一个。