[
https://issues.apache.org/jira/browse/CASSANDRA-8460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14598730#comment-14598730
]
Jeff Jirsa commented on CASSANDRA-8460:
---------------------------------------
Thanks for the feedback, [~krummas]!
{quote}
Can't we check before starting an archive compaction if there are any archive
locations available? If there are none, we shouldn't compact, right?
{quote}
Yea. There's a few cases here, and I suppose that answer works for all of them:
- CF compaction strategy specifies archive tier, but no disk is configured on
the node
- CF compaction strategy specifies archive tier, but there's no free space
- If we were to allowe max_sstable_age_days > archive_sstables_age_days, there
could be a use case where 2 sstables on archive storage would be eligible for
compaction, but there may not be room for them to be combined. If we don't
allow this, then the potential edge case goes away.
{quote}
I guess it could be a problem if users increase max_sstable_age_days and we
move the data back to the fast disks though, thoughts?
{quote}
Is that a problem? If the user wants to tune the parameter, we should support
it.
{quote}
As in 2), I think we should never compact the sstables on the slow disks.
{quote}
I'll write it however you want it, but my assumption was that the
{{max_sstable_age_days}} parameter is set and greater than
{{archive_sstables_age_days}}, we would still compact, it's just obviously
slower. In my mind, it's a cost/performance tradeoff for operators - slow disk
may not be SUPER slow, it may just be 10k iops instead of 20k iops, so
compaction may be OK, just not the best for hottest data. If you're adamant
about not allowing compaction on the archive tier, I'll add a check so that
{{max_sstable_age_days}} can not be set higher than
{{archive_sstables_age_days}} .
{quote}
you should probably check absolute paths and use startsWith?
{quote}
Noted, I like that way better.
Thanks again. I'll work on finishing this up and adding some tests.
> Make it possible to move non-compacting sstables to slow/big storage in DTCS
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-8460
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8460
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Marcus Eriksson
> Assignee: Jeff Jirsa
> Labels: dtcs
> Fix For: 3.x
>
>
> It would be nice if we could configure DTCS to have a set of extra data
> directories where we move the sstables once they are older than
> max_sstable_age_days.
> This would enable users to have a quick, small SSD for hot, new data, and big
> spinning disks for data that is rarely read and never compacted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
