[
https://issues.apache.org/jira/browse/CASSANDRA-14013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227347#comment-17227347
]
Benjamin Lerer edited comment on CASSANDRA-14013 at 11/6/20, 11:29 AM:
-----------------------------------------------------------------------
Trying to summarize the problem:
# SSTables used within the C* data directories should be within the data
directories returned by {{DatabaseDescriptor.getAllDataFileLocations()}} and
the table directories should be in the form {{<table name>-<TableID>}}. In this
case the problem come mainly from keyspace being named {{backups}} or
{{snapshots}}.
# Files coming from SSTableLoader should be outside of the data directories and
the table name should be without the TableID. In this case, keyspaces and
tables with a
{{backups}} or {{snapshots}} name will be having issues.
To be honest, the documentation I found on the SSTableloader is pretty
confusing and I imagine that some people might try to use it directly on the C*
data directories in which case the table directory will contains the TableID.
This case is somehow the same than the {{1.}} above.
[~stefan.miklosovic] As you pointed out there are several scenario that we
never tested {{nodetool snapshot}} with a {{snapshots}} or {{backups}} tag
name. SSTableLoader for a {{snapshots}} table (the {{backups}} name was tested
by CASSANDRA-16235. The patch should add some tests for those scenarios.
We should also probably test a {{nodetool refresh}} with a {{snapshots}} or
{{backups}} keyspace.
Pinging [~e.dimitrova] as she was involved in CASSANDRA-16235.
was (Author: blerer):
Trying to summarize the problem:
# SSTables used within the C* data directories should be within the data
directories returned by {{DatabaseDescriptor.getAllDataFileLocations()}} and
the table directories should be in the form {{<table name>-<TableID>}}. In this
case the problem come mainly from keyspace being named {{backups}} or
{{snapshots}}.
# Files coming from SSTableLoader should outside of the data directories and
the table name should be without the TableID. In this case, keyspace and table
with a
{{backups}} or {{snapshots}} name will be having issues.
To be honest, the documentation I found on the SSTableloader is pretty
confusing and I imagine that some people might try to use it directly on the C*
data directories in which case the table directory will contains the TableID.
This case is somehow the same than the {{1.}} above.
[~stefan.miklosovic] As you pointed out there are several scenario that we
never tested {{nodetool snapshot}} with a {{snapshots}} or {{backups}} tag
name. SSTableLoader for a {{snapshots}} table (the {{backups}} name was tested
by CASSANDRA-16235. The patch should add some tests for those scenarios.
We should also probably test a {{nodetool refresh}} with a {{snapshots}} or
{{backups}} keyspace.
Pinging [~e.dimitrova] as she was involved in CASSANDRA-16235.
> 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
