什么会导致节点间的断断续续的八卦问题？

Question

Cassandra集群大部分是可运行的，有时会遇到服务中断，特别是当一个(或多个)节点无法与集群中的其他节点闲聊时。

症状

一种症状是节点在没有明显原因的情况下随机上升和下降。下面是从节点的system.log中提取的一个示例：

INFO  [GossipTasks:1] 2016-04-29 02:47:32,559  Gossiper.java:1001 - InetAddress /10.1.2.3 is now DOWN
INFO  [GossipTasks:1] 2016-04-29 02:50:47,123  Gossiper.java:1001 - InetAddress /10.1.2.4 is now DOWN
INFO  [GossipTasks:1] 2016-04-29 02:54:59,640  Gossiper.java:1001 - InetAddress /10.1.2.5 is now DOWN
INFO  [SharedPool-Worker-2] 2016-04-29 03:01:23,828  Gossiper.java:987 - InetAddress /10.1.2.4 is now UP
INFO  [SharedPool-Worker-1] 2016-04-29 03:01:59,432  Gossiper.java:987 - InetAddress /10.1.2.5 is now UP
INFO  [SharedPool-Worker-7] 2016-04-29 03:02:01,839  Gossiper.java:987 - InetAddress /10.1.2.3 is now UP

类似地，在nodetool status输出中似乎有不同的节点，这取决于运行命令的节点，例如：

Datacenter: Cassandra
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address   Load       Tokens  Owns    Host ID                               Rack
DN  10.1.2.3  8.97 GB    256     ?       a50dfef5-229d-4d15-89d9-971bec01094b  rack1
UN  10.1.2.5  8.9 GB     256     ?       a16b71a2-9b95-4669-a6bd-d7326bd279e2  rack1
DN  10.1.2.4  9.09 GB    256     ?       ac01b6f9-3cb9-47ff-83c6-0404836386eb  rack1
UN  10.1.2.6  10.65 GB   256     ?       9c0ef3a2-aad7-4d06-b015-f32ddccac750  rack1

是什么引起了这个问题？

Answer 1

致

有关这一问题的个别报告以非常小的分组形式出现。上面描述的症状已被确定为与配置了GossipingPropertyFileSnitch (GPFS)的集群有关，但与conf/目录中的cassandra-topology.properties (用于PropertyFileSnitch)的副本以及用于定义节点架位置的cassandra-rackdc.properties一起使用。

GPFS与cassandra-topology.properties的组合可以在启动消息日志中验证：

INFO  [main] 2013-02-17 15:31:26,039  GossipingPropertyFileSnitch.java:63 - \
  Loaded cassandra-topology.properties for compatibility

重要的是要注意到这个问题是非常断断续续的，并不是所有触发这个问题的向量都知道。

解决方案

通过设计，GossipingPropertyFileSnitch回到了PropertyFileSnitch的S cassandra-topology.properties上，作为允许集群迁移到GPFS的一种方式。

如果集群已经在GossipingPropertyFileSnitch上，请检查cassandra-topology.properties是否已被删除或不存在，即使节点没有问题，以确保集群将来不会遇到问题。

有关更多信息，请参见卡桑德拉-11508。干杯!