On Wed, May 16, 2012 at 5:08 PM, Ron Siemens <rsiem...@greatergood.com> wrote: > > I upgraded to 1.0.6 to 1.1.0, and I noticed the effective ownership report > changed. > > I have a 3-node cluster, with evenly divided tokens and RF=2. The node tool > report on 1.0.6 was: > > 33.33% 0 > 33.33% 56713727820156410577229101238628035243 > 33.33% 113427455640312821154458202477256070485 > > Under 1.1.0 it is > > 66.67% 0 > 66.67% 56713727820156410577229101238628035243 > 66.67% 113427455640312821154458202477256070485 > > Does the updated reporting in 1.1.0 include the replicated data and before it > didn't?
Yes. > As long as I'm posting, I'll report other anomalies that I witnessed but > overcame. > > I eventually gave up trying to do a live rolling update because it complained > certain column families didn't exist. Like this: This doesn't appear to be > any CF I am using. > > ERROR [ReadStage:69680] 2012-05-02 01:54:14,995 AbstractCassandraDaemon.java > (line 133) Fatal exception > in thread Thread[ReadStage:69680,5,main] > java.lang.RuntimeException: java.lang.IllegalArgumentException: Unknown CF > 1851 > at > org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1238) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.IllegalArgumentException: Unknown CF 1851 > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:167) > at org.apache.cassandra.db.Table.getColumnFamilyStore(Table.java:160) > at org.apache.cassandra.db.Table.getRow(Table.java:374) > at > org.apache.cassandra.db.SliceByNamesReadCommand.getRow(SliceByNamesReadCommand.java:58) > at > org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:766 > ) > at > org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:1234) > ... 3 more > > I tried repeatedly after various nodetool incantations but never succeeded. > Although I know it -can- work. It worked at least once, but I had to > rollback to 1.0.6 though, because I found 1.1.0 was using the new > SnappyCompression. But my target OS is Solaris, and there's only 3 included > libraries in the jar for SnappyCompression - Solaris not included. So I had > to update all my column family creation code to explicitly set compression to > the previous JavaDeflate default. That new default was annoying. It doesn't ring a bell; For something like this, it would be great to have a ticket with details on your environment, steps to reproduce, the full output of the logs, and where possible, the data. -- Eric Evans Acunu | http://www.acunu.com | @acunu
