cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10805) Additional Compaction Logging
Date Thu, 25 Feb 2016 19:21:18 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167682#comment-15167682
] 

Carl Yeksigian commented on CASSANDRA-10805:
--------------------------------------------

I've been looking at logback and how we might be able to use logback directly. The biggest
problem is that there isn't a notification for when the log file changes. We need to know
that the logfile is changing so that we can log out the sstables that are already on disk
so that each logfile is independent (and old ones can be deleted).
We won't be able to use the logback loggers, or logback.xml, because we won't be able to use
the loggers as they are currently defined, since additional information needs to be passed
on creation of the logger to know what tables' files to log on a new file.
We can still use the infrastructure of logback to be able to execute the mechanics of doing
the log rotations so that we aren't responsible for it; it just won't be as seamless as updating
the logback.xml files and having it reread it.

> Additional Compaction Logging
> -----------------------------
>
>                 Key: CASSANDRA-10805
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10805
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Compaction, Observability
>            Reporter: Carl Yeksigian
>            Assignee: Carl Yeksigian
>            Priority: Minor
>
> Currently, viewing the results of past compactions requires parsing the log and looking
at the compaction history system table, which doesn't have information about, for example,
flushed sstables not previously compacted.
> This is a proposal to extend the information captured for compaction. Initially, this
would be done through a JMX call, but if it proves to be useful and not much overhead, it
might be a feature that could be enabled for the compaction strategy all the time.
> Initial log information would include:
> - The compaction strategy type controlling each column family
> - The set of sstables included in each compaction strategy
> - Information about flushes and compactions, including times and all involved sstables
> - Information about sstables, including generation, size, and tokens
> - Any additional metadata the strategy wishes to add to a compaction or an sstable, like
the level of an sstable or the type of compaction being performed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message