3

I'm working on two different machines and both have different hard disk storage and different cassandra version.

machine 1 SSD hard disk, Cassandra 2.1.13

machine 2 HDD hard disk, Cassandra 2.1.3

Now I transferred data of one CF from machine 2 to machine 1 using SSTableLoader utility. Till this step it was working fine and data were also transferred successfully.

But By mistake I truncated the data on machine 2 for the same CF. In order to recover back the data I used the same concept. I tried to transfer the data from machine 1 to machine 2.

And meanwhile I found some strange logs

  1. 16:22:53.956 [main] DEBUG o.a.c.io.sstable.SSTableReader - Cannot deserialize SSTable Summary File ./data/data/sstableloadertest/typestest-8e68e811f56511e59d60297061e28552/sstableloadertest-typestest-ka-57-Summary.db: Cannot deserialize SSTable Summary component because the DiskAccessMode was changed!

And it also deleted the *summary.db component of sstable.

First I thought It happened due to different cassandra version But I was wrong.

Anyone can tell me why is this happening ?

Anonymous
  • 181
  • 11

1 Answers1

1

The deleted summary file should be fine. Might be worth just deleting it yourself and restarting server. The summary file just stores indexes to the partitions and can be rebuilt on startup.

The default disk access mode is auto which is set based on if its a 32bit or 64bit architecture 1[2]. So likely your first or second system is using a 32bit version of jdk and other is not. Check in logs, there should be a line like 

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

If machine2 is running 64bit and machine1 was 32bit jvm then just set the disk_access_mode property in cassandra.yaml to standard. If machine2 is running 32bit jvm and machine1 was 64bit, upgrade jvm on machine2.

This will likely cause issues with all your other summary files set for other mode though. So ultimately it should work just letting it get rebuilt.

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

Chris Lohfink
  • 16,150
  • 1
  • 29
  • 38
  • I think you are right I'll check it tomorrow and will update you. Thanks for your reply. – Anonymous Mar 29 '16 at 12:55
  • But my both machines are 64 architecture not sure about version of JDK – Anonymous Mar 29 '16 at 12:58
  • 1
    edited with workaround, can set disk_access_mode in machine2 to match machine1 or upgrade jvm. – Chris Lohfink Mar 29 '16 at 13:02
  • I'll accept your answer after checking it. Thank you very much. – Anonymous Mar 29 '16 at 13:07
  • I checked the system.log for both machine and I found they are using same architecture.
    **machine 1 system.log** `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` Can you please explain the situation ?     – Anonymous Mar 30 '16 at 04:25
  • Just to reiterate above - can ignore all this since the summary is rebuilt on startup, but im curious as well. Can you open any Summary.db from each machine1 and machine2: `strings blarg-Summary.db` and see if its which is listed as "mmap" or "standard"? Maybe theres a jvm bug between update 20 or 66 that broke the arch detection. Using jconsole or https://github.com/aragozin/jvm-tools and get values of the System properties? `java.lang:type=Runtime` `SystemProperties`. ie `java -jar sjk.jar mx -mg -s 127.0.0.1:7199 -b java.lang:type=Runtime -f SystemProperties` – Chris Lohfink Mar 30 '16 at 05:07
  • Both machines Summary file has `mmap` `mmap` . – Anonymous Mar 30 '16 at 06:16
  • Can you tell me one thing Why SSTableLoader does remove `summary.db` file always ? – Anonymous Mar 30 '16 at 06:57
  • if the summary file doesnt match the indexing used by the reader it deletes it because it wont use it. The summary file isnt really needed, it just speeds up start time since it so it doesnt have to rebuild it. can you `java -version` on whatever system or wherever your running sstable loader from? Do you have multiple jdks installed on it? – Chris Lohfink Mar 30 '16 at 14:47
  • without summary file you can't truncate the table – Anonymous Mar 31 '16 at 03:48
  • I created two instance of cassandra on machine 2 itself. and tried to load data of one cassandra instance to another instance and it still says `Cannot deserialize SSTable Summary File /home/barala/Downloads/Cassandra/apache-cassandra-2.1.3.2/data/data/sstableloadertest/typestest-f36ad9d0f4a711e5807e55bc51b0510e/sstableloadertest-typestest-ka-2287-Summary.db: Cannot deserialize SSTable Summary component because the DiskAccessMode was changed! 11:52:10.041 [main] DEBUG o.apache.cassandra.io.util.FileUtils - Deleting sstableloadertest-typestest-ka-2287-Summary.db` – Anonymous Mar 31 '16 at 03:55
  • Can open a https://issues.apache.org/jira/browse/CASSANDRA to get it looked at more, but its something you can ignore – Chris Lohfink Mar 31 '16 at 14:44