脑裂的处理，可以分为手动和自动处理两种。对于数据和元数据的脑裂，两种方式都可以处理，目录的脑裂比较复杂可能需要我们手动修理。
查看哪些文件处于脑裂 # 查看集群中是否有脑裂的文件gluster volume heal <volume> info summary # 列出处于脑裂状态的文件或者目录gluster volume heal <volume> info split-brain
结果即会有GFID、也会有文件名，也会有目录名。没错！目录也是有可能脑裂的。
如果结果有目录出现（也可能是GFID的形式），并且还有这个目录下文件或者子目录出现，说明这个目录下可能是有文件存在GFID不一样，或者文件类型（一边是目录，一边是文件）不一样。
优先处理文件脑裂和单个的目录（info split-brain结果中只显示了这个目录，没有显示子目录或者目录下的文件）, 使用下面命令可以得到文件脑裂类型，然后根据相应的手段处理脑裂
getfattr -n replica.split-brain-status <挂载点下的文件名>这个命令可以确定是不是data(数据)或者metadata(元数据)的脑裂
上图表示文件没有处于这两种脑裂。如果是下面的这种输出，表示文件是处于元数据脑裂状态。当然一个文件可能拥有这两种脑裂状态。
通过这个命令的输出，比较多个brick下，相同文件的stat输出，我们也可以判断出是不是元数据和数据脑裂。
根据上面方式没有判断出来，继续往下看。
getfattr -d -e hex -m. <brick下的文件路径>
通过对比多个brick下的同一个文件的GFID是否一样，可以得到是不是gfid脑裂
处理完上述情况后，处理包含子目录或者目录下文件的情况
# 使用下面的命令，得到需要治愈的文件，得到的结果有的是脑裂，有的不是脑裂，需要按照上面的方式分析# 多加一个检查，就是文件是不是在一些brick下是文件，在另外一些brick下是目录，如果出现这种情况那就是 Type-mismatch脑裂gluster volume heal <volume> info 手动-CLI 解决data和metadata 脑裂CLI的方式不能解决文件类型不一样的脑裂。废话少说，直接上命令了：
# 选择最大的那个文件作为源文件，去修复其他的文件gluster volume heal <volume> split-brain bigger-file <filepath>filepath是有讲究的，比如说 我们挂载点是 /ABC ，info split-brain中显示了 /ABC/test/file001, 那么此处的filepath就是 /test/file001
# 选择修改时间mtime最新的文件作为源文件，去修复其他文件gluster volume heal <VOLNAME> split-brain latest-mtime <filepath> #下面的例子是，选择使用某个brick上的数据作为权威数据，去修复其他的文件gluster volume heal test split-brain source-brick test-host:/test/b1 gfid:c3c94de2-232d-4083-b534-5da17fc476ac此时 filepath 可以直接用 "gfid:"的形式
# 当要修复的文件比较多的时候，粗暴的指定一个权威数据源，来修复数据gluster volume heal <VOLNAME> split-brain source-brick <HOSTNAME:BRICKNAME> 手动-CLI 解决gfid脑裂修理gfid的脑裂, 不能使用 gfid:<GFID>形式的路径
# 使用最大的文件作为源，修复脑裂文件gluster volume heal VOLNAME split-brain bigger-file <filepath> # 使用修改时间最新的文件作为源，修复脑裂文件 gluster volume heal VOLNAME split-brain latest-mtime <filepath> # 选择一个brick作为权威源，修复脑裂文件gluster volume heal VOLNAME split-brain source-brick HOSTNAME:export-directory-absolute-path <filepath> 解决GFID脑裂，不能不指定filepath, 需要挨个文件执行如果一个目录处于GFID脑裂状态，并且你的集群是分布式副本卷，那么修复命令需要在每个sub-volumes 上执行。
Type-mismatch脑裂这种情况使用上面的命令不能修复，所以也别费劲了，执行也会报错。
# gluster volume heal test split-brain source-brick test-host:/test/b1 /entry1Healing /entry1 failed:Operation not permitted.Volume heal failed. 去冲突的brick下，查看目录，确定那个brick下的目录是权威的找到权威brick后， 将与这个权威brick冲突的brick下的，这个目录删除掉，并同时删除gfid-link目录删除后，你会发现这个目录会重新创建比如 冲突目录是：/test, 我们删除 /data/brick/test目录的同时，通过getfattf获取到目录的 GFID ，然后删除gfid-link，就像下面这样
比如 冲突的目录是：0x307a5c9efddd4e7c96e94fd4bcdcbd1b：
cluster.favorite-child-policy，这个配置项可设置的值如下：
- size: 认为最大的文件是权威文件- ctime: 认为ctime最新的文件是权威文件- mtime: 认为mtime最新的文件是权威文件- majority: 查看所有brick上冲突文件的 mtime和size, 取如果有一半以上的文件的mtime和size是一样的，就认为这批文件是权威文件这个选项修复不了type-mismatch类型的脑裂。
目录的脑裂能不能修复，我不确定。