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</volume>，输出里出现的路径是挂载点下的相对路径（比如 /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></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></file>看修改时间和大小 - 用
getfattr -d -e hex -m trusted.afr.<volname>-client-<idx><brick-file></brick-file></idx></volname>查看每个副本的 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</volume>—— 这条命令会选所有副本中 size 最大的那个作为源，**不看内容或时间戳** - 如果大小一样，就得用
split-brain source-brick：先查出 brick 编号（gluster volume info <volume></volume>输出里的Brick1: host:/path对应client-0），再运行gluster volume heal <volume> split-brain source-brick client-0 app/config.json</volume> - 注意：
source-brick模式要求目标文件在该 brick 上存在且非空，否则报错Invalid argument - 执行后立刻用
gluster volume heal <volume> info split-brain</volume>检查是否消失；若还在，说明有 GFID 或类型错配，得进 brick 手动删+同步
brick 层面手动同步的底线操作
当 CLI 命令失败，或 info 输出里出现目录级 GFID 冲突（比如 /app/logs 和它下面的 /app/logs/error.log 同时列出来），就必须登录 brick 服务器操作：
- 停掉该卷：
gluster volume stop <volume></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></file>确认所有 brick 上同名文件 GFID 一致，否则挂载点仍不可见 - 重启卷：
gluster volume start <volume></volume>，再触发一次gluster volume heal <volume></volume>
GFID 不一致是最容易被忽略的环节——哪怕文件内容、权限、时间戳全对上了，只要 GFID 不同，GlusterFS 就认为是两个独立文件，heal 命令不会合并，挂载点也可能只显示其中一个。
