java 操作cassandra_Cassandra操作和性能优化

1.Cassandra操作

本文档操作都是在单数据中心，Vnode上操作

1.1.添加节点到集群中

1.1.1.添加非seed单节点

1.在新节点上安装Cassandra，但不要启动

2.修改cassandra.yaml文件：cluster_name – 新节点加入集群名称

listen_address/rpc_address – 新节点IP

seed_provider – 集群seeds列表

3.启动新节点Cassandra

4.使用nodetool status验证节点是否启动完毕：状态为UN

5.运行nodetool cleanup(或OpsCenter)在集群节点上：移除脏数据(建议在低峰执行)

1.2.添加非seed单节点案例：

已经存在Cassandra集群：cluster_name = ‘Test Cluster’

xxx_address = 192.168.92.148

seed_provider = 192.168.92.148

添加新节点192.168.92.149:

1.安装Cassandra

参考《Cassandra教程》

2.修改cassandra.yaml

cluster_name：

seed_provider

listen_address:

rpc_address:

3.启动Cassandra

4.验证新节点192.168.92.149是否启动完毕

5.删除192.168.92.148上的脏数据

或者

1.1.3.添加非seed多个节点

步骤参考1.1.1，唯一不同点步骤3，启动Cassandra需要同时启动，避免数据多次迁移。

1.1.4.添加seed节点

由于seed需要修改cassandra.yaml文件，所以需要重启所有节点

1.先将seed作为非seed节点安装启动，完成数据迁移操作

步骤参考1.1.1

2.修改所有节点的cassandra.yaml文件，添加seed

3.重启所有节点

1.2.替换一个dead节点

由于一些硬盘损坏等原因，需要执行替换dead节点

1.确保dead节点状态为DN，使用nodetool status:

注意Address需要在下面步骤用到

2.修改新节点cassandra.yaml文件：参考1.1.1

3.启动新节点，使用replace_address选项：$ sudo bin/cassandra -Dcassandra.replace_address=address_of_dead_node

删除节点：参考1.4(建议72小时之后操作，确保gossip删除掉了老节点)

1.3.替换一个running节点

由于升级新硬件等原因，需要使用新节点替换添加新节点到集群中，参考步骤1.1.1

确保替换running节点状态为UN，使用nodetoolstatus:

4.删除running节点，参考1.4

1.4.删除节点

1.4.1.删除UN状态节点

运行nodetooldecommission删除UN节点

或者：

1.4.2.删除DN状态节点

运行nodetoolremovenode命令

注意

如果以上步骤无法删除，可能是由于节点存在脏数据，请运行nodetool assassinate，强制删除

1.5.修改ReplicationFactor

1.5.1.ReplicationFactor减少

运行nodetool cleanup，删除脏数据

或者：

1.5.2.ReplicationFactor增加

运行nodetool repair，迁移数据

或者：

2.Cassandra优化

2.1.安装前配置建议

2.1.1.安装jemallocjemalloc适合多线程下内存分配管理

wget http://www.canonware.com/download/jemalloc/jemalloc-3.6.0.tar.bz2

tar xjf jemalloc-3.6.0.tar.bz2

cd jemalloc-3.6.0

./configure

make &&make install

echo '/usr/local/lib'>/etc/ld.so.conf.d/local.conf

ldconfig

2.1.2.安装NTP (略)

2.1.3.Commit log和data目录在独立硬盘

2.1.4.硬盘类型硬盘类型SSD(微秒)SAS(毫秒)SATA(秒)

延迟100~1208~40>15

2.1.5.Linux优化

1.文件操作符

/etc/security/limits.conf* - nofile 65535

* - memlock unlimited

* – nofile 32768

* – as unlimited

/etc/security/limits.d/90-nproc.conf* - nproc 32768

2.Swap

/etc/sysctl.confvm.max_map_count = 131072

#最大限度使用物理内存

vm.swappiness = 0

使之生效sysctl -p

永久关闭swapswapoff –a

/etc/fstab：注释掉swap

3.NUMAecho 0 > /proc/sys/vm/zone_reclaim_mode

4.文件系统类型EXT4

2.1.6.磁盘阵列RAID优化使用高效性能RAID0

sudo blockdev --setra 128 /dev/

2.1.7.cassandra-evn.sh配置建议

JVM配置在cassandra-evn.sh中MAX_HEAP_SIZE

生产环境建议8G

HEAP_NEWSIZE

一般设置为MAX_HEAP_SIZE的1/4添加cassandra压缩线程级别，减少其资源占用-Dcassandra.compaction.priority=1打开JVM压缩，减少内存占用，适用于64位JVM-XX:+UseCompressedOops

2.1.8.cassandra.yaml配置建议concurrent_reads：16 * number_of_drives

concurrent_counter_writes：16 * number_of_drives

concurrent_writes：8 * number_of_cores

#使用Memory Mapped File IO，性能超过Standard IO，64位

disk_access_mode: mmap

#write性能提升5%

memtable_allocation_type: offheap_objects

2.2.安装后监控——定位——优化

2.2.1.nodetool tpstats

线程池使用统计，看是否有积压线程

或者使用OpsCenter

2.2.2.Read Requests/Write Requests

结合CPU和Disk使用监控，来判断系统每秒可以支持的操作数量

2.2.3.total Memtable size

与内存使用比较，确保大的memtable不会导致内存竞争，大的memtable有利于写多读少情况

2.2.4.SSTable count

确保sstablecount比较低(个位数)，每次读操作会检查所有sstable，太多的sstable影响read性能

2.2.5.total bytes compacted

确保不会发生频繁操作

2.2.6.read latency/write latency

确保延迟在可接受范围之内，不包含网络延迟

出问题后定位

writelatency写响应平均时长(以毫秒为单位)。依赖于consistency level和replication factor，也包含了写replicas的网络延迟

read latency受到硬盘，网络和应用程序读的方式等影响。比如，使用二级索引，读请求数据大小，client需要的consistencylevel都将影响readlatency。I/O的争用也会增加read latency。当SSTables有很多碎片，compaction跟不上写负载则读也会变慢。

2.2.7.partition size

监控表分区大小，确保max不超过100M

2.2.8.cell count

监控表cell count，确保不超过20亿

2.2.9.write Read active

读写请求数

2.2.10.OS系统监控

监控CPU、Memory、Disk的使用率、饱和度。