First, thanks! I'd read that before, but didn't associate doing a range
scan with using the CLI, much less doing "select count(*)" in CQL. Now I
know what to call the phenomenon.
Second, a followup question: So the row keys will be deleted after 1)
the GC grace period expires, and 2) I do a compaction?
Third: Assuming the answer is yes, is there any way to manually force GC
of the deleted keys without doing the full "GC shuffle" (setting the GC
grace period artificially low, restarting, compacting, setting grace
period back to normal, restarting)?
Todd
On 1/31/2012 5:03 PM, Benjamin Hawkes-Lewis wrote:
On Wed, Feb 1, 2012 at 12:58 AM, Todd Fast<t...@conga.com> wrote:
I added a row with a single column to my 1.0.8 single-node cluster:
RowKey: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
=> (column=test, value=hi, timestamp=...)
I immediately deleted the row using both the CLI and CQL:
del Foo[lexicaluuid('aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa')];
delete from Foo using consistency all where
KEY=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
In either case, the column "test" is gone but the empty row key still
remains, and the row count reflects the presence of this phantom row.
I've tried nodetool compact/repair/flush/cleanup/scrub/etc. and nothing
removes the row key.
http://wiki.apache.org/cassandra/FAQ#range_ghosts
--
Benjamin Hawkes-Lewis
