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)?
On 1/31/2012 5:03 PM, Benjamin Hawkes-Lewis wrote:
On Wed, Feb 1, 2012 at 12:58 AM, Todd Fast<firstname.lastname@example.org> wrote:
I added a row with a single column to my 1.0.8 single-node cluster:
=> (column=test, value=hi, timestamp=...)
I immediately deleted the row using both the CLI and CQL:
delete from Foo using consistency all where
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.