我怎么知道nodetool修复是否完成

use*_*568 19 cassandra nodetool cassandra-2.0

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

ALTER KEYSPACE "mykeyspace" WITH REPLICATION =   { 'class' : 'SimpleStrategy', 'replication_factor' : 2 };
Run Code Online (Sandbox Code Playgroud)

然后我尝试在执行此类alter之后运行推荐的"nodetool repair".

问题是这个命令有时会很快完成.当它完成时,通常会说"丢失通知......"并且退出代码不为零.

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

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

Aar*_*ron 52

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

  • compactionstats
  • netstats

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

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

$ nodetool compactionstats
pending tasks: 0
Active compaction remaining time :        n/a
Run Code Online (Sandbox Code Playgroud)

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

$ nodetool netstats
Run Code Online (Sandbox Code Playgroud)

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

while true; do date; diff <(nodetool -h localhost netstats) <(sleep 5 && nodetool -h localhost netstats); done
Run Code Online (Sandbox Code Playgroud)

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

DEBUG [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...
Run Code Online (Sandbox Code Playgroud)

  • @AlexisWilke Ctrl-C退出修复命令总是安全的.事实上,停止修复的唯一方法是使用`nodetool stop validation`.有很多东西可以导致维修.通过JMX监控待处理修复的数量,如果该数字永远不会达到零,则可能需要退回节点.网络不稳定也可能导致维修. (3认同)
  • 用进程替代`&lt;(...`)和`sleep`来避免写入temp / prev / last文件是很不错的选择。我对这里使用的所有组件都很熟悉,但从未想过以这种方式使用它们。 (2认同)

tje*_*oit 5

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

nodetool repair --trace <key_space> <table>