[
https://issues.apache.org/jira/browse/CASSANDRA-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17138278#comment-17138278
]
Sylvain Lebresne commented on CASSANDRA-13994:
----------------------------------------------
I have made a first pass of review and offered a few remarks above.
But I think this ticket is hang up on us deciding whether removing the KEYS
2ndary index code is ok or not. And this yield, to me, the question of what is
the upgrade path to 4.0 for users that still have KEYS index (which, reminder,
could only be created with Thrift, but could _used_ with CQL and thus still be
around).
Because, while I haven't tested this myself, I suspect we have a hole here.
Namely, KEYS index were compact tables, and 4.0 does not *start* if there is
still compact tables. And while for user tables, user are asked to use {{DROP
COMPACT STORAGE}} before upgrading, this cannot be done on KEYS index (there is
just no syntax to do it), so unless there is code I'm not aware of (and please,
someone correct me if I'm wrong), I don't think user can upgrade to 4.0 at all
if they still have KEYS index. They'd have to drop those index first.
So If I'm right here, this technically mean removing the KEYS index code in 4.0
is fine, since you cannot upgrade in the first place if you have KEYS index.
But the more important question for 4.0 imo is what is the upgrade path for
users if they have a KEYS index in 3.X?
Currently (without code changes), the only available option I can think of is
that before upgrade to 4.0, users would have to 1) drop their KEYS index and
then 2) re-create a "normal" (non-KEYS) equivalent index.
Are we comfortable with that being the upgrade path for KEYS index?
Personally, I'm not sure I am because this is not a seamless upgrade, as
between the 1) and 2) above, there is a window where there is no accessible
index, so if the user application rely on it, it means a period of downtime for
the application to perform the upgrade. However, if we want a more seamless
upgrade, we need to figure something out, and that probably involve non trivial
amounts of code and testing. And, playing devil's advocate, KEYS index being so
old, maybe nobody that plans to upgrade to 4.0 have them anymore, and maybe
it's not worth bothering?
So I could use others opinions here.
Tl;dr, this ticket raises the point that "Oops, I'm not sure we have though
through the question of upgrade to 4.0 for KEYS indexes". And tbc, it's not
directly related to this ticket, only indirectly, but it is still something we
need to figure out. And I'd say, before 4.0-alpha. But I'm happy to create a
separate ticket specific to that question if that helps.
> Remove COMPACT STORAGE internals before 4.0 release
> ---------------------------------------------------
>
> Key: CASSANDRA-13994
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13994
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Local Write-Read Paths
> Reporter: Alex Petrov
> Assignee: Ekaterina Dimitrova
> Priority: Low
> Fix For: 4.0, 4.0-alpha
>
>
> 4.0 comes without thrift (after [CASSANDRA-11115]) and COMPACT STORAGE (after
> [CASSANDRA-10857]), and since Compact Storage flags are now disabled, all of
> the related functionality is useless.
> There are still some things to consider:
> 1. One of the system tables (built indexes) was compact. For now, we just
> added {{value}} column to it to make sure it's backwards-compatible, but we
> might want to make sure it's just a "normal" table and doesn't have redundant
> columns.
> 2. Compact Tables were building indexes in {{KEYS}} mode. Removing it is
> trivial, but this would mean that all built indexes will be defunct. We could
> log a warning for now and ask users to migrate off those for now and
> completely remove it from future releases. It's just a couple of classes
> though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
