Sylvain - We have similar problem but the discrepancy is not that big.
Do we have to do major compaction to fix it? We did not do 'nodetool
compact', just did repair regularly, which triggers minor compaction.
Thanks,
Daning
On 10/26/2011 03:23 AM, Sylvain Lebresne wrote:
The estimate for t
On Wed, Oct 26, 2011 at 3:50 PM, Ramesh Natarajan wrote:
> I did some more analysis and I think the compaction for this CF stopped after
> we did a update column family to increase the key cache. Other CF compactions
> were going on without any issues.
> I did another update column family to the
I did some more analysis and I think the compaction for this CF stopped after
we did a update column family to increase the key cache. Other CF compactions
were going on without any issues.
I did another update column family to the same CF with same values as before
and the compaction started ag
Looks like compaction for this column family stopped after some time.
The last message for this column family in the system.log is
INFO [MigrationStage:1] 2011-10-25 16:57:00,385 Migration.java (line
119) Applying migration 43f106c0-ff54-11e0--68877f281daf Update
column family to
org.apache.c
The estimate for the number of keys is computed by summing the key
estimate for each sstable of the CF. For each sstable, the estimate
should be fairly good. However, that's when we sum all the sstable estimates
that we can loose potentially a lot of precision if there is a lot of rows that
have pa
I have a cluster of 8 nodes all running 1.0. The stats shown on the 1st node
on one of the CFs for the number of keys is much larger than expected. The
first node shows the key count estimate to be 9.2M whereas the rest report
~650K on each node. The 650K is in the correct neighborhood of the numbe
