Marc/Dimitry/Jon - greatly appreciate your feedback. I will look into the version part that you suggested. The reason to go direct to 3.x is to take a bi leap and reduce overall effort to upgrade a large cluster (development included).
I have these questions from my original post. Appreciate if you could shed some light and point me in the right direction. 1) How do deal with decommissioning a 2.1.9 node in a partially upgraded cluster? 2) How to bootstrap a 3.x node to a partially upgraded cluster? 3) Is there an alternative approach to the upgrade large clusters. i.e instead of going through nodetool upgradesstables on each node in rolling fashion On Sat, Dec 1, 2018 at 1:03 PM Jonathan Haddad <j...@jonhaddad.com> wrote: > Dmitry is right. Generally speaking always go with the latest bug fix > release. > > On Sat, Dec 1, 2018 at 10:14 AM Dmitry Saprykin <saprykin.dmi...@gmail.com> > wrote: > >> See more here >> >> https://issues.apache.org/jira/plugins/servlet/mobile#issue/CASSANDRA-13004 >> >> On Sat, Dec 1, 2018 at 1:02 PM Dmitry Saprykin <saprykin.dmi...@gmail.com> >> wrote: >> >>> Even more, 3.0.9 is a terrible target choice by itself. It has a nasty >>> bug corrupting sstables on alter. >>> >>> On Sat, Dec 1, 2018 at 11:55 AM Marc Selwan <marc.sel...@datastax.com> >>> wrote: >>> >>>> Hi Shravan, >>>> >>>> Did you upgrade Apache Cassandra 2.1.9 to the latest patch release >>>> before doing the major upgrade? It's generally favorable to go to the >>>> latest patch release as often times they include fixes that smooth over the >>>> upgrade process. There are hundreds of bug fixes between 2.1.9 and 2.1.20 >>>> (current version) >>>> >>>> Best, >>>> Marc >>>> >>>> On Fri, Nov 30, 2018 at 3:13 PM Shravan R <skr...@gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am planning to upgrade Apache Cassandra 2.1.9 to Apache >>>>> Cassandra-3.0.9. I came up with the version based on [1]. I followed >>>>> upgrade steps as in [2]. I was testing the same in the lab and encountered >>>>> issues (streaming just fails and hangs for ever) with bootstrapping a >>>>> 3.0.9 >>>>> node on a partially upgraded cluster. [50% of nodes on 2.1.9 and 50% on >>>>> 3.0.9]. The production cluster that I am supporting is pretty large and I >>>>> am anticipating to end up in a situation like this (Hope not) and would >>>>> like to be prepared. >>>>> >>>>> 1) How do deal with decommissioning a 2.1.9 node in a partially >>>>> upgraded cluster? >>>>> 2) How to bootstrap a 3.x node to a partially upgraded cluster? >>>>> 3) Is there an alternative approach to the upgrade large clusters. i.e >>>>> instead of going through nodetool upgradesstables on each node in rolling >>>>> fashion >>>>> >>>>> >>>>> As per [1] the general restriction is to avoid decommissioning or >>>>> adding nodes but in reality there can be failures or maintenance that >>>>> warrants us to do so. >>>>> >>>>> >>>>> Please point me in the right direction. >>>>> >>>>> >>>>> Thanks, >>>>> Shravan >>>>> >>>>> >>>>> [1] >>>>> https://docs.datastax.com/en/upgrade/doc/upgrade/datastax_enterprise/upgdDSE50.html#upgdDSE50__cstar-version-change >>>>> >>>>> [2] >>>>> https://myopsblog.wordpress.com/2017/12/04/upgrade-cassandra-cluster-from-2-x-to-3-x/ >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__myopsblog.wordpress.com_2017_12_04_upgrade-2Dcassandra-2Dcluster-2Dfrom-2D2-2Dx-2Dto-2D3-2Dx_&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=E6NVfMr2TIhW42QMfARTvsfCLtdF-oEA3KfAQRfVZdk&m=zbxL9Z9UjZMSVoHeue5w2ch4V1n65VR39w0_ysPWhBc&s=Ef6f6CfzIk0DBt3xD3fBmBhsfU8Yc2lv7YnIgiTWLMg&e=> >>>>> >>>>> -- >>>> Marc Selwan | DataStax | Product Management | (925) 413-7079 >>>> >>>> >>>> -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade >
