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

Question

假设我有两个节点cassandra集群，它们位于物理上不同的数据中心。假设该集群内的数据库具有复制因子，2这意味着该数据库中的每个数据都应该相互同步。假设这个数据库是一个庞大的数据库，它的表有数百万条记录。我将这些节点中心命名为node1和node2。假设node2不可靠，并且该服务器发生崩溃，需要几天时间才能修复并使服务器恢复正常运行状态。之后，根据我的理解，和之间应该有一个差距，node1并且node2可能需要很长时间才能node2与node1. 所以需要一种方法来衡量两者之间的差距node2和 node1 同步发生的平均时间？一段时间后，我应该如何确保node2等于node1？如果我根据 cassandra 架构对这个问题有误，请纠正我。

标签： cassandra

Answer 1

所以让我们从你的描述开始。2 节点集群，听起来不错，但在 2 个不同的数据中心 (DC) 中有 2 个节点 - 设计不佳，但可行。每个数据中心都应该有多个节点，以确保您的数据具有高可用性。无论如何，除此之外，假设您有一个 2 节点集群，每个 DC 中有 1 个节点。复制因子 (RF) 在键空间级别定义（而不是在集群级别 - 每个 DC 将具有特定键空间的 RF 设置（如果未为特定 DC 指定，则为 0））。话虽如此，如果每个 DC 中只有一个节点（RF，即存在的数据副本数，不能超过DC 中的节点数）。所以让我们暂时把它放在一边。

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

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

如果您想在查询运行时（读取数据时）确保数据一致，请确保写入 CL + 读取 CL > RF。您可以确保在 LOCAL 级别（例如，发生读/写的 DC，例如 LOCAL_QUORUM）或全局（所有具有 QUORUM 的 DC）上完成。通过这样做，您将确保虽然您的集群可能不一致，但您在读取期间的结果不会不一致（即结果将是一致/准确的——这是任何人真正关心的）。使用此设置，您还可以在不可用的节点中提供一些灵活性（例如，对于 3 节点 DC，您可以让单个节点不可用，而不会出现客户端读取或写入故障）。

如果节点确实变得不同步，此时您有几个选择：

修复
修复（由“nodetool repair”运行） - 这是一个您可以安排或手动运行的工具，以协调您的表、键空间和/或整个节点与其他节点（在节点所在的 DC 中或整个集群中） . 这是一个“节点级别”命令，必须在每个节点上运行才能“修复”问题。如果您有 DSE，Ops Center 可以在后台运行修复“块”数据 - 重复循环该过程。

NodeSync
与修复类似，这是一个类似于修复的特定于 DSE 的工具，可帮助保持数据同步（修复的较新版本）。

不可用节点：

如果节点在写入期间变得不可用，则提示切换Cassandra 能够“保留”更改。它将在指定的时间段内挂起更改。如果不可用的节点在时间用完之前变得可用，则将更改发送给应用程序。如果时间用完，提示收集将停止，并且需要执行上述其他选项之一以赶上进度。

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

希望这是有道理的并有所帮助。

-吉姆