Old restrictions that have been lifted Jeff :) Ever since 2.0 we have supported streaming old sstables, see here for the 2.0 ticket: https://issues.apache.org/jira/browse/CASSANDRA-5772
That was broken in early 3.0, but had since been fixed by the ticket Marcus linked https://issues.apache.org/jira/browse/CASSANDRA-10990 So it should be fine in all latest 3.x versions. -Jeremiah > On Oct 13, 2017, at 3:34 AM, Steinmaurer, Thomas > <thomas.steinmau...@dynatrace.com> wrote: > > Same here, regarding sincere question to know the corner cases from 2.1 => > 3.11.1, but Marcus already provided the JIRA ticket. > > Thanks! > > > -----Original Message----- > From: Per Otterström [mailto:per.otterst...@ericsson.com] > Sent: Freitag, 13. Oktober 2017 09:01 > To: dev@cassandra.apache.org > Subject: RE: Do it need to run 'nodetool upgradesstables' when updating from > 2.0.9 to 2.1.19? > > Hepp! > > Just to be clear, I'm not claiming this to be the case, it is a sincere > question. My team is planning an upgrade from 2.2 to 3.0 which is why I'm > asking. Some initial tests indicate that repairs etc work well before running > upgradesstables (assuming all nodes are upgraded to 3.0). But if there are > known corner cases I'd be interested to know. > > We need to support reading old sstables in order to support rolling upgrades. > This seem to be a general assumption that people agree on. I'm not sure there > is a clear agreement on the streaming part. Would it make sense to clarify > this in documentation? > > /pelle > > -----Original Message----- > From: Jeff Jirsa [mailto:jji...@gmail.com] > Sent: den 13 oktober 2017 08:09 > To: dev@cassandra.apache.org > Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from > 2.0.9 to 2.1.19? > > Two people say I’m wrong, I’ll believe it - must be imagining > restrictions that don’t exist. > > -- > Jeff Jirsa > > >> On Oct 12, 2017, at 10:55 PM, Per Otterström <per.otterst...@ericsson.com> >> wrote: >> >> Hi! >> >> This was news to me. I had the impression that we are maintaining backwards >> compatibility for streaming non-upgraded sstables. Is that not the case? >> >> However, I believe it is a good idea to run upgradesstables at some point >> _before_ upgrading Cassandra next time to make sure there are no old >> sstables around before you take the next step. >> >> /pelle >> >> -----Original Message----- >> From: Jeff Jirsa [mailto:jji...@gmail.com] >> Sent: den 12 oktober 2017 23:11 >> To: Cassandra DEV <dev@cassandra.apache.org> >> Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from >> 2.0.9 to 2.1.19? >> >> You won't notice any issues (all versions of cassandra are backwards >> compatible at least 1 version), and sstables will be slowly migrated to the >> new format as you compact, but you should still run it (upgradesstables) >> explicitly because when it comes time to run >> repair/boostrap/decommission/etc, you'll need all sstables on the >> same/current format. >> >> >> >> On Thu, Oct 12, 2017 at 1:59 PM, Li, Guangxing <guangxing...@pearson.com> >> wrote: >> >>> Hi, >>> >>> I recently upgraded my test cluster from C* 2.0.9 to 2.1.19 and I did >>> not run 'nodetool upgradesstables' at all. Per my confirmation >>> afterwards, everything is fine. But according to documentation at >>> https://support.datastax.com/hc/en-us/articles/208040036- >>> Nodetool-upgradesstables-FAQ. >>> I need to do that. >>> So can someone tell me if I must do 'nodetool upgradesstables' after >>> upgrading each node from 2.0.9 to 2.1.19? >>> >>> Thanks. >>> >>> George. >>> >> B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [Å“ÃXœØÜšXâ„¢KK[XZ[ > ˆ]‹][Å“ÃXœØÜšXâ„¢PØ\ÜØ[â„¢ ËœKËœ\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[â„¢ ËK[XZ[ > ˆ]‹Z[ Ø\ÜØ[â„¢ ËœKËœ\XÚK›Ü™ÃBÆ’B > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[ > �]�][��X��ܚX�P�\��[� �K�\X�K�ܙ�B��܈Y][Û˜[��[X[� �K[XZ[ > �]�Z[ �\��[� �K�\X�K�ܙ�B�B > The contents of this e-mail are intended for the named addressee only. It > contains information that may be confidential. Unless you are the named > addressee or an authorized designee, you may not copy or use it, or disclose > it to anyone else. If you received it in error please notify us immediately > and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) > is a company registered in Linz whose registered office is at 4040 Linz, > Austria, Freistädterstraße 313 > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PØ\ÜØ[™ ˜K˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ Ø\ÜØ[™ ˜K˜\XÚK›Ü™ÃBƒB
