如何从失败的引导中恢复Cassandra节点

Question

在启动一个新节点时，有一个节点宕机了，导致引导过程失败。该节点关闭，日志中留下以下消息：

INFO  [main] 2015-02-07 06:03:32,761 StorageService.java:1025 - JOINING: Starting to bootstrap...
ERROR [main] 2015-02-07 06:03:32,799 CassandraDaemon.java:465 - Exception encountered during startup
java.lang.RuntimeException: A node required to move the data consistently is down (/10.0.3.56).  If you wish to move the data from a potentially inconsistent replica, restart the node with -Dcassandra.consistent.rangemovement=false

如何恢复这种情况？当失败的节点重新上线后，我可以重新启动引导过程吗？还是需要撤销部分引导并尝试其他方式？

我已经找到了原因。新节点能够连接到10.0.3.56节点，但10.0.3.56无法打开回到新节点的连接。10.0.3.56包含一些需要移动到新节点的数据的唯一副本（复制因子==1），但它发送数据的尝试被阻止了。

- stub

---

你是在尝试替换一个已经失效的节点吗？ - Roman Tumaykin

不，这是在添加一个新节点。现有的keyspace之一使用了复制因子1，并且包含需要移动到新节点的唯一数据副本的某个节点不可用。 - stub

Answer 1

由于这涉及到数据移动，而不仅仅是复制，并且根据代码中抛出异常的位置，我认为您正在尝试替换一个死节点，如此描述在这里：http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html 从外观上看，该节点没有加入环。您可以通过运行nodetool status来进行双重检查，是否有节点已经加入。

如果没有，则可以简单地从数据、commitlog和saved_caches中删除所有内容，然后重新启动进程。那个10.0.2.56节点出了什么问题？

如果这个节点已经加入了环，那么一旦启动节点10.0.2.56，它仍然应该是安全的，只需简单地重新启动即可。

- Roman Tumaykin

---

这是一个新增加到集群中的新节点。系统键空间已从磁盘中清除，并启动服务指向一个可访问的实时种子节点。 - stub

仔细查看我的日志后，我认为.56节点从未可联系（或者如果一开始它是可联系的，在过程中防火墙切断了访问）。 - stub

该节点成功加入了环。从种子节点运行的“nodetool status”显示它为UN状态，并包含其系统认证keyspace的一部分，我也可以在磁盘上看到这些数据。 - stub

在这种情况下，您可以简单地重新启动节点。 - Roman Tumaykin

当我启动一个全新的Cassandra环时，我遇到了这个问题。一些节点可能无法加入环并抛出此错误。是的，我可以重新启动服务，它会起作用，但是否有任何解决此行为的方法？ - Sean Glover