【问题标题】:Cassandra nodes becomes unreachable to each otherCassandra 节点彼此无法访问
【发布时间】:2019-05-10 11:04:29
【问题描述】:

我有 3 个 elassandra 节点在 docker 容器中运行。

容器创建如下:

主机 10.0.0.1 : docker run --name elassandra-node-1 --net=host -e CASSANDRA_SEEDS="10.0.0.1" -e CASSANDRA_CLUSTER_NAME="BD Storage" -e CASSANDRA_DC="DC1" -e CASSANDRA_RACK ="r1" -d 表带数据/elassandra:最新的

主机 10.0.0.2 : docker run --name elassandra-node-2 --net=host -e CASSANDRA_SEEDS="10.0.0.1,10.0.0.2" -e CASSANDRA_CLUSTER_NAME="BD 存储" -e CASSANDRA_DC="DC1 " -e CASSANDRA_RACK="r1" -d strapdata/elassandra:latest

主机 10.0.0.3 : docker run --name elassandra-node-3 --net=host -e CASSANDRA_SEEDS="10.0.0.1,10.0.0.2,10.0.0.3" -e CASSANDRA_CLUSTER_NAME="BD Storage" -e CASSANDRA_DC="DC1" -e CASSANDRA_RACK="r1" -d strapdata/elassandra:latest

自从创建以来,Cluster 已经运行了几天,弹性、cassandra 都非常完美。

然而,目前所有 cassandra 节点都变得无法相互访问: 所有节点上的Nodetool状态就像

数据中心:DC1

状态=上/下 |/ 状态=正常/离开/加入/移动 -- 地址加载令牌拥有(有效)主机 ID 机架 DN 10.0.0.3 11.95 GiB 8 100.0% 7652f66e-194e-4886-ac10-0fc21ac8afeb r1 DN 10.0.0.2 11.92 GiB 8 100.0% b91fa129-1dd0-4cf8-be96-9c06b23daac6 r1 UN 10.0.0.1 11.9 GiB 8 100.0% 5c1afcff-b0aa-4985-a3cc-7f932056c08f r1

其中联合国是当前主机 10.0.0.1 在所有其他节点上相同。

10.0.0.1 上的Nodetool describecluster 是这样的

集群信息: 名称: BD Storage 告密者:org.apache.cassandra.locator.GossipingPropertyFileSnitch DynamicEndPointSnitch:启用 分区器:org.apache.cassandra.dht.Murmur3Partitioner 架构版本: 24fa5e55-3935-3c0e-9808-99ce502fe98d:[10.0.0.1]

            UNREACHABLE: [10.0.0.2,10.0.0.3]

当附加到第一个节点时,它只会重复这些信息:

2018-12-09 07:47:32,927 WARN [OptionalTask​​s:1] org.apache.cassandra.auth.CassandraRoleManager.setupDefaultRole(CassandraRoleManager.java:361) CassandraRoleManager 跳过了默认角色设置:一些节点尚未准备好 2018-12-09 07:47:32,927 INFO [OptionalTask​​s:1] org.apache.cassandra.auth.CassandraRoleManager$4.run(CassandraRoleManager.java:400) 安装任务失败,错误,重新安排 2018-12-09 07:47:32,980 信息 [HANDSHAKE-/10.0.0.2] org.apache.cassandra.net.OutboundTcpConnection.lambda$handshakeVersion$1(OutboundTcpConnection.java:561) 与 /10.0.0.2 的握手版本 2018-12-09 07:47:32,980 信息 [HANDSHAKE-/10.0.0.3] org.apache.cassandra.net.OutboundTcpConnection.lambda$handshakeVersion$1(OutboundTcpConnection.java:561) 握手版本与 /10.0.0.3

一段时间后,某个节点重新启动:

2018-12-09 07:52:21,972 WARN [MigrationStage:1] org.apache.cassandra.service.MigrationTask.runMayThrow(MigrationTask.java:67) 无法发送架构拉取请求:节点 /10.0.0.2下线了。

到目前为止尝试过: 同时重启所有容器 一个接一个地重启所有容器 在所有容器中重新启动 cassandra,例如:service cassandra restart Nodetool disablegossip 然后启用它 Nodetool 修复:修复命令 #1 失败,错误 Endpoint not alive: /10.0.0.2

似乎所有节点架构都不同,但我仍然不明白为什么它们被标记为彼此。

【问题讨论】:

  • 也许容器改变了IP?你试过在每个容器上运行 nodetool status 吗?
  • 容器 IP 很好。所有这些都显示了一个 UN(我运行 nodetool 状态的当前那个)和 2 个具有正确地址的 DN。

标签: cassandra nosql bigdata nodes elassandra


【解决方案1】:

如果您有不同的 Cassandra 版本,则 nodetool repair 将不会提取数据。保持相同版本的 Cassandra。有时,由于八卦没有正确发生,节点会显示或无法访问。原因可能是网络,该节点上的高负载或节点非常繁忙,并且正在进行大量 i/o 操作,例如修复、压缩等。

【讨论】:

  • 3台节点版本相同,服务器完全没有负载,网络没问题,3台服务器都可以手动通信
猜你喜欢
  • 2016-03-06
  • 2014-05-03
  • 2014-08-28
  • 2023-03-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-23
  • 2021-04-09
相关资源
最近更新 更多