我有一个正在运行的六节点 glusterfs 集群。今天早上，我注意到其中一台机器表现得很奇怪，所以为了安全起见，我重新启动了它——手动 STONITH，如果你愿意的话。
重新启动后，其他三个节点在gluster pool list和中将重新启动的计算机识别为“已连接” gluster peer status，但另外两个节点显示“已断开”状态。奇怪的是，即使在 中显示“断开连接”的节点gluster pool list仍然显示为“已连接” gluster volume heal [volname] info。
我gluster peer probe从两边都试过了，没有效果。我已经验证，我可以从认为其“已断开连接”的计算机连接到重新启动的节点上的端口 24007 和端口 49154（gluster volume status在将其识别为“已连接”的对等体上显示的砖端口）。
/var/log/glusterfs/glustershd.log在将重新启动的服务器视为已断开连接的节点上包含：
[2018-01-09 11:36:39.258109] I [MSGID: 114018] [client.c:2280:client_rpc_notify] 0-palantir-client-4: disconnected from palantir-client-4. Client process will keep trying to connect to glusterd until brick's port is available
[2018-01-09 11:36:50.074074] E [socket.c:2309:socket_connect_finish] 0-palantir-client-4: connection to xxx.xxx.xxx.205:24007 failed (No route to host)
然而，一个半小时后，它还没有重新连接，尽管第一个日志条目声称它会继续尝试。
鉴于这一切，我需要做什么才能让两个错误的对等点重新连接到重新启动的节点？
经过大量的网络（和灵魂）搜索后，我抓住机会停止并重新启动systemctl restart glusterfs-server两个节点上的 glusterfs 服务器服务（），这两个节点将重新启动的对等节点视为已断开连接，这使事情恢复同步。
最重要的是，执行这些重新启动不会导致数据丢失，即使重新启动的节点之一是它视为已断开连接的对等节点的副本。据推测，复制仍在通过仍将重新启动的对等方视为已连接的节点进行。