2013-03-12 46 views
3

作为生产问题的一部分,我们希望将生产1.0.9集群升级到1.2.1/2。Cassandra 1.0.9集群的滚动升级到1.2.1

虽然在我们的开发环境中测试升级,我发现了以下情况例外,而这样做使用CLI一个简单的列表操作升级的集群节点之一的:(只是一个节点出3升级)

[[email protected]] 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)相同的异常:

[[email protected]] 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节点我没有得到任何错误,在同一列表的操作,我假设此节点拥有唯一的副本:

[[email protected]] 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.3开始,从 1.2.1/2开始,它仍然无法使用范围(?)扫描。 从cql客户端使用select *查询时发生同样的错误。 我没有做任何特殊的测试,所以我猜这个问题应该发生在 任何从1.0.9升级,这将是很容易重现。

nodetool环显示所有节点都在运行(所有节点上运行):

-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% 567137278201564105772291
33.33.33.4 RAC1 Up Normal 63.39 KB 33.33% 113427455640312821154458202477256070485 

一旦我完成所有节点上的升级,集群恢复到正常的。

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

+0

你在cassandra日志中遇到错误吗?通常,一致的超时异常意味着存在异常。日志通常位于/var/log/cassandra/system.log中。 – Richard 2013-03-12 15:45:38

回答

0

滚动升级是可能的,我一直在做。你可能不应该跳过两个主要版本1.0 - 1.2。我知道它被归类为一个点的发布,但很多改变。

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

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

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