Насколько дорого обходится операция по ремонту nodetool?

Не повредит ли их регулярная работа nodetool repair на моих узлах Cassandra?

В FAQ по планете Кассандра отмечается (выделено мной), что

Антиэнтропийное восстановление узла - для данных, которые не читаются часто, или для обновления данных на узле, который не работал в течение длительного периода, процесс восстановления узла (также называемый антиэнтропийным ремонтом) гарантирует, что все данные на узле реплика сделана согласованной. Восстановление узлов (с помощью утилиты nodetool) следует запускать регулярно как часть регулярных операций по обслуживанию кластера.

Это единственное упоминание о регулярном nodetool repair запуске, которое я видел. Регулярно запускать его не составит труда, если оно дешевое, но насколько оно дорого? Выполняет ли он эквивалент чтения с проверкой согласованности каждой записи на узле? Или это умнее этого? В документации упоминается использование деревьев Меркла, но это не дает мне представления о том, насколько дорога эта операция.

Если у вас есть 500 ГБ данных на узле, и этот узел фактически согласуется с другими узлами (восстановление не выполняется), о том, сколько данных выполняется при восстановлении, считываемых с диска (чтение всех 500 ГБ заняло бы пару секунд). часов)? И о том, сколько данных отправляется по локальной сети (отправка всех 500 ГБ по локальной сети может занять еще час или около того).


cassandra nodetool maintenance
person Raedwald    schedule 12.07.2013    source источник

Ответы (1)


arrow_upward
16
arrow_downward

Некоторые варианты использования больше зависят от регулярного ремонта, чем другие. Если вы выполняете удаление на уровне ниже ConsistencyLevel.ALL, вам следует запустить восстановление, чтобы гарантировать, что удаленные столбцы не вернутся к жизни. Если вы не выполняете удаления, вы можете полагаться на подсказку и восстановление после чтения, чтобы во многих случаях поддерживать согласованность. Если вы читаете и пишете с низким уровнем согласованности или регулярно имеете простои или перегрузки сервера, вы, вероятно, захотите запустить восстановление.

При восстановлении считываются все данные на узле, на котором вы его запускаете (необязательно, с параметром -pr (основной диапазон), только диапазоны, для которых узел владеет основным диапазоном) и строит вверх по дереву Меркла. Он также отправляет сообщение всем узлам, которые хранят реплики любого из этих диапазонов, чтобы сделать то же самое - они будут читать только данные, которые реплицируются на узле начального восстановления.

Чтобы построить дерево Меркла на узле с 500 ГБ, будут прочитаны полные 500 ГБ (при использовании -pr это будет примерно на коэффициент репликации ниже). Однако деревья Меркла имеют постоянный размер (несколько МБ), поэтому очень мало передается по сети, если узлы синхронизированы.

Лучший способ запустить плановое восстановление - запустить по очереди с -pr на каждом узле. Это позволяет избежать многократного восстановления одних и тех же данных. Кроме того, запускайте одновременно только один узел, чтобы избежать дополнительной нагрузки на кластер.

person Richard    schedule 15.07.2013
comment
Не могли бы вы подробнее рассказать о возвращении удаленных столбцов к жизни? Вы говорите об удаленных столбцах, которые продолжают появляться в течение небольшого промежутка времени после удаления, или о том, что конечная согласованность Cassandra на самом деле не будет работать, если вы не используете ConsistencyLevel.ALL? Насколько я понимаю, удаление должно в конечном итоге распространиться на весь кластер, даже если используется ConsistencyLevel.ANY, потому что в конечном итоге изменения всегда будут распространяться. Это неправильно? - person aroth; 25.01.2016
comment
@aroth Вы получили ответ на вышеуказанный вопрос? - person Naresh; 01.12.2016
comment
@Naresh - Нет, однако я уже некоторое время использую более низкие уровни согласованности в продакшене и на практике не наблюдал таких проблем. Конечно, это анекдотично, с размером выборки, равным единице, и не означает, что плохие вещи не могут / не произойдут. Так что относитесь к этому с недоверием. - person aroth; 01.12.2016
comment
Конечная согласованность отлично работает для удалений, если вы выполнили успешное восстановление для каждого диапазона в gc_grace. Если вы не выполняете ремонт так часто или не проверяете наличие сбоев восстановления, вы получите данные, возвращающиеся к жизни, если какая-либо реплика не получит удаления. - person Richard; 12.12.2016