[
https://issues.apache.org/jira/browse/CASSANDRA-8654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284302#comment-14284302
]
Russ Hatch commented on CASSANDRA-8654:
---------------------------------------
[~enigmacurry] Also had a good idea, which is to forego on-disk logging and use
another cassandra cluster to be the authority on what the DB state should look
like for the cluster under test. This would presumably require a generic schema
that can somehow capture the state of what a cassandra cluster should look like
data-wise..
We could take this one step further by considering an "authority" C* cluster to
be bug-free, and use it to validate clusters of newer versions. Then we don't
need a generic schema on the authority cluster, it can simply be a mirror of
sorts (and this way we don't need to "emulate cassandra" in the test code). By
mirroring operations to two clusters that don't know about each other, we then
read from the authority to verify the cluster under test. This could be a great
way to accomplish this type of testing, but it may present some other
challenges, such as:
- how do we validate the authority cluster to know it won't have data
problems of its own?
- how do we map compatibility between the authority and the cluster under
test to be sure they are similar enough for meaningful results?
- how do we accomplish this blind mirroring, and how do we deal with routine
failures on one cluster?
> Data validation test
> --------------------
>
> Key: CASSANDRA-8654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8654
> Project: Cassandra
> Issue Type: Test
> Reporter: Russ Hatch
> Assignee: Russ Hatch
>
> There was a recent discussion about the utility of data validation testing.
> The goal here would be a harness of some kind that can mix operations and
> track its own notion of what the DB state should look like, and verify it in
> detail, or perhaps a sampling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
