[
https://issues.apache.org/jira/browse/CASSANDRA-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654568#comment-15654568
]
Paulo Motta commented on CASSANDRA-12186:
-----------------------------------------
This looks good, but how about using the same {{\[repair
#b14328a9-dcbc-4bc3-b1d2-47ea48256757\]}} prefix so it's consistent with the
rest of repair logging? If you agree, could you provide another patch with this
change? You can probably include this prefix in other anti-compaction messages
as well.
Also, I think we can/should include this on 3.0 as well, since this is not
invasive and will help troubleshooting. Can you provide a 3.0, trunk, and 4.0
patches prepared for commit (add CHANGES.TXT entry and commit message according
to [these
guidelines|http://cassandra.apache.org/doc/latest/development/patches.html]) ?
> anticompaction log message doesn't include the parent repair session id
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-12186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12186
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability
> Reporter: Wei Deng
> Assignee: Tommy Stendahl
> Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 12186.txt
>
>
> It appears that even though incremental repair is now enabled by default post
> C*-3.0 (which means at the end of each repair session, there is an
> anti-compaction step that needs to be executed), we don't include the parent
> repair session UUID in the log message of the anti-compaction log entries.
> This makes observing all activities related to an incremental repair session
> to be more difficult. See the following:
> {noformat}
> DEBUG [AntiEntropyStage:1] 2016-07-13 01:57:30,956
> RepairMessageVerbHandler.java:149 - Got anticompaction request
> AnticompactionRequest{parentRepairSession=27103de0-489d-11e6-a6d6-cd06faa0aaa2}
> org.apache.cassandra.repair.messages.AnticompactionRequest@34449ff4
> <...>
> <snip>
> <...>
> INFO [CompactionExecutor:5] 2016-07-13 02:07:47,512
> CompactionManager.java:511 - Starting anticompaction for trivial_ks.weitest
> on
> 1/[BigTableReader(path='/var/lib/cassandra/data/trivial_ks/weitest-538b07d1489b11e6a9ef61c6ff848952/mb-1-big-Data.db')]
> sstables
> INFO [CompactionExecutor:5] 2016-07-13 02:07:47,513
> CompactionManager.java:540 - SSTable
> BigTableReader(path='/var/lib/cassandra/data/trivial_ks/weitest-538b07d1489b11e6a9ef61c6ff848952/mb-1-big-Data.db')
> fully contained in range (-9223372036854775808,-9223372036854775808],
> mutating repairedAt instead of anticompacting
> INFO [CompactionExecutor:5] 2016-07-13 02:07:47,570
> CompactionManager.java:578 - Completed anticompaction successfully
> {noformat}
> The initial submission of the anti-compaction task to the CompactionManager
> still has reference to the parent repair session UUID, but subsequent
> anti-compaction log entries are missing this parent repair session UUID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
