我无法找到一个很好的文档/解释，关于severity在nodetool gossipinfo中表示什么。正在寻找一个详细的解释，但找不到合适的。
severity
nodetool gossipinfo
0ejtzxu11#
严重性是添加到动态告密者中的等待时间的值，以确定协调器将向哪个副本发送读取的DATA和DIGEST请求。它的值将取决于压缩中使用的IO，并且它将尝试读取/proc/stat（与iostat实用程序相同）以获取实际的磁盘统计信息作为其权重。在cassandra的3.10后版本中，https://issues.apache.org/jira/browse/CASSANDRA-11738中删除了此功能。在以前的版本中，你可以通过在jvm选项中设置-Dcassandra.ignore_dynamic_snitch_severity来禁用它。问题是，它对io的加权与延迟相同。因此，如果一个节点正在GC抖动，并且因此没有执行太多IO，那么它最终可能被视为大多数读取的目标，即使它是发送请求的最糟糕的节点。现在，如果您希望将其排除在读取操作之外，您仍然可以使用JMX将该值设置为still（设置为100）。示例用例是使用nodetool disablebinary，因此应用程序不会直接查询它，然后将严重性设置为100。只有当存在CL.ALL请求或读取修复时，群集才会查询该节点。这是一种从读取Angular 将节点“离线”进行维护的方法，但仍然允许它获得变化，因此它不会落后。
/proc/stat
-Dcassandra.ignore_dynamic_snitch_severity
nodetool disablebinary
ldfqzlk82#
严重性报告特定节点上发生的活动（压缩等），然后使用此信息来决定哪个节点可以更好地处理请求。original JIRA中有关于此功能的讨论以及如何使用此信息。P.S.请看Chris关于3.10版本后的变化的回答-我不知道这些变化...
2条答案
按热度按时间0ejtzxu11#
严重性是添加到动态告密者中的等待时间的值，以确定协调器将向哪个副本发送读取的DATA和DIGEST请求。
它的值将取决于压缩中使用的IO，并且它将尝试读取
/proc/stat（与iostat实用程序相同）以获取实际的磁盘统计信息作为其权重。在cassandra的3.10后版本中，https://issues.apache.org/jira/browse/CASSANDRA-11738中删除了此功能。在以前的版本中，你可以通过在jvm选项中设置-Dcassandra.ignore_dynamic_snitch_severity来禁用它。问题是，它对io的加权与延迟相同。因此，如果一个节点正在GC抖动，并且因此没有执行太多IO，那么它最终可能被视为大多数读取的目标，即使它是发送请求的最糟糕的节点。现在，如果您希望将其排除在读取操作之外，您仍然可以使用JMX将该值设置为still（设置为100）。示例用例是使用
nodetool disablebinary，因此应用程序不会直接查询它，然后将严重性设置为100。只有当存在CL.ALL请求或读取修复时，群集才会查询该节点。这是一种从读取Angular 将节点“离线”进行维护的方法，但仍然允许它获得变化，因此它不会落后。ldfqzlk82#
严重性报告特定节点上发生的活动（压缩等），然后使用此信息来决定哪个节点可以更好地处理请求。original JIRA中有关于此功能的讨论以及如何使用此信息。
P.S.请看Chris关于3.10版本后的变化的回答-我不知道这些变化...