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. 删除节点：参考1.4(建议72小时之后操作，确保gossip删除掉了老节点)

   1.3.   替换一个running节点

由于升级新硬件等原因，需要使用新节点替换

1. 添加新节点到集群中，参考步骤1.1.1

2. 确保替换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.     安装jemalloc

jemalloc适合多线程下内存分配管理
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~120	8~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.conf

vm.max_map_count = 131072
#最大限度使用物理内存
vm.swappiness = 0

使之生效

sysctl -p

 

永久关闭swap

swapoff –a

/etc/fstab：注释掉swap

3.NUMA

echo 0 > /proc/sys/vm/zone_reclaim_mode

4.文件系统类型

EXT4

2.1.6.     磁盘阵列RAID优化

使用高效性能RAID0
sudo blockdev --setra 128 /dev/<device>

2.1.7.     cassandra-evn.sh配置建议

JVM配置在cassandra-evn.sh中

1. MAX_HEAP_SIZE

生产环境建议8G

1. HEAP_NEWSIZE

一般设置为MAX_HEAP_SIZE的1/4

1. 添加cassandra压缩线程级别，减少其资源占用

-Dcassandra.compaction.priority=1

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的使用率、饱和度。

转载于:https://blog.51cto.com/eric100/1770036