Question

作为生产问题的一部分，我们希望将生产1.0.9集群升级到1.2.1 / 2.

在我们的开发环境中测试升级时，我在其中一个升级的集群节点上使用cli进行简单的列表操作时遇到以下异常:(只升级了3个节点）

[default@testKS] list testCF;
Using default limit of 100
Using default column limit of 100
null
TimedOutException()
at org.apache.cassandra.thrift.Cassandra$get_range_slices_result.read(Cassandra.java:12932)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:78)
at org.apache.cassandra.thrift.Cassandra$Client.recv_get_range_slices(Cassandra.java:734)
at org.apache.cassandra.thrift.Cassandra$Client.get_range_slices(Cassandra.java:718)
at org.apache.cassandra.cli.CliClient.executeList(CliClient.java:1485)
at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:272)
at org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:210)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:337)

我在非升级节点（1.0.9）上运行相同的列表操作时遇到相同的异常：

[default@testKS] list testCF;
Using default limit of 100
null
TimedOutException()
at org.apache.cassandra.thrift.Cassandra$get_range_slices_result.read(Cassandra.java:12830)
at org.apache.cassandra.thrift.Cassandra$Client.recv_get_range_slices(Cassandra.java:762)
at org.apache.cassandra.thrift.Cassandra$Client.get_range_slices(Cassandra.java:734)
at org.apache.cassandra.cli.CliClient.executeList(CliClient.java:1390)
at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:269)
at org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)

在另一个1.0.9节点上尝试相同的列表操作时，我没有错误，我认为这个节点只保存了一个副本：

[default@testKS] list testCF;
Using default limit of 100
-------------------
RowKey: 0a
=> (column=0a, value=0a, timestamp=1362642828623000)

1 Row Returned.
Elapsed time: 11 msec(s).

我正在使用的testCF只有一个键和值以及超时异常是一致的。我正在使用复制因子1，但所有三个节点似乎都已启动同步。

似乎这是从1.0.9开始的最简单的升级 1.2.1 / 2并且仍然无法使用范围（？）扫描。从cql客户端使用select *查询时发生同样的错误。我没有做任何特殊测试，所以我猜这个问题应该发生在任何从1.0.9的升级都很容易重现。

nodetool ring显示所有节点都已启动（在所有节点上运行）：

-bash-4.1$ nodetool -h localhost ring

Datacenter: US
==========
Replicas: 1

Address Rack Status State Load Owns Token
113427455640312821154458202477256070485
33.33.33.2 RAC1 Up Normal 39.31 KB 33.33% 0
33.33.33.3 RAC1 Up Normal 63.39 KB 33.33% 56713727820156410577229101238628035242
33.33.33.4 RAC1 Up Normal 63.39 KB 33.33% 113427455640312821154458202477256070485

在所有节点上完成升级后，群集将恢复正常。

为什么？不应该那样吗？对？据我了解，Cassandra应该能够支持像这样的滚动升级，对吧？如果有人遇到这个问题，或者认为他知道问题可能是什么，请指教，或

Answer 1

滚动升级是可能的，我会一直这样做。你可能不应该跳过2个主要版本1.0 - 1.2。我知道它被归类为点发布，但发生了很多变化。

您应该滚动升级到1.1.X，然后在所有节点上运行升级，然后在所有节点上进行修复。

然后滚动升级到1.2.X，然后在所有节点上运行升级，然后在所有节点上修复。

因此，支持滚动更新，但您应该以合理的方式来降低风险。你的3节点集群不应该花费很长时间。

将Cassandra 1.0.9群集滚动升级到1.2.1

1 个答案: