Change Details

Cassandra 3 (currently 3.10 / 3.0.12) has a number of significant improvements, including completely rewritten storage, materialized views, and time-windowed compaction. As part of {T156199}, we are considering a migration strategy that would downsize the current cluster to free up enough hardware nodes that we could setup a secondary cluster, deploy the updated storage module, and migrate use-cases to it incrementally. If we decide on this approach, it would provide a unique opportunity to deploy this new cluster with Cassandra 3, and avoid the high costs associated with an in-place upgrade later. The first step is to research outstanding issues, attempt to identify potential risks to our use-cases, and select a version to begin testing with. (WARNING) WIP; What follows is still evolving... == Cassandra Releases == === 2.2.x === We are currently using 2.2.6 in production (the latest is 2.2.9). The 2.2 series took quite a bit longer to release than was planned; It was held up by ambitious features that took longer to get completed than expected (most notably, [[ https://issues.apache.org/jira/browse/CASSANDRA-8099 | a complete rewrite of storage ]]). At some point, a decision to release with the (stable) features that had accumulated was made, rather than to make users continue to wait. The net result is that the 2.2 series carried fewer new features than previous major releases; It's basically a bridge between 2.1 and 3.x (which is what should have been the next major release). The 2.2 series is set to be EOL with the release of 4.0 (TBD). === 3.0.x === Starting with v3, the Cassandra project moved to a [[ http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html | tick-tock release cycle ]]. Releases are made monthly, even-numbered releases contain new features and bug fixes, odd-numbered releases contain bug fixes only. The idea was to keep trunk as close to releasable at all times, and to get new features (and fixes) out to users for testing more incrementally. Since it was recognized that this might take some time to achieve, the 3.0 release was special-cased to receive all bug-fixes from the 3.x series. The 3.0 series (currently at 3.0.12) is set to be EOL 6 months after 4.0 (TBD). === 3.x (tick-tock releases) === Amongst the various tick-tock versions (currently up to 3.10), there are two of interest for what they introduce. Version 3.2 [[ https://issues.apache.org/jira/browse/CASSANDRA-6696 | introduced a feature that pins one compactor to each data directory ]], and 3.6 which made [[ https://issues.apache.org/jira/browse/CASSANDRA-11206 | row indexing more memory efficient ]], (effectively raising the limit on partition width). === 4.0 === Tick-tock releases have not been popular, so beginning with version 4.0, they are being abandoned. Additionally, after recent changes within the project, sentiment seems to be shifting strongly in the direction of slowing the pace of destabilizing change, and concentrating on code debt and testability. There is no firm release date for 4.0 yet. == Selecting a Version == Prior to the 3.x tick-tock releases, Cassandra was somewhat legendary for needing several minor bugfix releases to a new version before even considering it for production use. Once tick-tock started, things got more complicated, as iterations were as likely to introduce new regressions as they were to solve them. Community consensus seems to be that once you start down the tick-tock path, it's best to ride it through to the end, upgrading to each new odd-numbered release. However, consensus also seems to suggest that this is not common; Most people who choose to run Cassandra 3 in production avoid the tick-tock releases and run 3.0. === 3.0.12 === TODO. === 3.7.3-instaclustr === TODO. === 3.10 === TODO.

Cassandra 3 (currently 3.10 / 3.0.12) has a number of significant improvements, including completely rewritten storage, materialized views, and time-windowed compaction. As part of {T156199}, we are considering a migration strategy that would downsize the current cluster to free up enough hardware nodes that we could setup a secondary cluster, deploy the updated storage module, and migrate use-cases to it incrementally. If we decide on this approach, it would provide a unique opportunity to deploy this new cluster with Cassandra 3, and avoid the high costs associated with an in-place upgrade later. The first step is to research outstanding issues, attempt to identify potential risks to our use-cases, and select a version to begin testing with. (WARNING) WIP; What follows is still evolving... == Cassandra Releases == === 2.2.x === We are currently using 2.2.6 in production (the latest is 2.2.9). The 2.2 series took quite a bit longer to release than was planned; It was held up by ambitious features that took longer to get completed than expected (most notably, [[ https://issues.apache.org/jira/browse/CASSANDRA-8099 | a complete rewrite of storage ]]). At some point, a decision to release with the (stable) features that had accumulated was made, rather than to make users continue to wait. The net result is that the 2.2 series carried fewer new features than previous major releases; It's basically a bridge between 2.1 and 3.x (which is what should have been the next major release). The 2.2 series is set to be EOL with the release of 4.0 (TBD). === 3.0.x === Starting with v3, the Cassandra project moved to a [[ http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html | tick-tock release cycle ]]. Releases are made monthly, even-numbered releases contain new features and bug fixes, odd-numbered releases contain bug fixes only. The idea was to keep trunk as close to releasable at all times, and to get new features (and fixes) out to users for testing more incrementally. Since it was recognized that this might take some time to achieve, the 3.0 release was special-cased to receive all bug-fixes from the 3.x series. The 3.0 series (currently at 3.0.12) is set to be EOL 6 months after 4.0 (TBD). === 3.x (tick-tock releases) === Amongst the various tick-tock versions (currently up to 3.10), there are two of interest for what they introduce. Version 3.2 [[ https://issues.apache.org/jira/browse/CASSANDRA-6696 | introduced a feature that pins one compactor to each data directory ]], and 3.6 which made [[ https://issues.apache.org/jira/browse/CASSANDRA-11206 | row indexing more memory efficient ]], (effectively raising the limit on partition width). === 4.0 === Tick-tock releases have not been popular, so beginning with version 4.0, they are being abandoned. Additionally, after recent changes within the project, sentiment seems to be shifting strongly in the direction of slowing the pace of destabilizing change, and concentrating on code debt and testability. There is no firm release date for 4.0 yet. == Selecting a Version == Prior to the 3.x tick-tock releases, Cassandra was somewhat legendary for needing several minor bugfix releases to a new version before even considering it for production use. Once tick-tock started, things got more complicated, as iterations were as likely to introduce new regressions as they were to solve them. Community consensus seems to be that once you start down the tick-tock path, it's best to ride it through to the end, upgrading to each new odd-numbered release. However, consensus also seems to suggest that this is not common; Most people who choose to run Cassandra 3 in production avoid the tick-tock releases and run 3.0. === 3.0.12 === TODO. === 3.7.3-instaclustr === Most non-trivial users accept a greater degree of ownership over Cassandra; It isn't uncommon to maintain builds from forks where critical bugfixes are backported. [[ https://www.instaclustr.com/ | Instaclustr ]] does this, and has published a fork of 3.7 + [[ https://github.com/instaclustr/cassandra#current-patches-backported | fixes ]]. === 3.10 === TODO.

Cassandra 3 (currently 3.10 / 3.0.12) has a number of significant improvements, including completely rewritten storage, materialized views, and time-windowed compaction. As part of {T156199}, we are considering a migration strategy that would downsize the current cluster to free up enough hardware nodes that we could setup a secondary cluster, deploy the updated storage module, and migrate use-cases to it incrementally. If we decide on this approach, it would provide a unique opportunity to deploy this new cluster with Cassandra 3, and avoid the high costs associated with an in-place upgrade later. The first step is to research outstanding issues, attempt to identify potential risks to our use-cases, and select a version to begin testing with. (WARNING) WIP; What follows is still evolving... == Cassandra Releases == === 2.2.x === We are currently using 2.2.6 in production (the latest is 2.2.9). The 2.2 series took quite a bit longer to release than was planned; It was held up by ambitious features that took longer to get completed than expected (most notably, [[ https://issues.apache.org/jira/browse/CASSANDRA-8099 | a complete rewrite of storage ]]). At some point, a decision to release with the (stable) features that had accumulated was made, rather than to make users continue to wait. The net result is that the 2.2 series carried fewer new features than previous major releases; It's basically a bridge between 2.1 and 3.x (which is what should have been the next major release). The 2.2 series is set to be EOL with the release of 4.0 (TBD). === 3.0.x === Starting with v3, the Cassandra project moved to a [[ http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html | tick-tock release cycle ]]. Releases are made monthly, even-numbered releases contain new features and bug fixes, odd-numbered releases contain bug fixes only. The idea was to keep trunk as close to releasable at all times, and to get new features (and fixes) out to users for testing more incrementally. Since it was recognized that this might take some time to achieve, the 3.0 release was special-cased to receive all bug-fixes from the 3.x series. The 3.0 series (currently at 3.0.12) is set to be EOL 6 months after 4.0 (TBD). === 3.x (tick-tock releases) === Amongst the various tick-tock versions (currently up to 3.10), there are two of interest for what they introduce. Version 3.2 [[ https://issues.apache.org/jira/browse/CASSANDRA-6696 | introduced a feature that pins one compactor to each data directory ]], and 3.6 which made [[ https://issues.apache.org/jira/browse/CASSANDRA-11206 | row indexing more memory efficient ]], (effectively raising the limit on partition width). === 4.0 === Tick-tock releases have not been popular, so beginning with version 4.0, they are being abandoned. Additionally, after recent changes within the project, sentiment seems to be shifting strongly in the direction of slowing the pace of destabilizing change, and concentrating on code debt and testability. There is no firm release date for 4.0 yet. == Selecting a Version == Prior to the 3.x tick-tock releases, Cassandra was somewhat legendary for needing several minor bugfix releases to a new version before even considering it for production use. Once tick-tock started, things got more complicated, as iterations were as likely to introduce new regressions as they were to solve them. Community consensus seems to be that once you start down the tick-tock path, it's best to ride it through to the end, upgrading to each new odd-numbered release. However, consensus also seems to suggest that this is not common; Most people who choose to run Cassandra 3 in production avoid the tick-tock releases and run 3.0. === 3.0.12 === TODO. === 3.7.3-instaclustr === TODOMost non-trivial users accept a greater degree of ownership over Cassandra; It isn't uncommon to maintain builds from forks where critical bugfixes are backported. [[ https://www.instaclustr.com/ | Instaclustr ]] does this, and has published a fork of 3.7 + [[ https://github.com/instaclustr/cassandra#current-patches-backported | fixes ]]. === 3.10 === TODO.