【问题标题】:Cassandra rebuild getting halt卡桑德拉重建停止
【发布时间】:2018-02-09 14:01:04
【问题描述】:

我有一个 cassandra 集群,在 1 个 DC1 中有 18 个 prod 节点,在 DC2 数据中心有 12 个备份节点,几天前所有备份节点都关闭并超过 gc_grace 期。现在我正在尝试启动所有备份节点,因此已从备份节点中删除所有数据并尝试重建,但它因 FileNotFoundException 停止:。

重建命令是:nohup nodetool rebuild DC1 &

(DC1 是产品数据中心)

Error in nohup.out file :
   Error while rebuilding node: Stream failed
-- StackTrace --
java.lang.RuntimeException: Error while rebuilding node: Stream failed
        at org.apache.cassandra.service.StorageService.rebuild(StorageService.java:1076)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

system.log 中的错误:

Caused by: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.io.FileNotFoundException: /data1/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-tmp-ka-62-Data.db (No such file or directory)
    at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:299) ~[guava-16.0.jar:na]
    at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:286) ~[guava-16.0.jar:na]
    at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116) ~[guava-16.0.jar:na]
    at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:372) ~[apache-cassandra-2.1.16.jar:2.1.16]
    ... 12 common frames omitted
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: /data1/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-tmp-ka-62-Data.db (No such file or directory)
        at org.apache.cassandra.io.util.SequentialWriter.<init>(SequentialWriter.java:82) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.io.compress.CompressedSequentialWriter.<init>(CompressedSequentialWriter.java:67) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.io.util.SequentialWriter.open(SequentialWriter.java:124) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.io.sstable.SSTableWriter.<init>(SSTableWriter.java:130) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.db.Memtable$FlushRunnable.createFlushWriter(Memtable.java:414) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.db.Memtable$FlushRunnable.writeSortedContents(Memtable.java:351) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.db.Memtable$FlushRunnable.runMayThrow(Memtable.java:335) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297) ~[guava-16.0.jar:na]
        at org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1134) ~[apache-cassandra-2.1.16.jar:2.1.16]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) ~[na:1.7.0_79]
        at java.util.concurrent.FutureTask.run(FutureTask.java:262) ~[na:1.7.0_79]
        ... 5 common frames omitted
Caused by: java.io.FileNotFoundException: /data1/cassandra/data/system/compactions_in_progress-55080ab05d9c388690a4acb25fe1f77b/system-compactions_in_progress-tmp-ka-62-Data.db (No such file or directory)

【问题讨论】:

    标签: cassandra rebuild


    【解决方案1】:

    您的问题不是 FileNotFound 异常。这是您正在流式传输系统表的事实。系统表将在节点启动时在本地创建。除系统表数据外,所有数据都应流式传输。 /data1/cassandra/data/system/

    您使用的是哪个 Cassandra 版本?

    如果您没有更改任何迫使 Cassandra 流式传输系统表的内容,我会说这是一个错误。

    【讨论】:

    • 我运行了“nohup nodetool rebuild DC1”并且没有提到任何 Keysapce。我使用的是 Apache Cassandra-2.1.16
    • 它与直接“nodetool 重建”的错误无关。在重建期间,每个键空间都会被拉过来,并且由于持续的压缩存在问题。
    【解决方案2】:

    当您在 DC2 中触发重建时,DC1 中正在进行压缩。您可以在 DC1 的所有节点中发出以下命令以查看正在进行的压缩

    nodetool 压缩统计

    作为压缩的一部分,sstable 将被合并在一起,一旦合并完成,tmp "compaction_in_progress" 表将消失。因此,这些临时表的流式传输在从 DC1 到 DC2 的过程中会丢失,并导致流式传输失败。

    这些压缩也可能由 DC1 中启动的“nodetool repair”触发。因此,如果正在进行维修,请等待维修完成,以避免出现这种情况。

    由于 DC1 有 18 个节点,我相信集群的存储大小是巨大的。解决这种情况的一种更简洁的方法是在重建期间暂停压缩并一次重建一个键空间。所以与其用

    重建整个集群

    nohup nodetool 重建 DC1 &

    1. 在 DC1 中发出以下命令

      nodetool disableautocompaction keyspace-name1

    2. 然后在 DC2 中重建该密钥空间,一次一个节点

      nohup nodetool 重建 keyspace-name1 DC1 &

    3. 一旦在 DC2 中的所有节点中为该键空间完成重建

      nodetool enableautocompaction keyspace-name1

    对所有键空间重复上述两个步骤,直到完成。您可以跳过系统表,例如“system”,它是该节点的本地表,并在您启动该节点时自动重建(即使数据目录为空)。

    如果有太多的应用程序键空间需要处理,它就会变成一点点手动工作。

    【讨论】:

    • 感谢您的清晰解释。但似乎“nodetool rebuild keyspace-name1 DC1”在我当前的 2.1.16 版本中不起作用。我停止了修复和压实,它起作用了!
    • 很高兴知道它有效。记得接受/支持答案。
    猜你喜欢
    • 2016-06-10
    • 1970-01-01
    • 2015-03-19
    • 2015-10-19
    • 2015-03-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多