There isn't any Rollback in real time systems. It's better to test upgrade sstables and binary on one node. Then
- if it was OK, upgrade binary on all nodes then run upgrade sstables one server at a time. OR - If it was OK, upgrade servers (binary+sstables) one by one. *-------------------------------------------------------* *VafaTech <http://www.vafatech.com> : A Total Solution for Data Gathering & Analysis* *-------------------------------------------------------* On Wed, Mar 4, 2020 at 7:38 AM manish khandelwal < manishkhandelwa...@gmail.com> wrote: > Should upgradesstables not be run after every node is upgraded? If we need > to rollback then we will not be able to downgrade sstables to older > version. > > Regards > Manish > > On Tue, Mar 3, 2020 at 11:26 PM Hossein Ghiyasi Mehr < > ghiyasim...@gmail.com> wrote: > >> It's more safe to upgrade one node before upgrading another node to avoid >> down time. >> After upgrading binary and package, run upgradesstables on candidate node >> then do it on all cluster nodes one by one. >> *-------------------------------------------------------* >> *VafaTech <http://www.vafatech.com> : A Total Solution for Data Gathering >> & Analysis* >> *-------------------------------------------------------* >> >> >> On Thu, Feb 13, 2020 at 9:27 PM Sergio <lapostadiser...@gmail.com> wrote: >> >>> >>> - Verify that nodetool upgradesstables has completed successfully on >>> all nodes from any previous upgrade >>> - Turn off repairs and any other streaming operations (add/remove >>> nodes) >>> - Nodetool drain on the node that needs to be stopped (seeds first, >>> preferably) >>> - Stop an un-upgraded node (seeds first, preferably) >>> - Install new binaries and configs on the down node >>> - Restart that node and make sure it comes up clean (it will >>> function normally in the cluster – even with mixed versions) >>> - nodetool statusbinary to verify if it is up and running >>> - Repeat for all nodes >>> - Once the binary upgrade has been performed in all the nodes: Run >>> upgradesstables on each node (as many at a time as your load will allow). >>> Minor upgrades usually don’t require this step (only if the sstable >>> format >>> has changed), but it is good to check. >>> - NOTE: in most cases applications can keep running and will not >>> notice much impact – unless the cluster is overloaded and a single node >>> down causes impact. >>> >>> >>> >>> I added 2 points to the list to clarify. >>> >>> Should we add this in a FAQ in the cassandra doc or in the awesome >>> cassandra https://cassandra.link/awesome/ >>> >>> Thanks, >>> >>> Sergio >>> >>> >>> Il giorno mer 12 feb 2020 alle ore 10:58 Durity, Sean R < >>> sean_r_dur...@homedepot.com> ha scritto: >>> >>>> Check the readme.txt for any upgrade notes, but the basic procedure is >>>> to: >>>> >>>> - Verify that nodetool upgradesstables has completed successfully >>>> on all nodes from any previous upgrade >>>> - Turn off repairs and any other streaming operations (add/remove >>>> nodes) >>>> - Stop an un-upgraded node (seeds first, preferably) >>>> - Install new binaries and configs on the down node >>>> - Restart that node and make sure it comes up clean (it will >>>> function normally in the cluster – even with mixed versions) >>>> - Repeat for all nodes >>>> - Run upgradesstables on each node (as many at a time as your load >>>> will allow). Minor upgrades usually don’t require this step (only if the >>>> sstable format has changed), but it is good to check. >>>> - NOTE: in most cases applications can keep running and will not >>>> notice much impact – unless the cluster is overloaded and a single node >>>> down causes impact. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Sean Durity – Staff Systems Engineer, Cassandra >>>> >>>> >>>> >>>> *From:* Sergio <lapostadiser...@gmail.com> >>>> *Sent:* Wednesday, February 12, 2020 11:36 AM >>>> *To:* user@cassandra.apache.org >>>> *Subject:* [EXTERNAL] Cassandra 3.11.X upgrades >>>> >>>> >>>> >>>> Hi guys! >>>> >>>> How do you usually upgrade your cluster for minor version upgrades? >>>> >>>> I tried to add a node with 3.11.5 version to a test cluster with 3.11.4 >>>> nodes. >>>> >>>> Is there any restriction? >>>> >>>> Best, >>>> >>>> Sergio >>>> >>>> ------------------------------ >>>> >>>> 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. >>>> >>>
