cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Chan (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-5483) Repair tracing
Date Sat, 01 Mar 2014 21:05:21 GMT


Ben Chan updated CASSANDRA-5483:

    Attachment: v02p02-5483-v05-0003-Use-long-instead-of-EnumSet-to-work-with-JMX.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
* {{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 {{}}, 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:
>             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, trunk@8ebeee1-5483-v01-001-trace-filtering-and-tracestate-propagation.txt,
trunk@8ebeee1-5483-v01-002-simple-repair-tracing.txt, 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

View raw message