Cassandra 'nodetool repair -pr' занимает слишком много времени

Я использую кластер с установленным 1 центром обработки данных (10 узлов) и Cassandra 2.1.7 на каждом. Мы используем SimpleStretegy (старая ошибка).

Ситуация такова, что я не выполнял никаких ремонта nodetool с самого начала, и теперь есть данные примерно 200 ГБ с 3 RF.

Так как выполнение полного восстановления или инкрементного восстановления на данном этапе одинаково. Итак, я попытался выполнить полный ремонт. Но это приводит к отключению узла координатора.

В итоге я выполняю восстановление полного диапазона разделов (nodetool repair -pr) на каждом узле по одному. Но это занимает слишком много времени (15+ часов для каждого узла, следовательно, недели для всех узлов).

Я делаю это неправильно, или это должно было случиться? Или это проблема версии?

В будущем, если я снова проведу полный ремонт после этого, займет ли это еще несколько недель?


cassandra nodetool cassandra-2.1
person r005t3r    schedule 03.04.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Поскольку на полное восстановление в основном влияет размер данных, на это потребуется столько же времени.

Я предлагаю перейти к поэтапному ремонту, это должно сэкономить ваше время и ресурсы.

Вот статья о том, как это сделать в версии 2.1: https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/opsRepairNodesMigration.html

person nevsv    schedule 03.04.2017
comment
Достаточно ли дополнительного ремонта для общего состояния кластера? Может ли это устранить необходимость в полном ремонте? - person r005t3r; 05.04.2017
comment
Конечно, это то, что он должен решить. Это также тип ремонта по умолчанию в более поздних версиях. - person nevsv; 05.04.2017

arrow_upward
1
arrow_downward

Если у вас слишком большой размер даты, вы можете использовать ремонт поддиапазона, это похоже на ремонт pr, но он фокусируется на поддиапазоне.

Дополнительные объяснения: https://www.pythian.com/blog/effective-anti-entropy-repair-cassandra

person V.HL    schedule 19.05.2017