问题标签 [nodetool]

过去几天我一直在监控 gcstats，不敢相信它返回的值是正确的。

nodetool gcstats [GC Reclaimed (MB)] 在最近 5 次运行中显示以下值，当时没有针对数据库运行

30356680056

663531768

4222674760

567091224

2147418944

总密钥空间大小小于 1 GB。

我有一个 4 节点 Cassandra 集群，在管理员之间大约 8 个月没有看到 repair() 。它没有看到太多的删除方式。我注意到，当我运行 nodetool repair 时，系统不会接受新数据，并且在修复完成之前没有人可以连接 cqlsh。维修导致停机是否正常？

First time Cassandra user and obligatory issue. Cassandra is running in a 2 node cluster with replication factor=2 and row update fails when 1 node is down.

Keyspace is defined as below.

When the service on node 1 is stopped manually. Row updates stop working. See below

Updating the row when node 1 is down

Column should be updated but behold

If nodetool repair is run on the 'up' node. The updates start to work as usual. It seems like the node is failing to register that the other node is down.

我正在使用 cassandra2.2.1并注意到提交日志文件没有被删除后nodetool flush （实际上，可能有些是，我没有看到，但提交日志目录不为空）。

1. 在定期冲洗期间nodetool flush或只是定期冲洗期间发生了什么？在此过程中是否应该删除所有提交日志文件？

2. 来自commitlog的数据是仅在节点修复期间使用还是在刷新期间使用？

我在 Mac Pro 上使用 Eclipse 对 datastax java 驱动程序进行了一些测试。基本上，在eclipse中，我使用prepared和batch statement来编写（id，name），其中id的范围从10000到1000000，名称是student1-student10000（根据id的范围）。每次在eclipse中运行代码后，一切顺利，然后我使用nodetool cfhistograms和proxyhistograms，以及cfstats查看结果。然而，这似乎很奇怪。当我期待看到读取延迟和写入延迟增加时，当我添加从 10000、100000、1000000、10000000 的范围时，最终结果证明延迟减少了。

例如，对于 10,000 个第一个表和 100,000 个第二个表的 cfhistogram： Percentile SSTables Write Latency 50% 0 14 75% 0 20 95% 0 42 98% 0 60 99% 0 60 Min 0 5 Max 0 179

和 100,000 以下 百分比 SSTables 写入延迟 50% 0 10 75% 0 12 95% 0 24 98% 0 29 99% 0 42 Min 0 3 Max 0 1109

此外，对于代理直方图，10, 000： 百分位读取延迟写入延迟 50% 1331 72 75% 1916 103 95% 5722 215 98% 5722 310 99% 5722 372 最小值 259 30 最大值 5722 11864

和 100,000 以下： 百分比读取延迟 写入延迟 50% 1331 42 75% 1916 50 95% 6866 103 98% 6866 149 99% 6866 215 最小 311 18 最大 6866 61214

有人对此有任何想法吗？

提前致谢！

史蒂文

目前在 Windows 7 中使用 Cassandra 2.1.9。
我正在尝试在 Cygwin 中使用 nodetool 但收到以下消息：

我试图为这个目录创建别名，但仍然没有运气。

有什么建议么？
谢谢

在设置了一个 3 节点 cassandra 集群（cassandra 版本 - 2.1.9）后，我运行了“nodetool status”命令。我意识到有效所有权百分比总计为 200%。

有谁知道为什么我们会获得 200% 的所有权？是因为某些复制因素吗？如果是这样，我怎么知道呢？

谢谢！

当我运行“nodetool cfhistograms”时，我看到了一个表格数据。

有人可以解释一下这些是如何计算的吗？我了解 %le 概念，但我想知道计算上述结果时考虑了多少读/写。

我有 Cassandra Datastax 2.2.3 集群（只有一个节点），作为测试，我正在添加一个新节点。成功添加新节点并使用 启动它后bootstrap=false，我尝试使用 重新平衡它nodetool repair。

但是，旧节点的日志中会弹出此错误：

和这个：

修复失败：

我试过跑步nodetool repair -seq- 结果是一样的。

问题？

• nodetool修复需要多少内存？如何检查？
• 我现在如何重新平衡戒指？有没有办法一步步触发修复？
• 如果没有，我可以添加“虚拟”RAM（可能作为交换），增加堆并触发修复吗？

我有一个运行 2.0.9 版的 cassandra 集群。Nodetool 从一开始就没有运行过（因为它没有被要求安排这些修复）。每个节点都有大约 8GB 的​​数据。这对我来说似乎相当小。当我尝试运行 nodetool repair 时，它似乎需要很长时间（2 天后未完成）。

我没有看到任何进展。我一直在阅读线程，他们告诉您检查 compactionstats 和 netstats 但那些表明没有流量。但是 nodetool repair 命令永远不会退出。这对我来说似乎不正常。我收到有关系统密钥空间正在修复并且正常的消息。但是，我们放入其中的实际数据不会返回任何内容。所有节点都已启动。我在 system.log (CentOS 6 BTW) 中检查了错误，但没有任何错误。我已经启动了一个命令来检查命令和响应的数量是否仍在增加（就是这种情况），但是我想知道这是否可能来自其他原因，或者这是否与 nodetool 修复直接相关。似乎没有任何 IO/net 饱和。所以昨天我又开始用工具 range-repair.py 进行修复。过去 12 小时没有额外的输出。最后的输出是：

这种修复需要永远（或只是修复被挂起）的主要问题是我们想要升级 cassandra 以进行应用程序部署。该程序说首先进行nodetool修复。在开始升级之前这真的有必要吗？也许 nodetool 工作效率更高（您现在还有一个增量选项）。

谁能在这里帮助我？提前非常感谢！