glusterfs客户端挂载点失败，因为“未满足客户端仲裁”

Question

假设一个基本的副本3仲裁器1配置，glusterfs-服务器4.0.2和glusterfs-客户机4.0.2.客户端安装在Ubuntu18.04上。

为了验证当一个存储节点如文档中所述被关闭时是否允许写/读操作，会发生意外的结果。在终止一个非仲裁节点(使用pkill ^gluster*)上的gluster进程之后，客户端挂载点将在“Client quorum is not met.”(请参阅glusterfs-客户机日志文件.)中失败。

Gluster卷信息：

Volume Name: brick01
Type: Replicate
Volume ID: 2310c6f4-f83d-4691-97a7-cbebc01b3cf7
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: proxmoxVE-1:/mnt/gluster/bricks/brick01
Brick2: proxmoxVE-2:/mnt/gluster/bricks/brick01
Brick3: arbiter01:/mnt/gluster/bricks/brick01 (arbiter)

该卷由以下命令创建

gluster volume create brick01 replica 3 arbiter 1 
proxmoxVE-1:/mnt/gluster/bricks/brick01 
proxmoxVE-2:/mnt/gluster/bricks/brick01 
arbiter01:/mnt/gluster/bricks/brick01

正如文档所指出的，在一个砖块倒塌的情况下，应该允许文件操作(如果仲裁者同意)，那么为什么我在客户端得到“客户仲裁不满足”呢？在花了大量时间阅读有关glusterfs的官方文档之后，我无法解释为什么会发生这种情况，我还在reading上提交了一个错误报告。

在这个话题上的任何帮助都将非常感谢！

Answer 1

gluster volume heal brick01 enablе解决了这个问题。

这最终将重新配置的选项cluster.self-heal-daemon: enable添加到卷中。在默认情况下，仲裁砖似乎无法在任何文件操作发生时同时恢复(同步)，并将错误归咎于仍在运行的另一个砖块。