[
https://issues.apache.org/jira/browse/CASSANDRA-18956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779291#comment-17779291
]
Ke Han edited comment on CASSANDRA-18956 at 10/26/23 3:30 AM:
--------------------------------------------------------------
[~smiklosovic] Thanks for the reply!
(1) The expected situation should be an exception and system should stops this
request.
{code:java}
cqlsh> ALTER TABLE test.foos RENAME key TO "2f";
InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
rename column key to 2f in keyspace foos; another column of that name already
exist" {code}
(2) "No enough power to fix this bug." I totally agree. This bug happens
rarely, and 3.0 is going to be deprecated soon.
I have fixed this bug and submitted a PR for fixing. The root cause is: when
renaming column FROM => TO, the system checks whether FROM exists but does not
check TO properly. The fix is simple: also add a check for the TO column.
Do you mind taking a look at my PR? I really appreciate it! The PR is here:
[https://github.com/apache/cassandra/pull/2840]
was (Author: JIRAUSER289562):
[~smiklosovic] Thanks for the reply!
(1) The expected situation should be an exception and system should stops this
request.
{code:java}
cqlsh> ALTER TABLE test.foos RENAME key TO "2f";
InvalidRequest: Error from server: code=2200 [Invalid query] message="Cannot
rename column key to 2f in keyspace foos; another column of that name already
exist" {code}
(2) "No enough power to fix this bug." I totally agree. This bug happens
rarely, and 3.0 is going to be deprecated soon.
I have fixed this bug and submitted a PR for fixing. The fix is simple: when
renaming column FROM => TO, the system checks whether FROM exists but not check
TO properly. This PR adds an additional check.
Do you mind taking a look at my PR? I really appreciate it! The PR is here:
[https://github.com/apache/cassandra/pull/2840]
> Metadata Loss caused by unchecked rename column when upgrading from 2.x to
> 3.0.29
> ---------------------------------------------------------------------------------
>
> Key: CASSANDRA-18956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18956
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Distributed Metadata
> Reporter: Ke Han
> Priority: Normal
> Attachments: data.tar.gz, signature.asc
>
>
> After migrating data from 2.1.22 (released 2022-06-17) to 3.0.29 (released
> 2023-05-05), if user performs a rename operation to rename the primary key to
> an existing column, it will succeed, and the original column will get lost
> permanently.
> h1. Reproduce
> Start up single cassandra node 2.1.22, create the following table using
> cassandra-cli
> {code:java}
> # bin/cassandra-cli
> create keyspace test with strategy_options = {replication_factor:1} and
> placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy';
> use test;
> create column family foos
> with column_type = 'Standard'
> and comparator = 'BytesType'
> and key_validation_class = 'UTF8Type'
> and column_metadata = [{column_name: '2f', validation_class: 'UTF8Type'}];
> {code}
> Stop the daemon
> {code:java}
> bin/nodetool -h ::FFFF:127.0.0.1 stopdaemon {code}
> Upgrade, start up new version
> {code:java}
> cqlsh> desc test.foos ;
> CREATE TABLE test.foos (
> key text PRIMARY KEY,
> "2f" text
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
> cqlsh> ALTER TABLE test.foos RENAME key TO "2f";
> cqlsh> desc test.foos ;
> CREATE TABLE test.foos (
> "2f" text PRIMARY KEY
> ) WITH COMPACT STORAGE
> AND bloom_filter_fp_chance = 0.01
> AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = {'chunk_length_in_kb': '64', 'class':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = 'NONE';
> cqlsh> SELECT * FROM test.foos ;
> 2f
> ----
> (0 rows) {code}
> h1. Root Cause
> The root cause is a missing check for the existing column when the table
> comparator from the old version is BytesType.
> I have uploaded the data dir, use it to start up 3.0.29 and execute the
> commands will reproduce this bug.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
