cassandra集群缩容与剔除问题节点

  今天在操作cassandra集群数据迁移时发生了一些意料之外的事情,服务器迁移前与迁移后同样为5台,但是不知道是什么原因导致的,迁移过后的节点居然多出了一台cassandra节点,个人瞬间感觉莫名其妙,但是问题节点的ip地址是原平台的cassandra数据库ip,所以感觉很不好,知道可能是因为那个环节出现了问题,因为是迁移演练所以没有决定删除所有数据,重新迁移只是将错误节点剔除了cassandra集群,操作如下:

官方文档建议

查看cassandra集群状态的命令

nodetool status
xss = -Dcassandra.fd_initial_value_ms=5000 -javaagent:/data/apps/opt/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms3987M -Xmx3987M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/apps/log/cassandra//cassandra-1502968444-pid11574.hprof -Xss350k
Note: Ownership information does not include topology; for complete information, specify a keyspace
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 192.168.70.17 551.55 MB 256 16.9% de09bab3-4d79-47a8-9f09-ad68d189802c rack1
UN 192.168.70.18 610.19 MB 256 18.5% f4b541b1-f8e6-4ea6-a376-a7c797a071c8 rack1
UN 192.168.70.19 696.68 MB 256 15.6% 17fb7b42-6ae2-4d7a-829f-92eab163b96a rack1
UN 192.168.70.20 567.55 MB 256 14.7% 02a2fc29-91a5-4a36-b7f4-58a461b8cc9f rack1
DN 192.168.0.4 ? 256 17.4% 41528794-6454-4cb3-9e16-6f8b7961cc61 rack1  (问题节点所在)
UN 192.168.70.21 467.75 KB 256 17.0% 03197de4-e1a5-4e98-a38a-aa75f31d10d9 rack1
[[email protected] ~]# nodetool removenode 41528794-6454-4cb3-9e16-6f8b7961cc61

一、修复每台机器的keyspace

nodetool repair -h ip_address_of_node keyspace_name

二、如果要剔除的cassandra数据库的状态为UN,表示数据库为正常状态可以执行以下命令

nodetool decommission  (此命令同样适用于cassandra缩容,执行此命令在某台cassandra数据库,此数据库将退出当前cassandra集群,需要注意的是此命令执行时间过长,需要在tmux或者使用nohup的方式执行)

三、如果要剔除的cassandra数据库的状态为DN,可以直接执行以下命令将问题节点剔除

nodetool removenode 41528794-6454-4cb3-9e16-6f8b7961cc61
xss = -Dcassandra.fd_initial_value_ms=5000 -javaagent:/data/apps/opt/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms3987M -Xmx3987M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/apps/log/cassandra//cassandra-1502969778-pid11978.hprof -Xss350k

四、接下来就是一段漫长的等待了,等到命令执行完成后在查看下是否还存在这个错误节点吧

nodetool status
xss = -Dcassandra.fd_initial_value_ms=5000 -javaagent:/data/apps/opt/cassandra/lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms3987M -Xmx3987M -Xmn400M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/apps/log/cassandra//cassandra-1502968444-pid11574.hprof -Xss350k
Note: Ownership information does not include topology; for complete information, specify a keyspace
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 192.168.70.17 551.55 MB 256 16.9% de09bab3-4d79-47a8-9f09-ad68d189802c rack1
UN 192.168.70.18 610.19 MB 256 18.5% f4b541b1-f8e6-4ea6-a376-a7c797a071c8 rack1
UN 192.168.70.19 696.68 MB 256 15.6% 17fb7b42-6ae2-4d7a-829f-92eab163b96a rack1
UN 192.168.70.20 567.55 MB 256 14.7% 02a2fc29-91a5-4a36-b7f4-58a461b8cc9f rack1
UN 192.168.70.21 467.75 KB 256 17.0% 03197de4-e1a5-4e98-a38a-aa75f31d10d9 rack1
  至此cassandra错误节点清除与cassandra缩容完成。

时间: 2024-10-16 14:21:07

cassandra集群缩容与剔除问题节点的相关文章

使用kubeadm部署k8s集群07-扩容kube-scheduler到3节点

使用kubeadm部署k8s集群07-扩容kube-scheduler到3节点 2018/1/4 扩容 kube-scheduler 到 3 节点 连接到本节点的 apiserver [[email protected] kube-controller-manager]# cat /etc/kubernetes/manifests/kube-scheduler.yaml |grep '/etc/kubernetes' --kubeconfig=/etc/kubernetes/scheduler.

使用kubeadm部署k8s集群03-扩容kube-apiserver到3节点

使用kubeadm部署k8s集群03-扩容kube-apiserver到3节点 2018/1/3 扩容 kube-apiserver 到 3 节点 配置 kube-apiserver.yaml 分析 kube-apiserver 依赖的证书 为新节点生成专属证书 下发证书到对应的节点 确认每个节点的 apiserver 是否处于 Running 状态 配置 kube-apiserver.yaml ### 拷贝原 master 上的配置: [[email protected] ~]# mkdir

Cassandra 集群核心配置和概梳理

Cassandra是一款分布式的结构化数据存储方案(NoSql数据库),存储结构比Key-Value数据库(像Redis)更丰富,但是比Document数据库(如Mongodb)支持度有限:适合做数据分析或数据仓库这类需要迅速查找且数据量大的应用.Cassandra 集群特性比较丰富,考虑场景也比较多,如果想用好集群,集群本很多概念都要能够了解,下面对相关概念进行简介: 与关系数据库相关概念: keyspace -> table –> column,对应关系型数据库 database ->

Cassandra集群管理-下线正常节点

测试前题: 测试cassandra集群使用了vnodes,如何判断是否用了vnodes呢? 主要看你的cassandra.yml配置文件中.默认(3.x)为空,系统自动生成.为空表示使用virtual nodes,默认开启,使用了vnodes,删除了节点之后它会自己均衡数据,需要人为干预. 测试数据生成 创建一个名为kevin_test的KeySpace 创建一个名为kevin_test的KeySpace,使用网络拓扑策略(SimpleStrategy),集群内3副本,另外开启写commit l

Cassandra集群管理-删除异常节点

Cassandra集群管理-删除异常节点 故障模拟节点:172.20.101.166,模拟节点系统直接损坏,所有数据丢失. 注意: 本文档只是体系文档中的一部分,前面文档信息详见:测试准备+下线正常节点:https://blog.51cto.com/michaelkang/2419518节点异常重启:https://blog.51cto.com/michaelkang/2419524添加新节点:https://blog.51cto.com/michaelkang/2419521删除异常节点:ht

Cassandra集群管理-替换异常节点

Cassandra集群管理-替换异常节点 替换异常集群节点,使用JVM启动标志 Dcassandra.replace_address_first_boot = <dead_node_ip>启动.一旦启用此属性,节点将在休眠状态中启动,在此期间所有其他节点将看到此节点关闭.替换节点将立即开始从集群中的其余节点引导数据. 新节点的正常引导的主要区别在于此新节点在此阶段不会接受任何写入.一旦引导完成,节点将被标记为"UP",我们依赖于隐性启动保障新节点数据独立存在.(因为自引导开

Cassandra 集群管理-添加新节点

Cassandra 集群添加节点 注意 本文档只是体系文档中的一部分,前面文档信息详见:https://blog.51cto.com/michaelkang/2419518 场景: 用于节点扩容,测试方法:清理(172.20.101.165)节点上所有数据,模拟新节点加入: 确认内容: 1:使用相同版本的Cassandra 2:注意,种子节点不能引导.确保新节点没有在-seeds列表中列出,不要使所有节点种子节点. 3:copy加入DC现有节点配置文件到新节点,然后进行配置修改,文件如下: 在c

Cassandra集群管理-节点异常重启

Cassandra集群管理-节点异常重启 登陆一台集群节点,直接重启服务器(172.20.101.166),设置了 cassandra 开机启动. 注意: 本文档只是体系文档中的一部分,前面文档信息详见:测试准备+下线正常节点:https://blog.51cto.com/michaelkang/2419518节点异常重启:https://blog.51cto.com/michaelkang/2419524添加新节点:https://blog.51cto.com/michaelkang/2419

自学总结redis第四部分(集群搭建以及增加和删除节点)

十六.redis集群 参考网站"https://redis.io/topics/cluster-tutorial" 16.1集群搭建 #下述是在一台机器模拟六个节点,3主3从 [[email protected] ~]# cd /application/ [[email protected] application]# cd redis [[email protected] redis]# mkdir redis-cluster [[email protected] redis-clu