Cassandra学习笔记 --- 关于Cassandra的节点通讯机制——Gossip
2016-11-25 15:48
826 查看
Cassandra的集群内部用一种叫做gossip的协议来做位置发现和状态信息共享。gossip在国内听别人翻译为“流言协议”,是一种p2p通信协议,通过这个协议,Cassandra节点之间定期地交换自己和自己已知节点的状态信息。这样,节点信息就能像现实中的流言一样迅速扩散出去。
为种子节点)。这些信息是必须在每个节点的cassandra.yaml里配置的。
gossip是局部持久化信息,并且是节点一重启就立即生效使用。为了清除gossip历史记录重启(例如更换节点IP等情况),需要在/usr/share/cassandra或者 <install_location>/conf下的cassandra-env.sh中添加如下信息:
-Dcassandra.load_ring_state=false
为了阻止gossip分区通信,所有节点配置文件中的种子列表必须相同。
注意:gossip除了在新节点加入集群的时候自举使用外,并无别的目的。因此种子节点不存在单点故障问题
故障检查是根据gossip历史记录局部决策的,Cassandra根据gossip历史记录信息来防止访问宕机的节点。 (Cassandra亦能通过dynamic
snitch减少访问性能较差的节点.)。
gossip进程可以通过直接(gossip直接通话)或者间接(gossip从直接通话的节点中获取)获取其他节点状态信息。Cassandra不是通过一个固定阈值来判定节点存活的,Cassandra使用权责发生制的检测机制来计算每个节点的阈值,这个机制会考虑到网络性能、工作量等条件。在gossip中,每个节点维护一个滑动窗口来标记其他节点的gossip到达时间。在Cassandra,可以配置phi_convict_threshold属性来调整的故障检测器的灵敏度。在大多数情况下,使用默认值,但对亚马逊EC2(由于频繁地遇到网络拥塞),需要将该值提高到12。
节点故障可能由各种原因引起,如硬件故障和网络中断。这种往往是暂时的,但可以持续延长的时间间隔。集群中一个节点出现故障并不是意味着该节点永久离开,因此Cassandra不会从环中自动永久删除该节点。其他节点的gossip会周期性地尝试通信,看看他们是否恢复。管理员可以使用nodetool工具从集群中永久删除一个节点。
当一个节点重新联机中断后,可能已经错过了它维护的副本数据,一旦故障检测器标记节点宕机,错过的数据均以hinted handoff的方式由邻居节点以hinted handoff的方式保存。如果一个节点宕机时间超过max_hint_window_in_ms(默认为3小时),hinted handoff将不再保留。由于节点宕机的时候可能已经存储有未交付的hinted handoff,你应该运行修复工具来恢复宕机时间较长的节点。此外,你应该定期运行nodetool维护所有节点,以确保它们具有一致的数据。
1.关于集群节点和种子节点(Seed)
当一个节点启动的时候,它会从配置文件中读取配置信息,这样它就知道它属于哪个集群,它需要跟哪个节点通信以获取其他节点信息(这个通信节点称为种子节点)。这些信息是必须在每个节点的cassandra.yaml里配置的。
2.配置Gossip
属性 | 描述 |
---|---|
cluster_name | 节点加入的集群名,集群内所有节点均应该相同。 |
listen_address | 别的节点与该节点通信的IP地址,即应该配置为当前节点的IP。默认为localhost,应该改为普通IP地址。 |
seed_provider | gossip用来获取整个环(集群)拓扑信息的种子节点IP列表。集群内所有节点的种子节点都应该相同,并且在多数据中心的集群中,每个数据中心至少要有一个种子节点在列表中。 |
storage_port | 集群内部节点的通信端口(默认为7000),整个集群内部必须全部相同。 |
initial_token | 在1.1之前用来决定节点负责的数据范围。 |
num_tokens | 在1.2之后用来决定节点负责的数据范围。 |
3.清除节点Gossip
gossip是局部持久化信息,并且是节点一重启就立即生效使用。为了清除gossip历史记录重启(例如更换节点IP等情况),需要在/usr/share/cassandra或者 <install_location>/conf下的cassandra-env.sh中添加如下信息:-Dcassandra.load_ring_state=false
为了阻止gossip分区通信,所有节点配置文件中的种子列表必须相同。
注意:gossip除了在新节点加入集群的时候自举使用外,并无别的目的。因此种子节点不存在单点故障问题
4.关于故障检查和恢复
故障检查是根据gossip历史记录局部决策的,Cassandra根据gossip历史记录信息来防止访问宕机的节点。 (Cassandra亦能通过dynamicsnitch减少访问性能较差的节点.)。
gossip进程可以通过直接(gossip直接通话)或者间接(gossip从直接通话的节点中获取)获取其他节点状态信息。Cassandra不是通过一个固定阈值来判定节点存活的,Cassandra使用权责发生制的检测机制来计算每个节点的阈值,这个机制会考虑到网络性能、工作量等条件。在gossip中,每个节点维护一个滑动窗口来标记其他节点的gossip到达时间。在Cassandra,可以配置phi_convict_threshold属性来调整的故障检测器的灵敏度。在大多数情况下,使用默认值,但对亚马逊EC2(由于频繁地遇到网络拥塞),需要将该值提高到12。
节点故障可能由各种原因引起,如硬件故障和网络中断。这种往往是暂时的,但可以持续延长的时间间隔。集群中一个节点出现故障并不是意味着该节点永久离开,因此Cassandra不会从环中自动永久删除该节点。其他节点的gossip会周期性地尝试通信,看看他们是否恢复。管理员可以使用nodetool工具从集群中永久删除一个节点。
当一个节点重新联机中断后,可能已经错过了它维护的副本数据,一旦故障检测器标记节点宕机,错过的数据均以hinted handoff的方式由邻居节点以hinted handoff的方式保存。如果一个节点宕机时间超过max_hint_window_in_ms(默认为3小时),hinted handoff将不再保留。由于节点宕机的时候可能已经存储有未交付的hinted handoff,你应该运行修复工具来恢复宕机时间较长的节点。此外,你应该定期运行nodetool维护所有节点,以确保它们具有一致的数据。
相关文章推荐
- 关于Cassandra的节点通讯机制——Gossip
- 第二部分 关于Cassandra1.0.x节点间通讯《草稿》
- Cassandra1.2文档学习(2)——节点间通信协议之gossip协议
- 2011年Android IPC进程间通讯机制学习笔记之一
- 学习笔记 --- LINNUX 使用异步通讯机制实现按键驱动代码分析
- Android IPC进程间通讯机制学习笔记
- JAVA学习笔记_关于异常机制处理问题
- Android IPC进程间通讯机制学习笔记
- Android Binder 机制初步学习 笔记(三)—— Binder 进程通讯库简介
- 【C学习笔记】【疑问】关于const常量的实现机制在C和C++中的不同
- Android IPC进程间通讯机制学习笔记
- Cassandra学习笔记之Gossip协议
- 学习笔记:关于对下属的批评和赞扬
- python(异常处理机制,学习笔记摘要)
- 计算机学习笔记2:关于微程序的一点己见
- 关于朴素贝叶斯分类的学习笔记
- java学习笔记,关于java的一些基础知识,适用于初学者,第一节
- RTTI关于dynamic_cast的学习笔记(1)
- 关于用jsp实现http认证安全登陆的学习笔记。(正在原创ing)
- 关于JDBC学习笔记(一)