在我们的密钥空间中的某个列系列上尝试进行nodetool修复时,需要帮助了解Cassandra发生了什么。
我们正在运行Cassandra 2.0.7并且有一个表用于索引系统中的对象数据。
CREATE TABLE ids_by_text (
object_type text,
field_name text,
ref_type text,
value text,
ref_id timeuuid,
PRIMARY KEY((object_type,field_name,ref_type),value,ref_id)
)
行可以变得非常大。我们在数据库中有大约1000万个对象,平均有4-6个字段通过上表对它们进行索引。这对我来说似乎并不多。
运行nodetool修复时,我们将运行一段时间,然后点击引发以下异常的点:
ERROR [AntiEntropySessions:8] 2014-07-06 16:47:48,863 RepairSession.java (line 286) [repair #5f37c2e0-052b-11e4-92f5-b9bfa38ef354] session completed with the following error
org.apache.cassandra.exceptions.RepairException: [repair #5f37c2e0-052b-11e4-92f5-b9bfa38ef354 on apps/ids_by_text, (-7683110849073497716,-7679039947314690170]] Sync failed between /10.0.2.166 and /10.0.2.163
at org.apache.cassandra.repair.RepairSession.syncComplete(RepairSession.java:207)
at org.apache.cassandra.service.ActiveRepairService.handleMessage(ActiveRepairService.java:236)
at org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:59)
at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:60)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
INFO [ScheduledTasks:1] 2014-07-06 16:47:48,909 GCInspector.java (line 116) GC for ConcurrentMarkSweep: 66029 ms for 1 collections, 7898896176 used; max is 8547991552
INFO [GossipTasks:1] 2014-07-06 16:47:48,901 Gossiper.java (line 883) InetAddress /10.0.2.162 is now DOWN
INFO [GossipTasks:1] 2014-07-06 16:47:49,181 Gossiper.java (line 883) InetAddress /10.0.2.163 is now DOWN
INFO [GossipTasks:1] 2014-07-06 16:47:49,184 StreamResultFuture.java (line 186) [Stream #da84b3e1-052b-11e4-92f5-b9bfa38ef354] Session with /10.0.2.163 is complete
WARN [GossipTasks:1] 2014-07-06 16:47:49,186 StreamResultFuture.java (line 215) [Stream #da84b3e1-052b-11e4-92f5-b9bfa38ef354] Stream failed
INFO [GossipTasks:1] 2014-07-06 16:47:49,187 Gossiper.java (line 883) InetAddress /10.0.2.165 is now DOWN
INFO [GossipTasks:1] 2014-07-06 16:47:49,188 Gossiper.java (line 883) InetAddress /10.0.2.164 is now DOWN
INFO [GossipTasks:1] 2014-07-06 16:47:49,189 Gossiper.java (line 883) InetAddress /10.0.2.166 is now DOWN
INFO [GossipTasks:1] 2014-07-06 16:47:49,189 StreamResultFuture.java (line 186) [Stream #da84b3e0-052b-11e4-92f5-b9bfa38ef354] Session with /10.0.2.166 is complete
WARN [GossipTasks:1] 2014-07-06 16:47:49,189 StreamResultFuture.java (line 215) [Stream #da84b3e0-052b-11e4-92f5-b9bfa38ef354] Stream failed
此时,其他节点将无响应,抛出TPStatus日志并且基本上没有响应。系统无法从中恢复。我们死了。
我经历了“nodetool scrub'在所有节点上。大部分都有效,有些失败了,所以我使用了sstablescrub'在他们。我们编写了一个执行子范围修复的脚本,我可以确定有问题的范围,但我还没有做足够的测试来确定这是一致的还是有症状的。当它降低产量时,测试很难,所以我必须谨慎。
补充栏问题...你如何停止正在进行的维修?如果我能看到横向发生的事情,我想阻止它。
请注意,键空间中的每个其他列族都可以修复。
我不确定要提供的其他细节。我们一直在打击这个问题一个星期,而且,我们已经陷入困境。
答案 0 :(得分:1)
此(https://issues.apache.org/jira/browse/CASSANDRA-7330)可能与修复失败后的无响应有关。它已在最新的2.0.9版本中修复。
你如何停止正在进行的维修?
它仍在进行中(https://issues.apache.org/jira/browse/CASSANDRA-3486)。
答案 1 :(得分:1)
您可以在2.1。*中停止修复,如下所示:
$this->validate($request, [
'value.*' => 'max:30'
]);
...
for ($i=0; $i < $count ; $i++) {
// save etc
}