Generally speaking, don't run mixed versions longer than you have to, and don't upgrade that way.
Why? * We don't support it. * We don't even test it. * If you run into trouble and ask for help, the first thing people will tell you is to get all nodes on the same version. Anyone that's doing so that didn't specifically read the source and test it out for themselves only got lucky in that they didn't hit any issues. If you do it, and hit issues, be prepared to get very familiar with the C* source as you're on your own. Be smart and go the supported, well traveled route. You'll need to do it when upgrading majors *anyways*, so you might as well figure out the right way of doing it *today* and follow the same stable method every time you upgrade. On Wed, Jun 24, 2020 at 8:36 AM Jai Bheemsen Rao Dhanwada < jaibheem...@gmail.com> wrote: > Thank you all for the suggestions. > > I am not trying to scale up the cluster for capacity but for the upgrade > process instead of in place upgrade I am planning to add nodes with 3.11.6 > and then decommission the nodes with 3.11.3. > > On Wednesday, June 24, 2020, Durity, Sean R <sean_r_dur...@homedepot.com> > wrote: > >> Streaming operations (repair/bootstrap) with different file versions is >> usually a problem. Running a mixed version cluster is fine – for the time >> you are doing the upgrade. I would not stay on mixed versions for any >> longer than that. It takes more time, but I separate out the admin tasks so >> that I can reason what should happen. I would either scale up or upgrade >> (depending on which is more urgent), then do the other. >> >> >> >> >> >> Sean Durity >> >> >> >> *From:* manish khandelwal <manishkhandelwa...@gmail.com> >> *Sent:* Wednesday, June 24, 2020 5:52 AM >> *To:* user@cassandra.apache.org >> *Subject:* [EXTERNAL] Re: Cassandra upgrade from 3.11.3 -> 3.11.6 >> >> >> >> Rightly said by Surbhi, it is not good to scale with mixed versions as >> debugging issues will be very difficult. >> >> Better to upgrade first and then scale. >> >> >> >> Regards >> >> >> >> On Wed, Jun 24, 2020 at 11:20 AM Surbhi Gupta <surbhi.gupt...@gmail.com> >> wrote: >> >> In case of any issue, it gets very difficult to debug when we have >> multiple versions. >> >> >> >> On Tue, 23 Jun 2020 at 22:23, Jürgen Albersdorfer < >> jalbersdor...@gmail.com> wrote: >> >> Hi, I would say „It depends“ - as it always does. I have had a 21 Node >> Cluster running in Production in one DC with versions ranging from 3.11.1 >> to 3.11.6 without having had any single issue for over a year. I just >> upgraded all nodes to 3.11.6 for the sake of consistency. >> >> Von meinem iPhone gesendet >> >> >> >> Am 24.06.2020 um 02:56 schrieb Surbhi Gupta <surbhi.gupt...@gmail.com>: >> >> >> >> >> >> Hi , >> >> >> >> We have recently upgraded from 3.11.0 to 3.11.5 . There is a sstable >> format change from 3.11.4 . >> >> We also had to expand the cluster and we also discussed about expansion >> first and than upgrade. But finally we upgraded and than expanded. >> >> As per our experience what I could tell you is, it is not advisable to >> add new nodes on higher version. >> >> There are many bugs which got fixed from 3.11.3 to 3.11.6. >> >> >> >> Thanks >> >> Surbhi >> >> >> >> On Tue, Jun 23, 2020 at 5:04 PM Jai Bheemsen Rao Dhanwada < >> jaibheem...@gmail.com> wrote: >> >> Hello, >> >> >> >> I am trying to upgrade from 3.11.3 to 3.11.6. >> >> Can I add new nodes with the 3.11.6 version to the cluster running with >> 3.11.3? >> >> Also, I see the SSTable format changed from mc-* to md-*, does this cause >> any issues? >> >> >> >> >> ------------------------------ >> >> The information in this Internet Email is confidential and may be legally >> privileged. It is intended solely for the addressee. Access to this Email >> by anyone else is unauthorized. If you are not the intended recipient, any >> disclosure, copying, distribution or any action taken or omitted to be >> taken in reliance on it, is prohibited and may be unlawful. When addressed >> to our clients any opinions or advice contained in this Email are subject >> to the terms and conditions expressed in any applicable governing The Home >> Depot terms of business or client engagement letter. The Home Depot >> disclaims all responsibility and liability for the accuracy and content of >> this attachment and for any damages or losses arising from any >> inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other >> items of a destructive nature, which may be contained in this attachment >> and shall not be liable for direct, indirect, consequential or special >> damages in connection with this e-mail message or its attachment. >> >
