本节包含一些在运行IPFS集群时识别和纠正问题的技巧。
调试日志
默认情况下, ipfs-cluster-service
只有输出 INFO
, WARNING
和 ERROR
消息。有时候,用--loglevel debug
旗帜增加冗长度是很有用的 。这将使ipfs-cluster及其组件更加冗长。 --debug
flag变量将使ipfs-cluster,其组件及其最突出的依赖项(raft,libp2p-raft,libp2p-gorpc)冗长。
ipfs-cluster-ctl
提供一个 --debug
flag变量,用于输出有关工具使用的API端点的信息。 --enc json
允许从API输出json
原始响应。
解释调试信息可能很棘手。例如:
18:21:50.343 ERROR ipfshttp: error getting:Get http://127.0.0.1:5001/api/v0/repo/stat: dial tcp 127.0.0.1:5001: getsockopt: connection refused ipfshttp.go:695
上面的一行显示了来自ipfshttp
设施的严重性错误的消息 。此工具对应于ipfshttp
实现IPFS连接器组件的模块。此信息有助于缩小发生错误的上下文。该错误消息表明该组件未能对ipfs HTTP API执行GET请求。日志条目包含记录错误的文件和行号。
鉴于所有这些上下文,我们可以发现很可能ipfs守护程序没有运行,或者无法访问。
发现问题时,如果您在寻求帮助时可以提供一些日志,则始终有用。
节点没有启动
当您的对等节点没有启动时:
- 检查日志并查找错误
- 所有的监听地址都是免费的还是由不同的进程使用?
- 集群的其他对等节点是否可达?
- 所有同行的
cluster.secret
是否相同? - 仔细检查
peerstore
文件是否具有正确的内容,并且您已按照“ 启动群集”部分中的某个方法进行操作 。 - 仔细检查集群的其余部分是否处于正常状态。
- 在某些情况下,它可能有助于运行
ipfs-cluster-service state clean
(特别是如果不启动的原因是筏状态和jiqun对等体之间不匹配)。假设集群是健康的,这将允许非启动对等节点在引导时从集群领导者中拉出干净状态。
节点意外地停了下来
当对等节点意外停止时:
- 确保您没有从集群中删除对等节点或触发关闭
- 检查日志中是否存在因内部故障导致进程死亡的线索
- 检查系统日志以查找是否有任何外部操作终止了该过程
- 报告任何应用程序恐慌,因为它们不应该与日志一起报告
ipfs-cluster-ctl status <cid>
不报告所有对等节点的CID信息
这通常是共享状态 和本地状态之间或本地状态 和ipfs状态之间的异步的结果。如果问题在几分钟后没有自动更正(由于自动同步),请尝试运行 ipfs-cluster-ctl sync [cid]
有问题的项目。您也可以重新启动节点。
libp2p错误
由于集群是建立在libp2p之上的,因此新用户面临的许多错误都来自libp2p并且具有令人困惑的消息,这些消息乍一看并不明显。此列表汇编了其中一些:
dial attempt failed: misdial to <peer.ID XXXXXX> through ....
:这意味着您正在联系的多地址在其中具有与预期不同的对等节点。dial attempt failed: connection refused
:对等节点未运行或未在预期的地址/协议/端口上侦听。dial attempt failed: context deadline exceeded
:这意味着无法访问该地址或使用了错误的密码。dial backoff
:与上述相同。dial attempt failed: incoming message was too large
:这可能意味着您的集群对等节点没有共享相同的秘密。version not supported
:这意味着您的节点正在运行不同版本的raft / cluster。