我有一个2节点的apache cassandra (2.0.3)集群,rep factor为1。
ALTER KEYSPACE "mykeyspace" WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 2 };然后,我尝试在执行这种类型的alter之后运行推荐的"nodetool修复“。
问题是这个命令有时完成得非常快。当它像这样结束时,它通常会显示“丢失通知...”。并且退出代码不是零。
所以我只是重复这个“nodetool修复”,直到它没有错误地完成。我还检查了“nodetool status”是否报告了每个节点的预期磁盘空间。(使用rep factor 1,每个节点的容量约为7 7GB,我预计在nodetool修复后,假设在平均时间内没有集群使用,每个节点的容量为14 7GB)
在这种情况下,是否有更正确的方法来确定“nodetool修复”是否已完成?
发布于 2014-08-01 21:23:28
一般来说,您可以使用两个nodetool命令来监控nodetool repair操作:
修复操作有两个截然不同的阶段。首先,它计算节点之间的差异(要完成的修复工作),然后通过将数据流式传输到适当的节点来对这些差异采取行动。
这将检查活动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); doneDataStax在他们的支持论坛上发布了一篇关于troubleshooting hanging repairs的帖子。如果您有任何挂起的修复流,您应该能够通过netstats看到它们。如果其中一个节点在修复过程中变得不可用,就会发生这种情况。要监视特定的修复操作,您可以检查日志文件中类似以下内容的条目:
调试写入- /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...发布于 2017-06-09 13:06:05
启动修复命令时,可以使用选项--trace监视修复流:
nodetool repair --trace <key_space> <table>
发布于 2019-01-25 17:09:01
我们还可以在Opscenter console的Activities下监控修复进度。
https://stackoverflow.com/questions/25064717
复制相似问题