[
https://issues.apache.org/jira/browse/CASSANDRA-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847367#comment-13847367
]
Sylvain Lebresne commented on CASSANDRA-5839:
---------------------------------------------
Haven't looked at the whole patch, but on the schema, I'd keep the grouping of
the keyspace and cf names into the partition key (like in Jonathan's initial
comment). It's common to have just one keyspace (or at least very few) and
there's no point in putting all the burden of the repair data on just one node.
bq. users can use their force to construct their desired view
I just pictured a green Yuki with pointy hears answering a user question by
"use the force Luke". That was funny :). Joking asides, I agree there is no
need to overthink it initially. That being said, I don't see a particular
reason not to let users create 2ndary indexes on those tables if they care for
it, and in fact, is there a reason this doesn't work out of the box? (if there
is, let's worry about it later).
bq. I don't think a hardcode factor based on gc_grace is the way to go
It certainly shouldn't be hardcoded. We have a per-table default_time_to_live
which is what we should use, and users can set that to whatever they want. The
only question is what default to set it to (I personally would go with
something like 6 months but I don't feel very strongly on any number).
bq. I renamed the table to repair_jobs since each entry corresponds to a
RepairJob rather than a whole session
I'd go with repair_history or even just repairs rather than sticking too
closely to internal Java classes name, unless we particularly enjoy feeling
stupid when we rename said classes in a refactor that is.
bq. What do you consider stats (and not status) in the current schema?
I believe Yuki really just meant total_ranges_out_of_sync in the current
schema. And what I'd suggest is to leave this discussion to a follow up ticket.
I think there could be value in both some per-job simple stats (for quick
estimation of what the repair did do) as well as some per-job per-replica
"repair log" that provides more fine grained information. But it warrants it's
own discussion and so should be a separate ticket imo.
Nits:
* not a fan of system_global as a name. Imo it suggests that it might be
replicated to all nodes which it isn't. Not pretending I have a much better
proposition though.
* "coordinating_node" and "participant_nodes" should be of type "inet". I'd
also shorten the names, say "cordinator" and "participants".
> Save repair data to system table
> --------------------------------
>
> Key: CASSANDRA-5839
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5839
> Project: Cassandra
> Issue Type: New Feature
> Components: Core, Tools
> Reporter: Jonathan Ellis
> Assignee: Jimmy Mårdell
> Priority: Minor
> Fix For: 2.0.4
>
> Attachments: 2.0.4-5839-draft.patch
>
>
> As noted in CASSANDRA-2405, it would be useful to store repair results,
> particularly with sub-range repair available (CASSANDRA-5280).
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
