Cassandra 读取一致性一，受其他节点影响？

Question

我正在使用 NetworkTopologyStrategy 和 PropertyFileSnitch 在 4 个 DC 上测试 Cassandra 2.0 的部署。每个 DC 的复制配额为 1，表示每个 DC 都有完整的数据库。 我的键空间配置为一致性“一”读取。这意味着（据我了解）客户端可以在本地获取数据，如果它可用而不执行任何仲裁等。

不幸的是，我的测试结果表明并非如此。如果我人为地（使用 MiniNet）增加其中一个 DC 的延迟，我可以看到我在其他 DC 上的读取速度显着减慢（与延迟成正比，超过 dynamic_snitch_badness_threshold）。

在这个测试期间，我没有写入任何数据，我只是在执行读取。请注意，如果我完全断开其中一个节点的连接，我的性能将恢复到 100%。

因此我有 2 个问题，1.为什么当我执行一致性一次读取时，一个 DC 会降低整个系统的性能。以及 2. 为什么 Dynamic snytch 不会将通信从性能不佳的节点重新路由（默认设置，测试 20 多分钟）。

问候。

编辑： 所以这是我到目前为止的一系列行动。 当我创建表时，我添加了这个：with read_repair_chance = 0 and speculative_retry='NONE';

问题：当我使用 cqlsh 控制台时，我可以读取当前的一致性级别，并且可以根据文档设置 LOCAL_ONE。但是新的设置是不持久的，当我退出cqlsh再进入时，又可以看到默认的一致性ONE了。好像是按会话设置的？

我在慢速节点上运行 nodetool netstat，我看到没有修复尝试但有一些响应？？

Mode: NORMAL
Not sending any streams.
Read Repair Statistics:
Attempted: 0<<-----------
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool Name                    Active   Pending      Completed
Commands                        n/a         0              0
Responses                       n/a         0           3807<<------------

Answer 1

1) 根据您的读取负载，即使您使用 LOCAL_ONE 或 LOCAL_QUORUM，您也可能会导致其他数据中心的节点上的一些负载来自读取修复。尝试查看 nodetool tpstats 的输出，看看节点是否正在执行大量读取修复。如果是这样，请尝试通过将其设置为零来关闭 CF 的 read_repair_chance。

要观察上述行为，请启用 DEBUG 日志记录并查找如下行：

ReadCallback.java（第 79 行）Blockfor 是 ....

它应该通过向其他 DC 中的节点发送请求来告诉您请求是否被阻止，可能是由于 read_repair。

2) 动态告密者有一个重置间隔。这意味着无论过去的历史如何，它都会重置它为每个节点的延迟捕获的分数。在 snitch 重置后，您可能会观察到查询路由到慢速节点。

Answer 2

1) 的答案是“一个”需要单个响应，但不要求协调器将请求路由到本地 dc。为此，请使用“LOCAL_ONE”。这可以保证您的读取不会跨直流。

LOCAL_ONE 在 Cassandra 1.2.11 和 2.0.2 及更高版本中可用。一个写 必须发送给至少一个并由其成功确认 本地数据中心的副本节点。在多数据中心 集群，通常需要 ONE 的一致性级别，但跨 DC 交通不是。 LOCAL_ONE 实现了这一点。为了安全和质量 原因，您可以在离线数据中心使用此一致性级别 防止自动连接到其他数据中心的在线节点 如果离线节点出现故障。

http://www.datastax.com/documentation/cassandra/2.0/webhelp/cassandra/dml/dml_config_consistency_c.html

尝试跟踪一些请求以获取有关 C* 如何执行查询的更多信息。 http://www.datastax.com/dev/blog/tracing-in-cassandra-1-2