本文档操作都是在单数据中心,Vnode上操作
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)在集群节点上:移除脏数据(建议在低峰执行)
已经存在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.1,唯一不同点步骤3,启动Cassandra需要同时启动,避免数据多次迁移。
由于seed需要修改cassandra.yaml文件,所以需要重启所有节点
1.先将seed作为非seed节点安装启动,完成数据迁移操作
步骤参考1.1.1
2.修改所有节点的cassandra.yaml文件,添加seed
3.重启所有节点
由于一些硬盘损坏等原因,需要执行替换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.1.1
确保替换running节点状态为UN,使用nodetoolstatus:
4.删除running节点,参考1.4
运行nodetooldecommission删除UN节点
或者:
运行nodetoolremovenode命令
注意 如果以上步骤无法删除,可能是由于节点存在脏数据,请运行nodetool assassinate,强制删除
运行nodetool cleanup,删除脏数据
或者:
运行nodetool repair,迁移数据
或者:
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
硬盘类型 | SSD(微秒) | SAS(毫秒) | SATA(秒) |
延迟 | 100~120 | 8~40 | >15 |
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
使用高效性能RAID0 sudo blockdev --setra 128 /dev/<device>
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
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
线程池使用统计,看是否有积压线程
或者使用OpsCenter
结合CPU和Disk使用监控,来判断系统每秒可以支持的操作数量
与内存使用比较,确保大的memtable不会导致内存竞争,大的memtable有利于写多读少情况
确保sstablecount比较低(个位数),每次读操作会检查所有sstable,太多的sstable影响read性能
确保不会发生频繁操作
确保延迟在可接受范围之内,不包含网络延迟
出问题后定位
writelatency写响应平均时长(以毫秒为单位)。依赖于consistency level和replication factor,也包含了写replicas的网络延迟
read latency受到硬盘,网络和应用程序读的方式等影响。比如,使用二级索引,读请求数据大小,client需要的consistencylevel都将影响readlatency。I/O的争用也会增加read latency。当SSTables有很多碎片,compaction跟不上写负载则读也会变慢。
监控表分区大小,确保max不超过100M
监控表cell count,确保不超过20亿
读写请求数
监控CPU、Memory、Disk的使用率、饱和度。
本文出自 “java架构师之路” 博客,请务必保留此出处http://eric100.blog.51cto.com/2535573/1770036
原文地址:http://eric100.blog.51cto.com/2535573/1770036