You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Matt Byrd (JIRA)" <ji...@apache.org> on 2018/06/19 23:45:00 UTC
[jira] [Assigned] (CASSANDRA-14531) Only include data owned by the
node in totals for repaired, un-repaired and pending repair.
[ https://issues.apache.org/jira/browse/CASSANDRA-14531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Byrd reassigned CASSANDRA-14531:
-------------------------------------
Assignee: Matt Byrd
> Only include data owned by the node in totals for repaired, un-repaired and pending repair.
> -------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14531
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14531
> Project: Cassandra
> Issue Type: Improvement
> Components: Metrics, Repair
> Reporter: Matt Byrd
> Assignee: Matt Byrd
> Priority: Minor
> Fix For: 4.x
>
>
> If there is data which is left over from a topology change and is not yet cleaned up, it will be included in the total for BytesRepaired, BytesUnrepaired or BytesPendingRepair metrics.
> This can distort the total and lead to misleading metrics (albeit potentially short-lived).
> As an operator if you wanted to keep track of percent repaired, you might not have an accurate idea of the relevant percent repaired under such conditions.
> I propose we only include sstables owned by the node in the totals for BytesRepaired, BytesUnrepaired, BytesPendingRepair and PercentRepaired. It feels more logical to only emit metrics like repaired/un-repaired for data which can actually be repaired.
> When an SStable is partially owned by the node, we can compute the size which falls within the token-range by binary searching the index for the uncompressed offsets.
> We can finally also emit a metric which consists of all the data which is not owned by the node.
> This might also be helpful for operators to discover whether there is data which is not owned by the node and hence the need to run cleanup.
> On slight complication is that with a large number of sstables and a reasonable number of vnodes, computing these values now becomes a bit expensive. There is probably a way of keeping some of these metrics updated online rather than re-computing periodically, though this might be a bit fiddly. Alternately using things like the interval tree or some other data-structure might be enough to ensure it performs sufficiently and doesn't add undue overhead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org