从cassandra手动删除SSTable后的AssertionError

时间:2016-11-21 07:27:07

标签: cassandra datastax cassandra-2.0

由于空间限制,我从cassandra手动删除了一些SSTable。之后我每次执行nodetool cfstats KEYSPACE.COLUMNFAMILY时都会出现以下错误。为什么要找出我删除的SSTable并给出AssertionError?

error: /mnt/cassandra2112/data/data/KEYSPACE/COLUMNFAMILY-3ef09530a70811e6ae4f97f9576f9b43/KEYSPACE-COLUMNFAMILY-ka-14-Data.db
    -- StackTrace --
    java.lang.AssertionError: /mnt/cassandra/data/data/KEYSPACE/COLUMNFAMILY-3ef09530a70811e6ae4f97f9576f9b43/KEYSPACE-COLUMNFAMILY-ka-14-Data.db
        at org.apache.cassandra.io.sstable.SSTableReader.getApproximateKeyCount(SSTableReader.java:268)
        at org.apache.cassandra.metrics.ColumnFamilyMetrics$9.value(ColumnFamilyMetrics.java:296)
        at org.apache.cassandra.metrics.ColumnFamilyMetrics$9.value(ColumnFamilyMetrics.java:290)
        at com.yammer.metrics.reporting.JmxReporter$Gauge.getValue(JmxReporter.java:63)
        at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
        at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
        at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
        at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
        at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
        at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
        at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
        at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
        at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
        at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1420)
        at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
        at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
        at sun.rmi.transport.Transport$2.run(Transport.java:202)
        at sun.rmi.transport.Transport$2.run(Transport.java:199)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:198)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:567)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.access$400(TCPTransport.java:619)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:684)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$1.run(TCPTransport.java:681)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:681)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)

2 个答案:

答案 0 :(得分:1)

你做不到。

  

Cassandra在写入路径的几个阶段处理数据,从立即记录写入开始到结束写入数据到磁盘:

     
      
  • 在提交日志中记录数据
  •   
  • 将数据写入记忆
  •   
  • 从记忆中刷新数据
  •   
  • 在SSTables中的磁盘上存储数据
  •   

每个表都维护着Memtables和SSTable。 SSTables是不可变的,在刷新memtable后不再写入。因此,分区通常存储在多个SSTable文件中。

这意味着您需要SSTable来从存储中读取数据。

有关更多信息: How is data written in cassandra?

答案 1 :(得分:0)

如果你去你兄弟的车并拆下一个轮胎怎么办?他不打算在高速公路上跑步的事实并不意味着他不会注意到轮胎丢失了。

简短回答

不要手动删除SSTable。

Long anwer

Cassandra表可以在磁盘上保留为多个 SSTables。他们实际 您的数据,是实时数据,或已删除的数据(是的,他们仍然您的数据并且将被收取费用直到压实发生,并且它们被称为墓碑!)

您可能删除了“实时”SSTable。没有C *抱怨的唯一能够删除的是快照。当你这样做时,你需要使用right tool

如果您的空间不足,则需要向群集添加一个节点。

如果你没想到空间不足,那就该回去重新设计你的数据模型了。

HTH。