We are planning to upgrade our cluster which currently runs on 2.0.9 to 2.2.6. According to the documentation and some blogs people upgrade cassandra inplace ie remove a node from ring upgrade it and add it back again. We are skeptical of following this approach as things can go wrong(This is a high transaction database with a good number of QPS).
我们计划升级目前运行在2.0.9到2.2.6的集群。根据文档和一些博客，人们升级cassandra inplace即从环中删除一个节点升级它并再次添加它。我们对这种方法持怀疑态度，因为事情可能会出错（这是一个拥有大量QPS的高交易数据库）。
So we were planning to add a new datacenter to the cluster which shall have upgraded cassandra version(2.2). So the setup shall have two datacenter one old(2.0.9) and the other new (2.2.6)
因此，我们计划在集群中添加一个新的数据中心，该集群将具有已升级的cassandra版本（2.2）。所以设置应该有两个数据中心一个旧（2.0.9）和另一个新（2.2.6）
This datacenter is just a backup. When the datacenter becomes stable we shall change the client connection to this datacenter and if it plays well then we shall go with this datacenter and close the old datacenter or else we can fall back to the old datacenter and debug what went wrong.
此数据中心只是一个备份。当数据中心变得稳定时，我们将更改与此数据中心的客户端连接，如果它运行良好，那么我们将使用此数据中心并关闭旧数据中心，否则我们可以回退到旧数据中心并调试出错的地方。
Is this process feasible enough or should we go for in place upgrade?
这个过程是否可行，还是我们应该进行现场升级？
Can two cassandra version(2.0 and 2.2) exist across a datacenter.
数据中心内是否存在两个cassandra版本（2.0和2.2）。
Is there a downfall in this approach?
这种方法有挫折吗？
2 个解决方案
#1
3
Can two cassandra version(2.0 and 2.2) exist across a datacenter.
数据中心内是否存在两个cassandra版本（2.0和2.2）。
No, they cannot.
不，他们不能。
Is this process feasible enough or should we go for in place upgrade?
这个过程是否可行，还是我们应该进行现场升级？
You will need to perform an in-place upgrade. This is because Cassandra cannot stream across versions. Performing an in-place upgrade allows the new version to read the SSTables from the old version.
您需要执行就地升级。这是因为Cassandra不能跨版本流。执行就地升级允许新版本从旧版本读取SSTable。
Is there a downfall in this approach?
这种方法有挫折吗？
As I mentioned, you will not be able to stream data from your existing nodes to the new 2.2 DC. So bootstrapping, rebuilding, and repairing are all out of the question.
正如我所提到的，您将无法将现有节点的数据流式传输到新的2.2 DC。因此，引导，重建和修复都是不可能的。
The other issue you have, is that 2.2.6 is not "upgrade compatible" with 2.0.9. From this DataStax doc: Apache Cassandra versions requiring intermediate upgrades...
您遇到的另一个问题是2.2.6与2.0.9不是“升级兼容”。从这个DataStax doc：需要中间升级的Apache Cassandra版本......
Apache Cassandra 2.2.x restrictions
Apache Cassandra 2.2.x限制
- Upgrade from Cassandra 2.1 versions later or equal to 2.1.9 directly to Cassandra 2.2.x.
- 从Cassandra 2.1版本稍后升级或等于2.1.9直接升级到Cassandra 2.2.x.
- Direct upgrade from Cassandra 2.0 and older versions is not supported.
- 不支持从Cassandra 2.0和旧版本直接升级。
You will first have to upgrade your entire cluster to Cassandra 2.1. Once the upgrade to 2.1 is complete, then you can upgrade your nodes to 2.2.6.
您首先必须将整个群集升级到Cassandra 2.1。升级到2.1完成后，您可以将节点升级到2.2.6。
#2
1
Cassandra is a master-less distributed datastore. For Cassandra there's no such thing as a "backup" datacenter. If you're going to add another DC running 2.2, you're opting-in for a mixed version cluster setup, just as you would by upgrading nodes individually. The only advantage I see is that performance issues should be less likely due to the added nodes. However, adding another DC will make your cluster setup more complex and may introduce issues that you don't know about yet, but won't have anything to do with running different versions. How would you bootstrap the new DC? How will taking down the old DC effect performance? The operational impact will be much bigger with this approach compared to updating individual nodes..
Cassandra是一个无主分布式数据存储区。对于Cassandra来说，没有“备份”数据中心这样的东西。如果您要添加另一个运行2.2的DC，您将选择使用混合版本集群设置，就像单独升级节点一样。我看到的唯一优势是，由于添加了节点，性能问题应该不太可能发生。但是，添加另一个DC会使您的群集设置更加复杂，并且可能会引入您尚未了解的问题，但与运行不同版本无关。你会如何引导新的DC？如何降低旧的DC效果性能？与更新单个节点相比，此方法的运营影响将大得多。
If you really don't want to do rolling upgrades, I'd suggest do setup the second DC as a separate cluster, import a backup and do some (load) testing. Also change your code to write into both clusters and eventually switch to the new one if you're satisfied. If you don't want to spend so much effort, just do the rolling upgrade.
如果您真的不想进行滚动升级，我建议将第二个DC设置为单独的群集，导入备份并执行一些（加载）测试。还要更改代码以写入两个群集，如果满意，最终切换到新群集。如果您不想花费这么多精力，只需进行滚动升级即可。
#1
3
Can two cassandra version(2.0 and 2.2) exist across a datacenter.
数据中心内是否存在两个cassandra版本（2.0和2.2）。
No, they cannot.
不，他们不能。
Is this process feasible enough or should we go for in place upgrade?
这个过程是否可行，还是我们应该进行现场升级？
You will need to perform an in-place upgrade. This is because Cassandra cannot stream across versions. Performing an in-place upgrade allows the new version to read the SSTables from the old version.
您需要执行就地升级。这是因为Cassandra不能跨版本流。执行就地升级允许新版本从旧版本读取SSTable。
Is there a downfall in this approach?
这种方法有挫折吗？
As I mentioned, you will not be able to stream data from your existing nodes to the new 2.2 DC. So bootstrapping, rebuilding, and repairing are all out of the question.
正如我所提到的，您将无法将现有节点的数据流式传输到新的2.2 DC。因此，引导，重建和修复都是不可能的。
The other issue you have, is that 2.2.6 is not "upgrade compatible" with 2.0.9. From this DataStax doc: Apache Cassandra versions requiring intermediate upgrades...
您遇到的另一个问题是2.2.6与2.0.9不是“升级兼容”。从这个DataStax doc：需要中间升级的Apache Cassandra版本......
Apache Cassandra 2.2.x restrictions
Apache Cassandra 2.2.x限制
- Upgrade from Cassandra 2.1 versions later or equal to 2.1.9 directly to Cassandra 2.2.x.
- 从Cassandra 2.1版本稍后升级或等于2.1.9直接升级到Cassandra 2.2.x.
- Direct upgrade from Cassandra 2.0 and older versions is not supported.
- 不支持从Cassandra 2.0和旧版本直接升级。
You will first have to upgrade your entire cluster to Cassandra 2.1. Once the upgrade to 2.1 is complete, then you can upgrade your nodes to 2.2.6.
您首先必须将整个群集升级到Cassandra 2.1。升级到2.1完成后，您可以将节点升级到2.2.6。
#2
1
Cassandra is a master-less distributed datastore. For Cassandra there's no such thing as a "backup" datacenter. If you're going to add another DC running 2.2, you're opting-in for a mixed version cluster setup, just as you would by upgrading nodes individually. The only advantage I see is that performance issues should be less likely due to the added nodes. However, adding another DC will make your cluster setup more complex and may introduce issues that you don't know about yet, but won't have anything to do with running different versions. How would you bootstrap the new DC? How will taking down the old DC effect performance? The operational impact will be much bigger with this approach compared to updating individual nodes..
Cassandra是一个无主分布式数据存储区。对于Cassandra来说，没有“备份”数据中心这样的东西。如果您要添加另一个运行2.2的DC，您将选择使用混合版本集群设置，就像单独升级节点一样。我看到的唯一优势是，由于添加了节点，性能问题应该不太可能发生。但是，添加另一个DC会使您的群集设置更加复杂，并且可能会引入您尚未了解的问题，但与运行不同版本无关。你会如何引导新的DC？如何降低旧的DC效果性能？与更新单个节点相比，此方法的运营影响将大得多。
If you really don't want to do rolling upgrades, I'd suggest do setup the second DC as a separate cluster, import a backup and do some (load) testing. Also change your code to write into both clusters and eventually switch to the new one if you're satisfied. If you don't want to spend so much effort, just do the rolling upgrade.
如果您真的不想进行滚动升级，我建议将第二个DC设置为单独的群集，导入备份并执行一些（加载）测试。还要更改代码以写入两个群集，如果满意，最终切换到新群集。如果您不想花费这么多精力，只需进行滚动升级即可。