cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Greaves (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-14197) SSTable upgrade should be automatic
Date Thu, 26 Apr 2018 06:01:00 GMT

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

Kurt Greaves edited comment on CASSANDRA-14197 at 4/26/18 6:00 AM:
-------------------------------------------------------------------

This was kind of why I was assuming this is more of an advanced feature. You wouldn't want
to do it unless you had significant extra capacity + knew what you were in for, because we're
essentially tying the format upgrade process with the version upgrade process.
{quote}It seems like a single thread is probably fine because there is no rush to get the
tables upgraded right?
{quote}
Correct me if I'm wrong but restricting it to a single thread would mean we block compactions
on each table for a longer period, right? This means if a table has a lot of data we could
cause performance degradation over time.

These compactions are still throttled by {{compactionthroughput}} (I'm fairly sure), so I
don't see a major issue with using all threads available (although maybe it should be configurable?).
I guess my only question would be will upgrades block minor compactions on other tables occuring?
In my experience the answer is no but I'm not sure if there's anything in the code to actually
prioritise compactions over upgrades.

 

But either way, I don't see it as a major problem because anyone using this option should
know ahead of time the overhead the upgrades are going to cause and how much capacity they
need to handle it. It's probably a good idea to add some information about that to NEWS.txt
and the actual jvm option in {{jvm.options}} and in the docs...?


was (Author: kurtg):
This was kind of why I was assuming this is more of an advanced feature. You wouldn't want
to do it unless you had significant extra capacity + knew what you were in for, because we're
essentially tying the format upgrade process with the version upgrade process.
{quote}It seems like a single thread is probably fine because there is no rush to get the
tables upgraded right?
{quote}
Correct me if I'm wrong but restricting it to a single thread would mean we block compactions
on each table for a longer period, right? This means if a table has a lot of data we could
cause performance degradation.

These compactions are still throttled by {{compactionthroughput}} (I'm fairly sure), so I
don't see a major issue with using all threads available (although maybe it should be configurable?).
I guess my only question would be will upgrades block minor compactions on other tables occuring?
In my experience the answer is no but I'm not sure if there's anything in the code to actually
prioritise compactions over upgrades.

 

But either way, I don't see it as a major problem because anyone using this option should
know ahead of time the overhead the upgrades are going to cause and how much capacity they
need to handle it. It's probably a good idea to add some information about that to NEWS.txt
and the actual jvm option in {{jvm.options}} and in the docs...?

> SSTable upgrade should be automatic
> -----------------------------------
>
>                 Key: CASSANDRA-14197
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-14197
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Marcus Eriksson
>            Assignee: Marcus Eriksson
>            Priority: Major
>             Fix For: 4.x
>
>
> Upgradesstables should run automatically on node upgrade



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message