Cassandra是否阻止现有数据中心在重新加入群集时提供读取请求？

Question

我知道Cassandra非常聪明，在新节点被引导并加入群集之前不会提供任何读取请求，直到所有数据都被复制到节点。

问题是，对于重新加入群集的现有数据中心，Cassandra的行为是否相同？具体针对以下场景：

如果我有2个DC，DC1用于所有读/写，DC2仅用于备份。如果DC1关闭并且DC2接管所有写入。当DDC1现在回来时，Cassandra会阻止DC1读取请求，直到所有数据都被完全复制。

Answer 1

  

问题是，对于重新加入群集的现有数据中心，Cassandra的行为是否相同？

如果您遵循标准数据中心构建过程，其中空节点是站立的，然后通过nodetool rebuild进程流式传输数据，则答案是“不一定”。重建节点与引导节点的工作方式不同，因此，它仍可能尝试为请求提供服务。

当然，硬币的另一面是，你的应用程序团队不应该部署或激活任何默认或“粘性”到新的或“重新加入”数据中心的服务，直到你给他们好的。这就是为什么所有客户端应用程序都应指定默认数据中心，并使用NetworkTopologyStrategy作为其键空间的原因之一。

  

如果我有2个DC，DC1用于所有读/写，DC2仅用于备份。如果DC1关闭并且DC2接管所有写入。当DC1现在回来时，Cassandra会阻止DC1读取请求，直到所有数据完全复制完毕吗？

在这种情况下，答案是“否”，它不会阻止DC1提供请求。如果应用程序对DC1是粘性的，并且它存在，它将为请求提供服务，无论其数据是否不同步。如果是我，我会使用Reaper确保在DC1上运行修复，并告诉我的应用程序团队将其应用程序/服务配置为仅使用DC2，直到另有说明。