我们当前在 Gluster 3.6.4 上运行三节点集群。
在我们的一个节点上，我们注意到 glusterd 守护进程已停止运行。
但 glusterfsd 守护进程仍在运行，我们相信客户端正在连接并检索数据
我们注意到守护进程已经死了一个星期，我们没有看到它。NFS 分布式挂载继续正常工作
我们想知道我们可以安全地继续并重新启动 glusterd 服务吗？
如果这样，这会触发所有卷的自我修复吗？因为这会导致性能问题。
该节点的日志如下：
[2016-08-19 18:01:52.804453] E [rpc-clnt.c:362:saved_frames_unwind] (--> /usr/lib64/libglusterfs.so.0(_gf_log_callingfn+0x1e0)[0x7f4f3ffca550] (--> /usr/lib64/libgfrpc.so.0(saved_frames_unwind+0x1e7)[0x7f4f3fd9f787] (--> /usr/lib64/libgfrpc.so.0(saved_frames_destroy+0xe)[0x7f4f3fd9f89e] (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_connection_cleanup+0x91)[0x7f4f3fd9f951] (--> /usr/lib64/libgfrpc.so.0(rpc_clnt_notify+0x15f)[0x7f4f3fd9ff1f] ))))) 0-DAOS-client-4: forced unwinding frame type(GF-DUMP) op(DUMP(1)) called at 2016-08-19 18:01:51.886737 (xid=0x144a1d)
[2016-08-19 18:01:52.804480] W [client-handshake.c:1588:client_dump_version_cbk] 0-DAOS-client-4: received RPC status error
[2016-08-19 18:01:52.804504] W [socket.c:620:__socket_rwv] 0-glusterfs: readv on 127.0.0.1:24007 failed (No data available)
[2016-08-19 18:02:02.900863] E [socket.c:2276:socket_connect_finish] 0-glusterfs: connection to 127.0.0.1:24007 failed (Connection refused)
如果这样做不安全，我们还应该做些什么来解决这个问题
（有用信息：此博客文章讨论了 glusterfsd 和 glusterd 之间的区别http://blog.nixpanic.net/2013/12/gluster-and-not-restarting-brick.html）
答案1
是的，如果没有足够数量的节点对此问题进行投票，您的卷将无法自我修复。是的，当您启动 glusterd.service 时，它应该重新启动自我修复过程。但是，它只会修复已标记为需要修复的文件。
由于您没有注意到缺少 glusterd 守护进程，我假设您不会在此集群上修改太多的砖块/卷。但是，glusterfsd 守护进程都在运行，这意味着大多数情况下不需要自我修复。
需要考虑的最大问题是，自我修复不像巡检读取，而更像是选择性清理 - 因为它只对被标记为脏的文件起作用。考虑到这一点，启动 glusterd 守护进程就不是什么大问题了。