Нужна помощь в понимании того, что происходит с Cassandra при попытке восстановить nodetool в одном из семейств столбцов в нашем пространстве ключей.
Мы запускаем 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)
)
Ряды могут вырасти до довольно больших размеров. У нас примерно 10 миллионов объектов в базе данных со средним числом 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». Мы написали сценарий, который выполнил восстановление поддиапазона, и я могу определить проблемные диапазоны, но я не провел достаточного тестирования, чтобы узнать, является ли это постоянным или симптоматическим. Когда производительность падает, тестирование оказывается трудным, поэтому я должен быть осторожен.
Вопрос на боковой панели ... как остановить текущий ремонт? Если я вижу, что дела идут не так, как надо, я бы хотел это остановить.
Обратите внимание, что все остальные семейства столбцов в пространстве ключей исправляются нормально.
Я не уверен, что еще рассказать. Мы бились об этом в течение недели и, ну, мы застряли.
