A quick question on the same topic, we are upgrading from 3.11.1 to 3.11.6. We had a schema mismatch after upgrading one node. RR did ont fix it and we had to remove that node. have anyone faced this issue ? Also Do we need to do a nodetool drain before running upgrade sstables.
Meena On Wed, Jun 24, 2020 at 8:54 AM Jon Haddad <j...@jonhaddad.com> wrote: > 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. >>> >>
