[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17226335#comment-17226335
]
Stefan Miklosovic edited comment on CASSANDRA-14013 at 11/4/20, 7:05 PM:
-------------------------------------------------------------------------
[~blerer] more to it, I have just added that "tableId" into test, that is just
minor detail, the implementation already copes with that.
Devil is in details, for example, for sstableloader, people might put sstable
into /tmp/some/path/mykeyspace/mytable/(data files), and that "mytable" will
not have any "id" on it ... the solution works with both scenarios. Plus this
"path" might be arbitrary, different from the actual data locations specified
in cassandra.yaml etc ...
What I do not like in particular is that the whole solution feels rather
"spaghetti-like" (I do not want to offend here anybody). I based my solution on
regular expressions.
bq. It seems to me that when we hit a directory named snapshots, it can either
be the snapshots directory or the keyspace directory.
And you can have also a snapshot taken which is called "snapshots" :) That
complicates things ever further. Now what, you have a "snapshots" dir where
snapshots are and there you might have "snapshots" dir which represents the
snapshot taken etc etc ...
was (Author: stefan.miklosovic):
[~blerer] more to it, I have just added that "tableId" into test, that is just
minor detail, the implementation already copes with that.
Devil is in details, for example, for sstableloader, people might put sstable
into /tmp/some/path/mykeyspace/mytable/(data files), and that "mytable" will
not have any "id" on it ... the solution works with both scenarios. Plus this
"path" might be arbitrary, different from the actual data locations specified
in cassandra.yaml etc ...
What I do not like in particular is that the whole solution feels rather
"spaghetti-like" (I do not want to offend here anybody). I based my solution on
regular expressions.
> 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
