【问题标题】:AssertionError after deleting the SSTable manually from cassandra从 cassandra 手动删除 SSTable 后出现 AssertionError
【发布时间】:2017-04-04 12:48:22
【问题描述】:

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

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)

【问题讨论】:

    标签: cassandra datastax cassandra-2.0


    【解决方案1】:

    你不能这样做。

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

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

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

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

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

    【讨论】:

      【解决方案2】:

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


      简答

      不要手动删除 SSTables。


      长回答

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

      您可能删除了“实时”SSTable。唯一可以删除而不会引起 C* 抱怨的是 快照。当你这样做时,你需要使用right tool

      如果您的空间不足,那么是时候向您的集群添加一个节点了。

      如果您没想到会用完空间,那么是时候回去重新设计您的数据模型了。

      HTH。

      【讨论】:

        猜你喜欢
        • 2014-11-11
        • 1970-01-01
        • 1970-01-01
        • 2016-09-29
        • 2015-06-06
        • 2018-09-15
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多