cassandra 常见问题

时间：2023-02-04 01:48:02

摘要

本文主要介绍在部署cassandra集群以及使用cassandra过程中遇到的一些问题。

文章只发布在CSDN 和个人站点

更多nosql文章可以访问stone fang 个人主页

正文

Q1:cassandra 如何将一个节点设置为seed node,seed node与其他node有什么区别

A1:设置seed node很简单，在cassandra.yaml 中 -seeds 选项中设置。可以设置多个node.

seed node 是用于新节点加入到集群中，新节点需要通过seed node去发现集群加载的data信息。一旦新节点bootstrap后

seed node 就没有作用了。

seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
  parameters:
      - seeds: "127.0.0.1"

Q2:cassandra node 新加入到集群中，autobootstrap默认为true，所以可以进行bootstrap，但是加入到集群后，然后重启node，并没有设置

autobootstrap为false，为什么这时候cassandra不再做bootstrap呢。

A2:bootstrap意思是一个新节点加入到集群中，这个新节点加入到集群的partition ring中。负责一部分partition key。其他节点也会更新

保存的partition 环信息。而当我们重启节点时，节点会首先自动缓存Gossip状态信息，在重新启动时会自动加载。所以在cassandra部署过程中，你会发现

有时候你新启动一个节点，并没有指定seed node，这个node也莫名其妙的加入到了cluster。这是gossip状态没有清除，保存了以前的信息。

可以在启动时添加-Dcassandra.load_ring_state=false

Q3:unable to gossip with seeds.seed 设置有效，也没有防火墙屏蔽。为什么无法gossip，启动失败

A3:这个可能性很多，首先检查下cassandra.yaml 配置文件的listen_address和broadcast_address.在seed node上

面ping下broadcast_address。是否能够ping通。通常在云主机平台上，主机有public ip和private ip.broad_address 需要配置为public ip,listen_address

可以配置private ip。

作者还碰到过一个情况：cassandra 运行在docker中，listen_address是docker分配的私有地址172.17.0.2.

但是不知道什么时候配置了route表。将172.17.0.0配置到节点的public ip。导致cassandra无法启动。gossip 不到seeds node.

172.17.0.0 应该是路由到docker 的网桥，默认是docker0.将配置错的路由删除掉。就可以了。

Q4:JMX 访问，设置了remote 方式，7199 端口也打开了，但是仍然访问不了。

A4:cassandra-env.sh 中配置了JMX访问方式，可以传参。

if [ "x$LOCAL_JMX" = "x" ]; then
LOCAL_JMX=yes
fi
JMX_PORT="7199"

if [ "$LOCAL_JMX" = "yes" ]; then
  JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.local.port=$JMX_PORT -XX:+DisableExplicitGC"
else
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.ssl=false"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.authenticate=true"
  JVM_OPTS="$JVM_OPTS -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password"

实验环境中可以自行设定了外部访问方式，

将jmxremote.authenticate值设为false.就不需要登录名和密码了。通常是使用jconsle 来测试JMX是否可以

通过remote连接。在docker环境下7199已经映射了，但是仍然访问不了。cassandra的listen_address是docker分配的

private ip.broadcast_address是public ip.jconsole连接的public ip.这时候无法访问，解决办法是在

cassandra-env.sh中设置jmx暴露出的ip，像JMX_PORT=”7199”一样

JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname=<public ip>"

Q5:新节点加入时状态一直都是UJ,而不是UN

A5:UJ J表示在加入。已经存在的cluster数据很多，将数据从其他节点中移过来需要时间。可以通过nodetool netstats查看下

其他节点传输数据到新节点的情况。如果已经没有stream data了，但是状态还是J。可能是sstable在做compaction工作。

Q6:如何理解在关系型数据库中是首先设计DB Schema，然后考虑查询。但是在cassandra中，需要首先考虑查询场景，然后再去设计DB Schema

A6:关系型数据库数据是行列式存储，一系列的行和列组成了表，一张表的每一行的列数是固定的。可以根据任意一列来去查询数据。

所以查询场景不需要优先考虑。而在cassandra则不是，首先cassandra是根据partition key分布在各个节点上的。节点上的数据又是根据cluster key来分布的。

一种查询模式对应的一张表。

eg

create table test (
name text,
age int,
address text,
PRIMARY KEY(name,address,age)
);

这里name是partition key，address,age是cluster key.数据在节点上的存储方式是/address/age 这种分层结构。所以查询的时候只能根据address来查

select *from test where address='xx'

而不能根据age,因为age在address的下一层结构中，无法索引到。如果想根据age，必须重新创建一张表。或者使用materialized view.

综上所述，所以说在cassandra中需要先考虑查询场景，然后再去设计DB Schema.

Q7:Cassandra 3.0 and later require Java 8u40 or later.

java -version 查看已经是JDK8。

A7.echo JAVA_HOME 发现指向了JDK7，cassandra去检查了JAVA_HOME 环境变量，所以出现错误。

移除JAVA_HOME或者指向JDK8,就可以解决问题

Q8:java driver cannot connect to ip:9042

A8:检查9042端口是否暴露

然后检查cassandra.yaml 文件的rpc_address 是否设置为公共ip

相关文章