cassandra - 向集群添加新节点时如何避免查询耗时过长

Question

我发现在向集群添加新节点时查询(只是一个简单的选择查询)需要很长时间。

我的执行时间日志:

17:49:40.008 [ThreadPoolTaskScheduler-14] INFO  task.DiskCounting - void task.DiskCounting.runJob()  executed in 8 ms
17:50:00.010 [ThreadPoolTaskScheduler-3] INFO  task.DiskCounting - void task.DiskCounting.runJob()  executed in 15010 ms
17:50:15.008 [ThreadPoolTaskScheduler-4] INFO  task.DiskCounting - void task.DiskCounting.runJob()  executed in 10008 ms
17:50:20.008 [ThreadPoolTaskScheduler-16] INFO  task.DiskCounting - void task.DiskCounting.runJob()  executed in 7 ms

正常情况下需要10ms左右，添加节点时突然需要15000ms。

我发现它因为等待新的节点初始化数据而卡住了

Cassandra 日志(新节点):

INFO  [HANDSHAKE-/194.187.1.52] 2019-05-31 17:49:36,056 OutboundTcpConnection.java:560 - Handshaking version with /194.187.1.52
INFO  [GossipStage:1] 2019-05-31 17:49:36,059 Gossiper.java:1055 - Node /194.187.1.52 is now part of the cluster
INFO  [RequestResponseStage-1] 2019-05-31 17:49:36,069 Gossiper.java:1019 - InetAddress /194.187.1.52 is now UP
INFO  [GossipStage:1] 2019-05-31 17:49:36,109 TokenMetadata.java:479 - Updating topology for /194.187.1.52
INFO  [GossipStage:1] 2019-05-31 17:49:36,109 TokenMetadata.java:479 - Updating topology for /194.187.1.52
INFO  [MigrationStage:1] 2019-05-31 17:49:39,347 ViewManager.java:137 - Not submitting build tasks for views in keyspace system_traces as storage service is not initialized
INFO  [MigrationStage:1] 2019-05-31 17:49:39,352 ColumnFamilyStore.java:411 - Initializing system_traces.events
INFO  [MigrationStage:1] 2019-05-31 17:49:39,382 ColumnFamilyStore.java:411 - Initializing system_traces.sessions

卡住时间:节点/194.187.1.52 现在是集群的一部分

客户端将等待新节点初始化所有数据

我尝试过的:

1. I try use consistency with ONE or QUORUM, and is no difference

2. I try turn replication factor to 1, 2 or 3, and still no difference

为什么当新节点没有完全初始化数据时新节点成为集群的一部分。

有什么办法可以解决吗

我希望当我查询旧节点时，性能不会因为等待新节点初始化数据而受到影响。

---

...

我解决了这个问题。

我写错了配置，我让所有节点在加入集群之前就成为种子，这导致在向集群添加新节点时读取超时。

修复后。所有读取都正常，但不知何故我发现在添加节点时插入查询超时。

最后我调整它以避免插入超时:

/sbin/sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=5

同时更改 conf 以限制吞吐量

stream_throughput_outbound_megabits_per_sec : 100

非常感谢您的帮助。

Answer 1

这只是一种理论，但一个可能的原因是新节点被您的驱动程序客户端选择为协调器，在这种情况下，一致性级别和复制不是导致延迟的主要因素为您的查询提供服务。

如果新节点最初由于某种原因执行缓慢并且驱动程序正在向它发送请求，协调器的行为可能会影响您的请求服务。

runJob 到底在做什么？您建议它进行单个查询，但它有可能是范围查询吗？

如果它是一个单一的查询，并且它花费了 10 秒之久，这似乎很奇怪，因为默认的 read_request_timeout 是 5 秒。如果是范围查询(涉及多个分区的读取)，默认是10秒。您是否正在调整这些超时？

当您看到对单个查询的响应很长时，这可能意味着协调器正在阻碍响应能力，否则如果协调器响应迅速而副本很慢，您会看到 ReadTimeoutException 消息得到服务给客户。

为了更好地应对这些情况，许多客户端驱动程序实现了一种称为“推测执行”的策略。如 documentation for the DataStax Java Driver for Apache Cassandra 中所述:

Sometimes a Cassandra node might be experiencing difficulties (ex: long GC pause) and take longer than usual to reply. Queries sent to that node will experience bad latency.

One thing we can do to improve that is pre-emptively start a second execution of the query against another node, before the first node has replied or errored out. If that second node replies faster, we can send the response back to the client (we also cancel the first execution – note that “cancelling” in this context simply means discarding the response when it arrives later, Cassandra does not support cancellation of in flight requests at this stage)

您可以将您的驱动程序配置为推测性地执行幂等请求(例如读取请求)的恒定阈值。在 3.x java 驱动程序中，它是这样完成的:

Cluster cluster = Cluster.builder()
  .addContactPoint("127.0.0.1")
  .withSpeculativeExecutionPolicy(
    new ConstantSpeculativeExecutionPolicy(
      500, // delay before a new execution is launched
      2    // maximum number of executions
  ))
  .build();

在这种情况下，如果协调器响应缓慢，则在 500 毫秒后驱动程序选择另一个协调器并提交第二个任务，并且第一个响应的协调器获胜。

请注意，这可能会导致发送到您的集群的整体请求数量增加，因此您希望调整该延迟，使其仅在响应时间高度异常时才会启动。在您的情况下，如果请求通常花费的时间少于 10 毫秒，则 500 毫秒可能是一个合理的数字，具体取决于您的较高百分位数延迟情况。

综上所述，如果您能够确定问题是新节点作为协调器表现不佳。值得理解为什么。添加推测执行可能是解决该问题的好方法，但最好尝试了解为什么新节点执行如此缓慢。通过适当的监控来观察 Cassandra 的指标可能会给问题带来很大的可见性。