cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6570) Compatibility mode for 2.1
Date Fri, 10 Jan 2014 20:49:51 GMT

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

Jonathan Ellis commented on CASSANDRA-6570:
-------------------------------------------

bq. 2.1 is an unusually good place to do this since AFAIK we haven't made any other incompatible
changes, e.g. to schema propagation.

... thinking about it more, it's also an unusually poor place since we got rid of the two-pass
compaction that the old format required for large rows.

I could see

# adding back precompacted row (which is at least relatively simple) and just saying we won't
compact 2.0-format rows larger than in_memory_compaction_limit
# or, adding back two-pass compaction

Is there a clever 80% solution I'm missing?

> Compatibility mode for 2.1
> --------------------------
>
>                 Key: CASSANDRA-6570
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6570
>             Project: Cassandra
>          Issue Type: Task
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Marcus Eriksson
>             Fix For: 2.1
>
>
> Upgrading to a new major Cassandra release is a big commitment, because once on a new
version you can't downgrade again because we write new-version sstables.
> Let's add an option to write old-version sstables so that users can try upgrading a single
2.1 RC node in a 2.0 cluster with the safety net of being able to back it out if anything
goes wrong.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message