cassandra 常见问题

前端之家收集整理的这篇文章主要介绍了cassandra 常见问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

摘要

本文主要介绍在部署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.

猜你在找的NoSQL相关文章