Error message example:
ERROR [SSTableBatchOpen:1] XXXX-XX-XX XX:XX:XX,XXX SSTableReader.java:511 - Cannot open /var/lib/cassandra/data/keyspace/tablename-52c55f30e1ac11e697999719b600b4d0/mc-xxx-big; org.apache.cassandra.dht.RandomPartitioner does not match system partitioner org.apache.cassandra.dht.Murmur3Partitioner. Note that the default partitioner starting with Cassandra 1.2 is Murmur3Partitioner, so you will need to edit that to match your old partitioner if upgrading.
What does this ERROR message mean?
This error means that cassandra is trying to load sstables into a cluster that does not match the setting for the partitioner: org.apache.cassandra.dht.Murmur3Partitioner that is set in the cassandra.yaml.
For example sstables being loaded that have been partitioned using a RandomPartitioner and trying to load these sstables into a cluster which is currently using a Murmur3Partitioner partitioner.
Why does this ERROR occur?
This can occur when you are loading sstables from a cluster that was previously using a different partitioner to that being used in the cluster to which the sstables are being loaded. You cannot stream from one partitioner to a different partitioner.
How do you fix this ERROR?
If you are loading data into a new cluster. You can configure the target cluster to use the same partitioner as the source cluster.
However, the recommendation is to use the default Murmur3Partitioner partitioner since it provides faster hashing and improved performance.
In which case you will need to unload the data from the source cluster and then import back into the target cluster, this will strip the Token assignment and allow the data to be rewritten into the different partitioner. For example using cqlsh COPY FROM and COPY TO options.
Depending on the Cassandra release and the size of the tables. You can also explore the dsbulk option tool for faster and more efficient unload/load method. Please refer to the below dsbulk documentation for more details: