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

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

登陆一台集群节点,直接重启服务器(172.20.101.166),设置了 cassandra 开机启动。

注意:

本文档只是体系文档中的一部分,前面文档信息详见:
测试准备+下线正常节点:https://blog.51cto.com/michaelkang/2419518
节点异常重启:https://blog.51cto.com/michaelkang/2419524
添加新节点:https://blog.51cto.com/michaelkang/2419521
删除异常节点:https://blog.51cto.com/michaelkang/2419525

场景:

节点被异常重启,对集群引发的反应。

cassandra.log 基本没有输出

tailf /var/log/cassandra/cassandra.log

system.log

有明显日志报 172.20.101.166 DOWN !!!

172.20.101.165 节点:

[[email protected] lib]# tailf /var/log/cassandra/system.log
INFO  [GossipStage:1] 2019-07-11 18:19:23,372 Gossiper.java:1026 - InetAddress /172.20.101.166 is now DOWN

查看异常节点

[[email protected] ~]# nodetool describecluster
Cluster Information:
        Name: pttest
        Snitch: org.apache.cassandra.locator.GossipingPropertyFileSnitch
        DynamicEndPointSnitch: enabled
        Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
        Schema versions:
                cfce5a85-19c8-327a-ab19-e1faae2358f7: [172.20.101.164, 172.20.101.165, 172.20.101.167, 172.20.101.160, 172.20.101.157]

                UNREACHABLE: [172.20.101.166]

debug.log

大量报无法连接 172.20.101.166

172.20.101.164 节点:

tailf /var/log/cassandra/debug.log

DEBUG [GossipStage:1] 2019-07-11 18:19:23,374 OutboundTcpConnection.java:205 - Enqueuing socket close for /172.20.101.166
DEBUG [MessagingService-Outgoing-/172.20.101.166-Small] 2019-07-11 18:19:23,374 OutboundTcpConnection.java:411 - Socket to /172.20.101.166 closed
DEBUG [GossipStage:1] 2019-07-11 18:19:23,374 OutboundTcpConnection.java:205 - Enqueuing socket close for /172.20.101.166
DEBUG [MessagingService-Outgoing-/172.20.101.166-Gossip] 2019-07-11 18:19:23,374 OutboundTcpConnection.java:411 - Socket to /172.20.101.166 closed
DEBUG [GossipStage:1] 2019-07-11 18:19:23,374 FailureDetector.java:313 - Forcing conviction of /172.20.101.166
DEBUG [MessagingService-Outgoing-/172.20.101.166-Gossip] 2019-07-11 18:19:24,740 OutboundTcpConnection.java:425 - Attempting to connect to /172.20.101.166
INFO  [HANDSHAKE-/172.20.101.166] 2019-07-11 18:19:24,741 OutboundTcpConnection.java:561 - Handshaking version with /172.20.101.166
DEBUG [MessagingService-Outgoing-/172.20.101.166-Gossip] 2019-07-11 18:19:24,742 OutboundTcpConnection.java:533 - Done connecting to /172.20.101.166

验证查询

系统启动后,服务自然启动,能正常加入集群。

[email protected]> SELECT * from kevin_test.t_users; 

 user_id | emails                          | first_name | last_name
---------+---------------------------------+------------+-----------
       6 | {‘[email protected]‘, ‘[email protected]‘} |     kevin6 |      kang
       7 | {‘[email protected]‘, ‘[email protected]‘} |     kevin7 |      kang
       9 | {‘[email protected]‘, ‘[email protected]‘} |     kevin9 |      kang
       4 | {‘[email protected]‘, ‘[email protected]‘} |     kevin4 |      kang
       3 | {‘[email protected]‘, ‘[email protected]‘} |     kevin3 |      kang
       5 | {‘[email protected]‘, ‘[email protected]‘} |     kevin5 |      kang
       0 | {‘[email protected]‘, ‘[email protected]‘} |     kevin0 |      kang
       8 | {‘[email protected]‘, ‘[email protected]‘} |     kevin8 |      kang
       2 | {‘[email protected]‘, ‘[email protected]‘} |     kevin2 |      kang
       1 | {‘[email protected]‘, ‘[email protected]‘} |     kevin1 |      kang

测试结果:

反复重启节点,查询表内容正常。

原文地址:https://blog.51cto.com/michaelkang/2419524

时间: 2024-08-02 04:51:42

Cassandra集群管理-节点异常重启的相关文章

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

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

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

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

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

mysql集群管理维护日记

管理节点启动:#首次运行.备份或者config.ini配置变化时加--initial[[email protected] mysql-cluster]# /usr/local/mysql/bin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini --initial查看启动后的端口情况: [[email protected] mysql-cluster]#  netstat -lntpu 管理节点检验 [[email protected] /]# /usr

Ignite集群管理——基于静态IP的节点发现

Ignite作为分布式内存,集群管理必不可少,Ignite支持基于组播,静态IP,Zookeeper,JDBC等方式发现节点,本文主要介绍基于静态IP的节点发现. 两个最重要的TCP通信设置类: 1. TcpDiscoverySpi 用于设置集群维持与节点发现的tcp通信ip,port. 2. TcpCommunicationSpi 用于设置业务数据(缓存数据)tcp通信的ip,port. 3. 两者的区别与联系 TcpDiscoverySpi用于维持管理集群,交换的是用户不感知的ignite内

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

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

2 weekend110的zookeeper的原理、特性、数据模型、节点、角色、顺序号、读写机制、保证、API接口、ACL、选举、 + 应用场景:统一命名服务、配置管理、集群管理、共享锁、队列管理

在hadoop生态圈里,很多地方都需zookeeper. 启动的时候,都是普通的server,但在启动过程中,通过一个特定的选举机制,选出一个leader. 只运行在一台服务器上,适合测试环境:Zookeeper 的启动脚本在 bin 目录下:在启动脚本之前,还有几个基本的配置项需要配置一下, tickTime :这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每个  tickTime  时间就会发送一个心跳:dataDir:顾名思义就是 Zookee

Oracle12.2 RAC集群管理之增加删除节点_Oracle12cR2视频教程(项目实战之六)

一.课程主题 风哥Oracle数据库教程12cR2(项目实战之六):基于Linux操作系统的Oracle12.2 RAC集群的管理之增加删除节点(rac node add,rac node delete). Oracle12.2 RAC集群管理之增加删除节点_Oracle12cR2视频教程(项目实战之六) http://edu.51cto.com/course/10245.html 二.项目需求 由于业务需求,需要在原有一套ERP核心系统的RAC集群中增加或删除一个节点. 三.实施步骤 01.O