【问题标题】:Rolling upgrade for Cassandra 1.0.9 cluster to 1.2.1Cassandra 1.0.9 集群滚动升级到 1.2.1
【发布时间】:2014-06-05 12:23:31
【问题描述】:

作为我们遇到的生产问题的一部分,我们希望将生产 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 应该能够支持这样的滚动升级,对吧? 如果有人遇到这个问题,或者认为他知道问题可能是什么, 请指教, 或者。

【问题讨论】:

  • 您是否在 cassandra 日志中遇到错误?通常一致的超时异常意味着存在异常。日志通常位于 /var/log/cassandra/system.log。

标签: cassandra


【解决方案1】:

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

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

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

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

【讨论】:

    猜你喜欢
    • 2023-03-20
    • 2013-12-01
    • 2016-08-02
    • 2022-06-10
    • 1970-01-01
    • 2019-10-18
    • 1970-01-01
    • 2018-11-14
    • 2011-10-07
    相关资源
    最近更新 更多