My two keys that I send in my test program are 0xe695b0e69982e99693 and 0x666f6f, which decodes to "数時間" and "foo" respectively.

So I ran my tests again, I started with a clean 0.6.13, wrote two rows with those two keys, drained, shut down, started 0.7.5, and imported my keyspace.

In my test program, when I do multi_get_slice, I send in those two keys, and get back a datastructure that contains the exact same keys, but only the structure under the key 0x666f6f contains any columns.

When I do a simple get with the first key, I get a NotFoundException. The second key works fine.

Doing get_range_slices, I get back two KeySlices, the keys are the exact same, and both have their columns.

If I run sstablekeys on the datafile, it prints out:
e695b0e69982e99693
666f6f

If I run sstable2json on the datafile, it prints out:
{
"e695b0e69982e99693": [["00", "01", 1304519723589, false]],
"666f6f": [["00", "01", 1304519721274, false]]
}


After that I re-inserted a row with the first key and then ran my tests again. Now both single gets work fine, multi_get_slice works fine, but get_range_slices return a structure with three keys:
0xe695b0e69982e99693
0xe695b0e69982e99693
0x666f6f

I restarted Cassandra to make it flush the commitlog, and my datadirectory now has two data files. When I run sstablekeys on the first one it still prints out:
e695b0e69982e99693
666f6f

And running it on the second datafile makes it print out:
e695b0e69982e99693


After all that, I forced a compaction with nodetool and restarted the server, ending up with a single datafile. When I run sstable2json on that, it prints out:
{
"e695b0e69982e99693": [["00", "01", 1304519723589, false]],
"e695b0e69982e99693": [["00", "02", 1304521931818, false]],
"666f6f": [["00", "01", 1304519721274, false]]
}

So I now have an SSTable with two rows with identical keys, except one of the rows doesn't really work? So, now what? And how did I end up in this state?


/Henrik Schröder


On Tue, May 3, 2011 at 22:10, aaron morton <aaron@thelastpickle.com> wrote:
Can you provide some details of the data returned from you do the =
get_range() ? It will be interesting to see the raw bytes returned for =
the keys. The likely culprit is a change in the encoding. Can you also =
try to grab the bytes sent for the key when doing the single select that =
fails.=20

You can grab these either on the client and/or by turing on the logging =
the DEBUG in conf/log4j-server.properties

Thanks
Aaron

On 4 May 2011, at 03:19, Henrik Schröder wrote:

> The way we solved this problem is that it turned out we had only a few hundred rows with unicode keys, so we simply extracted them, upgraded to 0.7, and wrote them back. However, this means that among the rows, there are a few hundred weird duplicate rows with identical keys.
>
> Is this going to be a problem in the future? Is there a chance that the good duplicate is cleaned out in favour of the bad duplicate so that we suddnely lose those rows again?
>
>
> /Henrik Schröder