摘要
本文主要介绍在部署cassandra集群以及使用cassandra过程中遇到的一些问题。
更多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.