sstableLoader

时间:2016-03-29 09:15:54

标签: database cassandra disk disk-io

我在两台不同的机器上工作,两者都有不同的硬盘存储空间和不同的cassandra版本。

机器1 SSD硬盘,Cassandra 2.1.13

机器2 硬盘硬盘,Cassandra 2.1.3

现在,我使用 SSTableLoader 实用程序将一个CF的数据从计算机2 传输到计算机1 。直到这一步它工作正常,数据也成功传输。

但是我错误地将机器2 上的数据截断为相同的CF.为了恢复数据,我使用了相同的概念。我尝试将数据从计算机1 传输到计算机2

同时我发现了一些奇怪的日志

  1. 16:22:53.956 [main] DEBUG o.a.c.io.sstable.SSTableReader - 不能 反序列化SSTable摘要文件 ./data/data/sstableloadertest/typestest-8e68e811f56511e59d60297061e28552/sstableloadertest-typestest-ka-57-Summary.db: 无法反序列化SSTable Summary组件,因为 DiskAccessMode已更改!
  2. 它还删除了sstable的* summary.db组件。

    首先我认为这是因为不同的cassandra版本而发生但我错了。

    任何人都可以告诉我为什么会这样?

1 个答案:

答案 0 :(得分:1)

删除的摘要文件应该没问题。可能值得自己删除它并重新启动服务器。 summary file只是将索引存储到分区,并且可以在启动时重建。

默认磁盘访问模式为auto,根据其是32位还是64位架构1 [2]设置。所以你的第一个或第二个系统很可能使用32位版本的jdk而其他系统不是。签入日志,应该有一行像

INFO  [main] 2016-03-16 16:45:11,464 CassandraDaemon.java:424 - JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.8.0_45

如果machine2运行64位且machine1为32位jvm,则只需将cassandra.yaml中的disk_access_mode属性设置为standard。如果machine2运行32位jvm且machine1为64位,则在machine2上升级jvm。

这可能会导致为其他模式设置的所有其他摘要文件出现问题。所以最终它应该只是让它重建。

1 https://github.com/apache/cassandra/blob/8097d390a285c20aa47954750a80d176a826e47b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L313

[2] https://github.com/apache/cassandra/blob/8097d390a285c20aa47954750a80d176a826e47b/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1931