[
https://issues.apache.org/jira/browse/CASSANDRA-18105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716287#comment-17716287
]
Stefan Miklosovic edited comment on CASSANDRA-18105 at 4/26/23 11:27 AM:
-------------------------------------------------------------------------
Thanks, that helped.
3.0 https://github.com/apache/cassandra/pull/2286
3.11 https://github.com/apache/cassandra/pull/2289
4.0 https://github.com/apache/cassandra/pull/2290
4.1 https://github.com/apache/cassandra/pull/2291
trunk https://github.com/apache/cassandra/pull/2292
builds:
3.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2129/workflows/1252eca4-bbdd-426f-87b0-a93fbbc38723
3.11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2130/workflows/4c174ddb-23bd-4a3e-b57a-9a72b52b2245
4.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2131/workflows/d0753f31-82b7-4986-a4d3-f082cbe45047
4.1
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2132/workflows/c09cdd14-0f6b-40a0-a88b-aed766a88e4b
trunk
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2133/workflows/6215ee32-7e4c-40e2-8363-ca1069395cc0
I am running multiplexer like 1000x and it seem to be stable.
When one looks closer into what tests are failing for 3.0 / 3.11, they are
unrelated and they have something in common with
{code}
> configured_strategy =
> CONFIG.getoption("--upgrade-version-selection").upper()
E AttributeError: 'NoneType' object has no attribute 'getoption'
{code}
This is out of scope of this ticket. I think that these tests are using some
old way of doing things and it backfired here.
was (Author: smiklosovic):
Thanks, that helped.
3.0 https://github.com/apache/cassandra/pull/2286
3.11 https://github.com/apache/cassandra/pull/2289
4.0 https://github.com/apache/cassandra/pull/2290
4.1 https://github.com/apache/cassandra/pull/2291
trunk https://github.com/apache/cassandra/pull/2292
builds:
3.0
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2129/workflows/1252eca4-bbdd-426f-87b0-a93fbbc38723
3.11
https://app.circleci.com/pipelines/github/instaclustr/cassandra/2130/workflows/4c174ddb-23bd-4a3e-b57a-9a72b52b2245
4.0 tbd
4.1 tbd
trunk tbd
I am running multiplexer like 1000x and it seem to be stable.
When one looks closer into what tests are failing for 3.0 / 3.11, they are
unrelated and they have something in common with
{code}
> configured_strategy =
> CONFIG.getoption("--upgrade-version-selection").upper()
E AttributeError: 'NoneType' object has no attribute 'getoption'
{code}
This is out of scope of this ticket. I think that these tests are using some
old way of doing things and it backfired here.
> TRUNCATED data come back after a restart or upgrade
> ---------------------------------------------------
>
> Key: CASSANDRA-18105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18105
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
> Reporter: Ke Han
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When we use the TRUNCATE command to delete all data in the table, the deleted
> data come back after a node restart or upgrade. This problem happens at the
> latest releases (2.2.19, 3.0.28, or 4.0.7)
> h1. Steps to reproduce
> h2. To reproduce it at release (3.0.28 or 4.0.7)
> Start up a single Cassandra node. Using the default configuration and execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE IF NOT EXISTS ks WITH REPLICATION = { 'class' :
> 'SimpleStrategy', 'replication_factor' : 1 };
> CREATE TABLE ks.tb (c3 TEXT,c4 TEXT,c2 INT,c1 TEXT, PRIMARY KEY (c1, c2, c3
> ));
> INSERT INTO ks.tb (c3, c1, c2) VALUES ('val1','val2',1);
> CREATE INDEX IF NOT EXISTS tb ON ks.tb ( c3);
> TRUNCATE TABLE ks.tb;
> DROP INDEX IF EXISTS ks.tb; {code}
> Execute a read command
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
> ----
> (0 rows) {code}
> Then, we flush the node and kill the Cassandra daemon by
> {code:java}
> bin/nodetool flush
> pgrep -f cassandra | xargs kill -9 {code}
> We restart the node. When the node has started, perform the same read, and
> the deleted data comes back again.
> {code:java}
> cqlsh> SELECT c2 FROM ks.tb;
> c2
> ----
> 1
> (1 rows) {code}
> h2. To reproduce it at release (2.2.19)
> We don't need to kill the Cassandra daemon. Use bin/nodetool stopdaemon is
> enough. The other steps are the same as reproducing it at 4.0.7 or 3.0.28.
> {code:java}
> bin/nodetool -h ::FFFF:127.0.0.1 flush
> bin/nodetool -h ::FFFF:127.0.0.1 stopdaemon{code}
>
> I have put the full log to reproduce it for release 4.0.7 and 2.2.19 in the
> comments.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
