如何确定Cassandra集群中特定节点的同步状态是最新的？

Question

假设我有两个节点cassandra集群，它们驻留在物理上不同的数据中心。假设集群中有复制因子的数据库是2，这意味着数据库中的每个数据都应该彼此同步。假设这个数据库是一个庞大的数据库，它拥有数百万表的记录。我将这些节点中心命名为node1和node2。假设node2不可靠，并且该服务器上出现了崩溃，需要几天时间才能修复并使服务器恢复正常运行状态。在此之后，根据我低估的说法，node1和node2之间应该存在差距，可能需要大量的时间来同步node2和node1。那么，是否需要一种方法来测量node2和node1之间的平均同步时间呢？过了一些时候，我该如何确保node2与node1相等？请纠正我的问题，如果我错了，根据卡桑德拉建筑。

Answer 1

让我们从你的描述开始。两个节点集群，这听起来不错，但2个节点在两个不同的数据中心(DC)-糟糕的设计，但可行。每个数据中心应该有多个节点，以确保您的数据是高度可用的。无论如何，撇开这一点，让我们假设您有一个2节点集群，每个DC中有1个节点。复制因子( RF )是在键空间级别(而不是在集群级别)定义的-每个DC将具有特定密钥空间的RF设置(如果没有为特定DC指定的话则为0)。尽管如此，如果每个DC中只有一个节点(RF，即存在的数据的拷贝数，不能超过DC中的节点数量)，则不能为任何DC的任何一个DC提供密钥空间。所以让我们暂时把它放在一边吧。

您有可能使DC变得不同步，以及DC中的节点变得不同步。针对这一问题有多种保护措施。

一致性水平(CL)

这是一个杠杆，你(客户)必须能够帮助控制有多远的不同步的事情。在可用性与一致性之间存在一种权衡(同时具有性能方面的影响)。CL设置是在连接时和/或每个语句级别配置的。对于写操作，CL确定有多少节点必须立即确认写入，然后才给应用程序“绿灯”才能继续前进(您对许多节点感到满意--知道您立即需要的节点越多，您的节点和/或DC(s)就越一致，但它所需的时间越长，并且您在没有客户端故障的情况下变得不可用时的灵活性就越小)。如果你指定的比RF少，这并不意味着RF不会被满足，它只是意味着他们不需要立即承认写才能继续。对于读取，此设置确定在返回结果之前比较了多少节点的数据(如果cassandra发现某个特定行与它正在比较的节点不匹配，则在得到结果之前，它将在读取期间“修复”它们--这称为读修复)。客户端有少量的CL选项(例如，一个、仲裁、LOCAL_ONE、LOCAL_QUOURM等)。同样，在可用性和与所选选择的一致性之间也存在一种权衡。

如果希望确保查询运行时(读取数据时)数据是一致的，请确保写入CL + read > RF。您可以确保这是在本地级别(例如读/写发生在LOCAL_QUORUM上的DC )或全局(具有法定量的所有DC)上完成的。通过这样做，您将确保集群可能不一致，但读取期间的结果不会是不一致的(也就是说，结果将是一致的/准确的--这是所有人真正关心的)。使用此设置，您还允许在不可用节点中具有一定的灵活性(例如，对于一个3节点DC，您可以让单个节点不可用，而不会出现客户端读写失败)。

如果节点确实不同步，那么此时有几个选项：

修复

修复(由"nodetool修复“运行)--这是一种可以安排或手动运行的工具，用于协调表、键空间和/或整个节点与其他节点(无论是在DC节点中，还是在整个集群中)。这是一个“节点级”命令，必须在每个节点上运行才能“修复”。如果您有DSE，操作中心可以运行修复在后台修复“块”的数据-重复循环的过程。

NodeSync

类似于修复，这是一个DSE特定的工具，类似于修复，它有助于保持数据同步(更新版本的修复)。

不可用节点：

暗示汉道夫

如果节点在写过程中不可用，Cassandra可以“保持”更改。它将在一段特定的时间内保持不变。如果不可用节点在时间耗尽之前可用，则将更改发送给应用程序。如果时间不多，提示收集就会停止，上面的其他选项之一需要执行才能完成。

最后，没有办法知道事情有多不一致(例如30%的不一致)。您只需尝试利用上述工具来控制一致性，而不完全牺牲可用性。

希望这是有意义的，也是有帮助的。

-Jim