Cassandra Startup Error 1.2.6 on Linux x86_64

问题:

Trying to install cassandra on linux from latest stable release - http://cassandra.apache.org/download/ - 1.2.6

I have modified the cassndra.yaml to point to a custom directory instead of /var since I do not have write access on /var

I am seeing this error on startup. Not able to find any answers on google yet since the release seems relatively new. Just posting it here in case its a silly mistake on my side.

Same distribution file worked fine on my macos x86_64 machine.

 INFO 19:24:35,513 Not using multi-threaded compaction
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:322)
    at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:229)
    at org.xerial.snappy.Snappy.<clinit>(Snappy.java:48)
    at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)
    at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)
    at org.apache.cassandra.io.compress.SnappyCompressor.<clinit>(SnappyCompressor.java:37)
    at org.apache.cassandra.config.CFMetaData.<clinit>(CFMetaData.java:82)
    at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:81)
    at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:468)
    at org.apache.cassandra.config.DatabaseDescriptor.<clinit>(DatabaseDescriptor.java:123)
    at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:211)
    at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:441)
    at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:484)
Caused by: java.lang.UnsatisfiedLinkError: /tmp/snappy-1.0.5-libsnappyjava.so: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /tmp/snappy-1.0.5-libsnappyjava.so)
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary1(Unknown Source)
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)
    at java.lang.ClassLoader.loadLibrary(Unknown Source)
    at java.lang.Runtime.load0(Unknown Source)
    at java.lang.System.load(Unknown Source)
    at org.xerial.snappy.SnappyNativeLoader.load(SnappyNativeLoader.java:39)
    ... 17 more

Please suggest what could be the issue. I will also add any more findings to this page as I discover anything new.

Looked at this so thread - cassandra 1.2 fails to init snappy in freebsd

However still see issue.

I have tried setting

internode_compression: none

However still see the same error in logs.

回答1:

It looks like you're (a) running on a system with an incompatible glibc for snappy 1.0.5 and (b) upgraded from an earlier version that worked.

If you start Cassandra fresh on a non-Snappy-compatible system, it will detect the problem and skip compression. But when you're upgrading and you have compressed system tables, there's nothing Cassandra can do.

You can downgrade, you can upgrade glibc, or you can downgrade, switch to lz4 and run upgradesstables, and then upgrade again.

Edit: you might also be able to just drop the old 1.0.4 snappy in, instead, and remove 1.0.5.

Edit 2: Is this RHEL 5? Pretty much anything modern should be snappy-1.0.5-compatible.

回答2:

Just in case anyone came across this post with the configuration I have:

• rhel 5
• cassandra 2.0.2

I had a startup problem - version `GLIBCXX_3.4.9' not found

Proposed solution:

1. Compile snappy 1.1.0 (I guess it could've been 1.0.5) on rhel 5.
2. Replace snappy 1.0.5 from the original cassandra 2.0.2 distribution with the version above
3. Restart in sequence (seed first, then other nodes to join)

Bypassed the problem, it seems.

Hope the future cassandra versions will have instructions dealing with variety of OS versions. Theoretically this should work...

INFO 23:49:07,006 Enqueuing flush of Memtable-local@926294408(43/430 serialized/live bytes, 2 ops)
 INFO 23:49:07,006 Writing Memtable-local@926294408(43/430 serialized/live bytes, 2 ops)
 INFO 23:49:07,019 Completed flushing /var/lib/cassandra/data/system/local/system-local-jb-10-Data.db (70 bytes) for commitlog position ReplayPosition(segmentId=1383810511586, position=220516)
 INFO 23:49:07,030 Enqueuing flush of Memtable-local@1880462876(10086/100860 serialized/live bytes, 257 ops)
 INFO 23:49:07,030 Writing Memtable-local@1880462876(10086/100860 serialized/live bytes, 257 ops)
 INFO 23:49:07,042 Completed flushing /var/lib/cassandra/data/system/local/system-local-jb-11-Data.db (5280 bytes) for commitlog position ReplayPosition(segmentId=1383810511586, position=232503)
 INFO 23:49:07,064 Node myeng11.mycompany.com/10.65.0.201 state jump to normal
 INFO 23:49:07,067 Startup completed! Now serving reads.