[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648253#comment-17648253
]
Paulo Motta commented on CASSANDRA-14013:
-----------------------------------------
The reason why {{SSTableLoaderTest#testLoadingBackupsTable}} was failing was
because this test was using the legacy table directory format which does not
have {{{}-{uuid{}}}} part and the regex was failing to pick up this case.
On [this
commit|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631],
I added the {{./*}} prefix to the regex which made it pick up the case of a
"backups" table in the legacy directory format without the table uuid. I also
updated {{SSTableLoaderTest}} to use the new [table directory
format|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631#diff-7caf9acb4092d0f8da99e009b74cab5832ee797d5c9b191ab2e3b394a533812fR333].
We did not have a test on {{DescriptorTest#testKeyspaceTableParsing}} to pick
up the scenario of a legacy "backups" table directory and keyspace, when the
table id suffix is missing so I added it
[here|https://github.com/pauloricardomg/cassandra/commit/59f42ce2e58f7846355ebb9f3395fceb28c76631#diff-f1003299495ea8593e83c86e261e77d7d6d7a57a52c61f52e51e7e816fcdad5eR223].
However, neither the solutions are able to correctly parse a snapshot in a
legacy "backups" table, for example
{noformat}
/path/to/cassandra/data/dir2/dir5/dir6/backups/backups/snapshots/snapshots/na-1-big-Index.db
{noformat}
Both approaches consider this an sstable on the "snapshots" table of the
"snapshots" directory, and not a snapshot on the "backups" table of the
"backups" keyspace. However I don't think we need to fix for this case as we
should no longer support directories in the legacy format moving forward.
I have submitted a CI run for the latest branch
[here|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/2106/].
[~smiklosovic] if tests look good and you're ok I can prepare patch for earlier
versions with the simpler fix, and the regex fix on trunk. Should we do just
4.x or 3.X too?
> Data loss in snapshots keyspace after service restart
> -----------------------------------------------------
>
> Key: CASSANDRA-14013
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14013
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core, Local/Snapshots
> Reporter: Gregor Uhlenheuer
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 4.0.x, 4.1.x, 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am posting this bug in hope to discover the stupid mistake I am doing
> because I can't imagine a reasonable answer for the behavior I see right now
> :-)
> In short words, I do observe data loss in a keyspace called *snapshots* after
> restarting the Cassandra service. Say I do have 1000 records in a table
> called *snapshots.test_idx* then after restart the table has less entries or
> is even empty.
> My kind of "mysterious" observation is that it happens only in a keyspace
> called *snapshots*...
> h3. Steps to reproduce
> These steps to reproduce show the described behavior in "most" attempts (not
> every single time though).
> {code}
> # create keyspace
> CREATE KEYSPACE snapshots WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> # create table
> CREATE TABLE snapshots.test_idx (key text, seqno bigint, primary key(key));
> # insert some test data
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1', 1);
> ...
> INSERT INTO snapshots.test_idx (key,seqno) values ('key1000', 1000);
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 1000
> # restart service
> kill <cassandra-pid>
> cassandra -f
> # count entries
> SELECT count(*) FROM snapshots.test_idx;
> 0
> {code}
> I hope someone can point me to the obvious mistake I am doing :-)
> This happened to me using both Cassandra 3.9 and 3.11.0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
