25

我有一个 2 节点 apache cassandra (2.0.3) 集群,rep 因子为 1。我在 cqlsh 中使用以下命令将 rep 因子更改为 2

ALTER KEYSPACE "mykeyspace" WITH REPLICATION =   { 'class' : 'SimpleStrategy', 'replication_factor' : 2 };

然后我尝试在进行此类更改后运行推荐的“nodetool repair”。

问题是这个命令有时会很快完成。当它确实像那样完成时,它通常会说“丢失通知......”并且退出代码不为零。

所以我只是重复这个'nodetool repair',直到它没有错误地完成。我还检查了“nodetool status”是否报告了每个节点的预期磁盘空间。(使用代表因子 1,每个节点都说每个节点大约 7GB,我希望在 nodetool 修复之后每个节点都是 14GB,假设同时没有集群使用)

在这种情况下,是否有更正确的方法来确定“nodetool repair”是否完成?

4

3 回答 3

61

一般来说,您可以nodetool repair使用两个 nodetool 命令监控一个操作:

  • 压实统计
  • 网络统计

修复操作有两个不同的阶段。首先它计算节点之间的差异(要完成的修复工作),然后通过将数据流式传输到适当的节点来处理这些差异。

这将检查活动的 Merkle 树计算:

$ nodetool compactionstats
pending tasks: 0
Active compaction remaining time :        n/a

可以通过以下方式监控修复流:

$ nodetool netstats

事实上,TheLastPickle的 Aaron Morton 建议使用以下 Bash 脚本/命令来监控任何活动的修复流:

while true; do date; diff <(nodetool -h localhost netstats) <(sleep 5 && nodetool -h localhost netstats); done

DataStax 在他们的支持论坛上发布了有关解决悬挂维修问题的帖子。如果您有任何挂起的修复流,您应该能够以netstats. 如果您的一个节点在修复过程中变得不可用,则可能会发生这种情况。要监视特定的修复操作,您可以检查日志文件中的条目,如下所示:

调试 [WRITE-/172.30.77.197] 2013-05-03 12:43:09,107 OutboundTcpConnection.java(第 165 行)错误写入 /172.30.77.197 java.net.SocketException:连接重置

请注意,修复会话也应在您的 system.log 中表示:

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Starting...

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Completed...
于 2014-08-01T13:23:28.480 回答
6

启动修复命令时,可以使用选项 --trace 监视修复流:

nodetool repair --trace <key_space> <table>

于 2017-06-09T05:06:04.657 回答
0

我们还可以在 Opscenter 控制台的“活动”下监控修复进度。

于 2019-01-25T09:09:01.080 回答