sstableLoader 的意外行为

Posted

技术标签:

【中文标题】sstableLoader 的意外行为【英文标题】:Unexpected behavior of sstableLoader 【发布时间】:2016-07-16 18:14:22 【问题描述】:

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

机器 1 SSD硬盘,Cassandra 2.1.13

机器 2 HDD硬盘,Cassandra 2.1.3

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

但我错误地截断了 ma​​chine 2 上相同 CF 的数据。为了恢复数据,我使用了相同的概念。我尝试将数据从 ma​​chine 1 传输到 ma​​chine 2

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

    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版本不同,但我错了。

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

【问题讨论】:

cassandra.yaml 中的 disk_access_mode 在 machine1 和 machine2 中设置为什么? @ChrisLohfink 两台机器都使用几乎默认的 cassandra.yaml,所以没有这样的属性。 @ChrisLohfink 和两台机器都是x86_64 【参考方案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 运行 32bit jvm 而 machine1 是 64bit,则升级 machine2 上的 jvm。

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

1https://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

【讨论】:

我认为你是对的,我明天会检查并更新你。感谢您的回复。 但是我的两台机器都是 64 架构的,不确定 JDK 的版本 修改了解决方法,可以在 machine2 中设置 disk_access_mode 以匹配 machine1 或升级 jvm。 我会在检查后接受您的回答。非常感谢。 我检查了两台机器的 system.log,发现它们使用相同的架构。 机器 1 系统日志 INFO [main] 2016-03-29 15:56:08,235 CassandraDaemon.java:172 - JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.8.0_20 --------------------------- -------------------------------------------------- ----------machine 2 system.log INFO [main] 2016-01-12 11:40:23,159 CassandraDaemon.java:114 - JVM vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.8.0_66你能解释一下情况吗?

以上是关于sstableLoader 的意外行为的主要内容,如果未能解决你的问题,请参考以下文章

sstableloader 远程批量上传

当集群处于部分升级状态时,我们可以使用 sstableloader 吗?

10-leveldb repair流程及优化方法

10-leveldb repair流程及优化方法

10-leveldb repair流程及优化方法

WindowsLookAndFeel关于按钮着色的意外行为