[
https://issues.apache.org/jira/browse/CASSANDRA-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Chan updated CASSANDRA-5483:
--------------------------------
Attachment:
v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch
v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch
v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch
These next few patches are different variations on adding {{nodetool}} control
of tracing (Use {{nodetool repair -tr}}), and are all based off of the
{{v02-0002}} patch, hence the naming and the {{0003}} numbering. An overview:
* {{v03}} simply adds a {{trace}} boolean to all of the repair functions.
* {{v04}} does not actually work, due to complications with sending an EnumSet
parameter via JMX.
* {{v05}} has the same structure as {{V04}}, except it uses a {{long}} and
traditional bitflags.
The idea for {{v04}} and {{v05}} was to consolidate all of the boolean options
into a single parameter. That way, adding or removing boolean options doesn't
require you to modify the entire call chain. It also makes binary compatibility
easier going forward (no need to maintain an ever growing list of function
overloads). I'm personally leaning towards {{v05}}.
---
About tracing to a separate table: an earlier comment mentioned wanting to
trace bootstrap and decommission. I wonder if these would go into that same
table. If so, I am thinking of calling the new table something generic like
{{system_traces.trace_logs}}. I also assume, that like
{{system_traces.events}}, the rows in this table should expire, though perhaps
not as fast as 24 hours. Thoughts on the naming and the use of the
{{system_traces}} schema?
---
One last thing I wanted to ask is about the possibility of trace log levels.
What is the minimum amount of trace log information you would find useful, the
next amount, and so on? Should it just follow the loglevel? (One possible
problem with that is you can't change loglevel without a server restart.)
I don't run Cassandra in any sort of production environment, so I'm not as
familiar with the use cases as I would like.
> Repair tracing
> --------------
>
> Key: CASSANDRA-5483
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5483
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Yuki Morishita
> Assignee: Ben Chan
> Priority: Minor
> Labels: repair
> Attachments: test-5483-system_traces-events.txt,
> trunk@4620823-5483-v02-0001-Trace-filtering-and-tracestate-propagation.patch,
> trunk@4620823-5483-v02-0002-Put-a-few-traces-parallel-to-the-repair-logging.patch,
> tr...@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt,
> [email protected],
> v02p02-5483-v03-0003-Make-repair-tracing-controllable-via-nodetool.patch,
> v02p02-5483-v04-0003-This-time-use-an-EnumSet-to-pass-boolean-repair-options.patch,
> v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.patch
>
>
> I think it would be nice to log repair stats and results like query tracing
> stores traces to system keyspace. With it, you don't have to lookup each log
> file to see what was the status and how it performed the repair you invoked.
> Instead, you can query the repair log with session ID to see the state and
> stats of all nodes involved in that repair session.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
