[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226269#comment-17226269
]
Benjamin Lerer edited comment on CASSANDRA-14013 at 11/4/20, 5:10 PM:
----------------------------------------------------------------------
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshots" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshots"
and table which is called "snapshots" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or indexes named
{{snapshots}} or {{backups}} are trully a problem because their corresponding
directories will have different names.
The directory name for a table named {{snapshots}} is {{snapshots-<TableID>}}
and the directory name for an index named {{snapshots}} is {{.snapshots}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshots}} will result in a directory called {{snapshots}}.
was (Author: blerer):
{quote}The current solution does not count on the fact that for example there
might be also a snapshot / table called "snapshot" as well as "backups" for
example - same for indexes and indexes in backups and snapshots. There might be
also a snapshot called "snapshot" for a keyspace which is called "snapshot" and
table which is called "snapshot" too and so on ... {quote}
[~stefan.miklosovic] I do not believe that tables or indexes named {{snapshot}}
or {{backups}} are trully a problem because their corresponding directories
will have different names.
The directory name for a table named {{snapshot}} is {{snapshot-<TableID>}} and
the directory name for an index named {{snapshot}} is {{.snapshot}}.
The {{testKeyspaceTableParsing}} is incorrect because it assumes that a table
named {{snapshot}} will result in a directory called {{snapshot}}.
> 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
> Reporter: Gregor Uhlenheuer
> Assignee: Stefan Miklosovic
> Priority: Normal
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
