Cassandra 节点如何看到另一个节点已关闭?

Hub*_*iak 6 cassandra

我在三个节点上运行 Cassandra。这是他们的nodetool status输出:

ubuntu@ip-10-0-8-8:~$ nodetool status
Datacenter: us-east
===================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns    Host ID                               Rack
UN  10.0.9.8   2.07 MB    256     ?       c8d574b9-540c-410f-9326-789eb75d3d14  1c
UN  10.0.8.8   2.06 MB    256     ?       d9454056-a358-4428-ab5f-c03e8042167e  1d
UN  10.0.10.8  2.01 MB    256     ?       3617643d-b0a8-4b72-a9d4-feded4445292  1a
Run Code Online (Sandbox Code Playgroud)
ubuntu@ip-10-0-9-8:~$ nodetool status
Datacenter: us-east
===================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns    Host ID                               Rack
UN  10.0.9.8   2.07 MB    256     ?       c8d574b9-540c-410f-9326-789eb75d3d14  1c
UN  10.0.8.8   2.06 MB    256     ?       d9454056-a358-4428-ab5f-c03e8042167e  1d
DN  10.0.10.8  2.09 MB    256     ?       3617643d-b0a8-4b72-a9d4-feded4445292  1a
Run Code Online (Sandbox Code Playgroud)
ubuntu@ip-10-0-10-8:~$ nodetool status
Datacenter: us-east
===================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens  Owns    Host ID                               Rack
UN  10.0.9.8   2.07 MB    256     ?       c8d574b9-540c-410f-9326-789eb75d3d14  1c
UN  10.0.8.8   2.06 MB    256     ?       d9454056-a358-4428-ab5f-c03e8042167e  1d
UN  10.0.10.8  2.01 MB    256     ?       3617643d-b0a8-4b72-a9d4-feded4445292  1a
Run Code Online (Sandbox Code Playgroud)

除了一件事(第二个块的最后一行)外,一切看起来都很好:

DN  10.0.10.8  2.09 MB    256     ?       3617643d-b0a8-4b72-a9d4-feded4445292  1a
Run Code Online (Sandbox Code Playgroud)

D该行的开始指示节点关闭。怎么会10.0.9.8看到节点关闭而其他节点看到它就好了?这会导致不一致吗?

顺便说一下,使用 Cassandra 2.1.1 版。

Aar*_*ron 3

八卦协议负责让节点了解所有其他节点的状态。我过去曾见过这样的情况:一个节点(无论出于何种原因)将某个节点视为“DN”,而其他节点则不然。通常,这种情况发生在云环境中,并且通常是由网络事件或不一致引起的。

这会导致不一致吗?

是的!将 10.0.10.8 视为“DN”的节点不会向其复制数据。假设这种情况已经超过 3 小时,他们也会停止记录提示。

为了快速解决方案,我会在 10.0.10.8 和 10.0.9.8 上反弹 Cassandra 进程。当它返回时,跟踪 system.log 文件并确保它与所有其他节点正确连接。

如果这不起作用,phi_convict如果您位于云中(在所有节点上),请尝试将 (cassandra.yaml) 设置为 10 或 12。这将使您的节点对由于网络延迟而被标记为“DN”有更多的容忍度。

另一件需要注意的事情是仔细检查您的云可用性区域中是否存在问题节点。一个云可用区中的节点可能在网络方面表现不同。因此,如果您发现这些问题是某个可用区特有的,您可能需要联系您的云提供商解决此问题。

如果仍然没有回来,请擦除节点的数据并重新引导它。请注意,当您确实将集群恢复为完整的“UN”时,您应该在被视为“DN”的节点上运行修复。

使用 Cassandra 版本 2.1.1

我会立即升级它。如果您坚持使用 2.1 版本,则至少应该使用最新的补丁版本(用于错误修复)2.1.18。但自 2.1.1 以来进行了许多修复和改进,这可能会导致此问题。