And extremely useful/important in the field not being a strict requirement immediately upgrading sstables, especially for not closely monitored environments, e.g. unattended deployments like development machines or even customer on-prem installations etc.
Cassandra's data backwards compatibility is one of the best I have seen. Thanks a lot for that! T. -----Original Message----- From: J. D. Jordan [mailto:jeremiah.jor...@gmail.com] Sent: Freitag, 13. Oktober 2017 13:13 To: dev@cassandra.apache.org Subject: Re: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19? 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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK >> KKKKCB•È [Å“Ã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�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KKKCB�� [��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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > KCB•È [œÝ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
