Re: [EXTERNAL] Re: Rolling back Cassandra upgrades (tarball)

2018-10-01 Thread Jeff Jirsa
sstable version alone isn’t sufficient - there can be other surprises that will break the lower version (commitlog format change, new types or concepts like UDTs that may appear in the schema, etc) I think 3.11 to 3.0 still works but I’m not certain of it personally -- Jeff Jirsa > On Oct

Re: [EXTERNAL] Re: Rolling back Cassandra upgrades (tarball)

2018-10-01 Thread Christophe Schmitz
Adding to the thread: - SSTable format is identical between 3.0.x and 3..11.x, so your SSTable files are compatible, in this case. BTW an easy way to check that is to look at the SSTables filename convention; first letters ('mc' in this case) indicate the SSTable storage format

RE: [EXTERNAL] Re: Rolling back Cassandra upgrades (tarball)

2018-10-01 Thread Durity, Sean R
Version choices aside, I am an advocate for forward-only (in most cases). Here is my reasoning, so that you can evaluate for your situation: - upgrades are done while the application is up and live and writing data (no app downtime) - the upgrade usually includes a change to the sstable version