[
https://issues.apache.org/jira/browse/CASSANDRA-15072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808019#comment-16808019
]
Blake Eggleston commented on CASSANDRA-15072:
---------------------------------------------
This is a great repro script, thanks.
A couple of observations:
* test.test has 2 columns, and uses compact storage, which shouldn’t be
possible
* node1 & node3 are the replicas of the missing partition (we’re querying from
the un-upgraded node2, for those following along).
* doing a point read ({{select * from test.test where id=‘1’;}}) returns the
expected partition
* using LIMIT 2 instead of PAGING 2 has the same problem
* LIMIT 3 returns a partial row: {{1 | there | null}}
* LIMIT 4 returns the entire row: {{1 | there | hi}}
Tables with compact storage can only have a single column, so you shouldn’t be
able to create a compact storage table with 2 columns. Instead of throwing an
error though, it seems like it just silently treats the table as a normal
table. This might be why no one has noticed that our ddl validation is broken.
It looks like the mixed mode read path is treating the table as a proper
compact storage table though, and treating each cell as a row, which is why you
see partial rows start to appear as you increase the limit. If you remove
compact storage from the ddl, or only use a single column, everything works
normally.
I'll think on the best way to address this.
> Incomplete range results during 2.X -> 3.11.4 upgrade
> -----------------------------------------------------
>
> Key: CASSANDRA-15072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15072
> Project: Cassandra
> Issue Type: Bug
> Reporter: Muir Manders
> Assignee: Blake Eggleston
> Priority: High
> Attachments: eriksw-repro.sh
>
>
> Hello
> During an upgrade from 2.1.17 to 3.11.4, our application starting getting
> back incomplete results for range queries. When all nodes were upgraded
> (before upgrading sstables), we stopped getting incomplete results. I was
> able to reproduce it and listed steps below. It seems to require the random
> partitioner and compact storage to reproduce reliably. It also reproduces
> coming from 2.1.21 and 2.2.14. You seem to get the bad behavior when an old
> node is your coordinator and it has to talk to an upgraded replica.
> {noformat}
> ccm create test -v 2.1.17 -n 3
> ccm updateconf 'partitioner: org.apache.cassandra.dht.RandomPartitioner'
> ccm node1 updateconf 'initial_token: 0'
> ccm node2 updateconf 'initial_token: 56713727820156410577229101238628035242'
> ccm node3 updateconf 'initial_token: 113427455640312821154458202477256070484'
> ccm start
> ccm node1 cqlsh <<SCHEMA
> CREATE KEYSPACE test WITH REPLICATION = {'class': 'SimpleStrategy',
> 'replication_factor': 3};
> CREATE COLUMNFAMILY test.test (
> id text,
> foo text,
> bar text,
> PRIMARY KEY (id)
> ) WITH COMPACT STORAGE;
> CONSISTENCY QUORUM;
> INSERT INTO test.test (id, foo, bar) values ('1', 'hi', 'there');
> INSERT INTO test.test (id, foo, bar) values ('2', 'hi', 'there');
> SCHEMA
> ccm node1 stop
> ccm node1 setdir -v 3.11.4
> ccm node1 start
> ccm node2 stop
> ccm node2 setdir -v 3.11.4
> ccm node2 start
> # here I use 3.X cqlsh to connect to 2.X node so I can lower the page size (to
> # allow for simpler test setup)
> cqlsh 127.0.0.3 <<QUERY
> CONSISTENCY QUORUM;
> PAGING 2;
> select * from test.test;
> QUERY
> {noformat}
> This results in:
> {noformat}
> Page size: 2
> id | bar | foo
> ----+-------+-----
> 2 | there | hi
> (1 rows)
> {noformat}
> Running it against the upgraded node (node1):
> {noformat}
> Page size: 2
> id | bar | foo
> ----+-------+-----
> 2 | there | hi
> 1 | there | hi
> (2 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
