[jira] [Commented] (CASSANDRA-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-13313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16297215#comment-16297215 ] Jeff Jirsa commented on CASSANDRA-13313: Reopening, patch coming soon. > Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0 > -- > > Key: CASSANDRA-13313 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13313 > Project: Cassandra > Issue Type: Bug > Components: Compaction >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Minor > > Before 3.0 we used sstable ancestors to figure out if an sstable was left > over after a compaction. In 3.0 the ancestors are ignored and instead we use > LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2 > compaction leftovers using the on-disk sstable ancestors when available. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
[ https://issues.apache.org/jira/browse/CASSANDRA-13313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939531#comment-15939531 ] Stefania commented on CASSANDRA-13313: -- > My expectation was the only consistency issue is counters Counters created before 2.1, after 2.1 it is no longer a concern. > there are other resource issues (disk space, memory on reads if there are a > lot of tombstones, etc). Correct, during the 7066 discussions, I remember this was mentioned, that at worst it would be a resource issue and only affecting users who would attempt to upgrade without a clean shutdown. > I'm not sure how vital it is - I marked it minor and it's low on my queue, > but if consensus is it's truly a won't-fix I'm not sure I'll fight that. CASSANDRA-12212 was a won't fixed mostly because the benefit was very low. However, if there is a patch, I am not at all opposed to it. > Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0 > -- > > Key: CASSANDRA-13313 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13313 > Project: Cassandra > Issue Type: Bug > Components: Compaction >Reporter: Jeff Jirsa >Assignee: Jeff Jirsa >Priority: Minor > > Before 3.0 we used sstable ancestors to figure out if an sstable was left > over after a compaction. In 3.0 the ancestors are ignored and instead we use > LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2 > compaction leftovers using the on-disk sstable ancestors when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-13313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939519#comment-15939519
]
Jeff Jirsa commented on CASSANDRA-13313:
Oh I hadn't seen 12212
I have a patch where it's implemented with {{compactions_in_progress}} and
re-added (but deprecated) ancestors to metadata , but hadn't finished the dtest.
My expectation was the only consistency issue is counters but there are other
resource issues (disk space, memory on reads if there are a lot of tombstones,
etc).
I'm not sure how vital it is - I marked it minor and it's low on my queue, but
if consensus is it's truly a won't-fix I'm not sure I'll fight that.
> Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
> --
>
> Key: CASSANDRA-13313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13313
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> Before 3.0 we used sstable ancestors to figure out if an sstable was left
> over after a compaction. In 3.0 the ancestors are ignored and instead we use
> LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2
> compaction leftovers using the on-disk sstable ancestors when available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13313) Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
[
https://issues.apache.org/jira/browse/CASSANDRA-13313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15939503#comment-15939503
]
Stefania commented on CASSANDRA-13313:
--
There was a similar discussion in CASSANDRA-12212 - albeit focused on using
{{compactions_in_progress}} rather than ancestors. Other than counters created
before 2.1, are you aware of any other possible consistency issues?
> Compaction leftovers not removed on upgrade 2.1/2.2 -> 3.0
> --
>
> Key: CASSANDRA-13313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13313
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
>Reporter: Jeff Jirsa
>Assignee: Jeff Jirsa
>Priority: Minor
>
> Before 3.0 we used sstable ancestors to figure out if an sstable was left
> over after a compaction. In 3.0 the ancestors are ignored and instead we use
> LogTransaction files to figure it out. 3.0 should still clean up 2.1/2.2
> compaction leftovers using the on-disk sstable ancestors when available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
