[
https://issues.apache.org/jira/browse/CASSANDRA-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287089#comment-16287089
]
Jeff Jirsa commented on CASSANDRA-6758:
---------------------------------------
Think this is done.
In 4.0, we have CASSANDRA-11503 (nodetool repaired/unrepaired by sstables),
CASSANDRA-13774 (repaired/unrepaired by bytes), CASSANDRA-13289 (track an ideal
consistency level beyond what acks the write), and CASSANDRA-13257 (repair
preview). Seems like that covers the intent of this ticket.
Propose we close as wontfix, because it's basically done by those others.
> Measure data consistency in the cluster
> ---------------------------------------
>
> Key: CASSANDRA-6758
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6758
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jimmy Mårdell
> Priority: Minor
> Labels: proposed-wontfix
>
> Running multi-DC Cassandra can be a challenge as the cluster easily tends to
> get out-of-sync. We have been thinking it would be nice to measure how out of
> sync a cluster is and expose those metrics somehow.
> One idea would be to just run the first half of the repair process and output
> the result of the differencer. If you use Random or the Murmur3 partitioner,
> it should be enough to calculate the merkle tree over a small subset of the
> ring as the result can be extrapolated.
> This could be exposed in nodetool. Either a separate command or perhaps a
> dry-run flag to repair?
> Not sure about the output format. I think it would be nice to have one value
> ("% consistent"?) within a DC, and also one value for every pair of DC's
> perhaps?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
