database - sstableLoader 的意外行为

Question

我在两台不同的机器上工作，它们都有不同的硬盘存储和不同的 cassandra 版本。

机器 1SSD硬盘，Cassandra 2.1.13

机器 2HDD硬盘，Cassandra 2.1.3

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

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

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

1. 16:22:53.956 [main] 调试 o.a.c.io.sstable.SSTableReader - 无法反序列化 SSTable 摘要文件./data/data/sstableloadertest/typestest-8e68e811f56511e59d60297061e28552/sstableloadertest-typestest-ka-57-Summary.db:无法反序列化 SSTable Summary 组件，因为DiskAccessMode 已更改!

而且它还删除了 sstable 的 *summary.db 组件。

起初我以为这是由于不同的 cassandra 版本而发生的，但我错了。

谁能告诉我为什么会这样？

Answer 1

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

默认的磁盘访问模式是自动的，它是根据它是 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