2) I have the following error in /var/log/cassandra/cassandra.log - cassandra dies after "service cassandra start"
This is Cassandra 2.1.8 running on RHEL 6.6, in a docker container.ERROR 12:16:09 Detected unreadable sstables /data/cassandra_saved_caches/system-schema_keyspaces-b0f2235744583cdb9631c43e59ce3676-KeyCache-b.db,/data/cassandra_saved_caches/system-local-7ad5
ity-5a1ff267ace03f128563cfae6103c65e-KeyCache-b.db,/data/cassandra_saved_caches/system-schema_columnfamilies-45f5b36024bc3f83a3631034ea4fa697-KeyCache-b.db, please check NEWS.txt and ensure
that you have upgraded through all required intermediate versions, running upgradesstables
This is Cassandra 2.1.8 running on RHEL 6.6, in a docker container - single node "cluster".
Fortunately, this is an experimental system, not production (and actually running in a VM that experienced a couple of transient disconnects to its datastore, likely having ill effect on /data.)
I'd really hate to see this happen in production! (But then, in production, I should have some pretty resilient storage for data_file_directories and commitlog_directory.)
Is this a case where sstablescrub might be useful? If so, I've only vague ideas about what arguments to supply for <keyspace> and <column_family>.