Разъяснения по поводу восстановления nodetool -pr

Question

Из документации:

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

Вероятно, никогда не будет времени, когда я могу принять все узлы медленными для определенной части данных. Но мне интересно: почему он это делает ^{(или, может быть, в документации есть просто путаница с опцией -par?!)}, когда nodetool repair кажется умнее

По умолчанию команда восстановления немедленно делает снимок каждой реплики, а затем последовательно восстанавливает каждую реплику из снимков. Например, если у вас RF=3 и A, B и C представляют три реплики, эта команда немедленно делает снимок каждой реплики, а затем последовательно восстанавливает каждую реплику из снимков (A<->B, A<->C, B<->C) вместо того, чтобы восстанавливать A, B и C одновременно. Это позволяет динамическому анализу поддерживать производительность вашего приложения через другие реплики, поскольку по крайней мере одна реплика в снимке не восстанавливается.

Тем не менее, блог datastax решает эту проблему:

Этот первый этап может быть интенсивным на диске IO, однако. Вы можете смягчить это до некоторой степени с помощью регулирования сжатия (поскольку этот этап является тем, что мы называем проверкой сжатия.) Однако иногда этого недостаточно, и некоторые люди пытаются уменьшить это дополнительно с помощью -pr (–partitioner-range) опция восстановления узла, которая восстанавливает только основной диапазон для этого узла. К сожалению, другие реплики для этого диапазона все равно должны будут выполнять вычисления дерева Меркле, вызывая уплотнение проверки. Это может быть проблемой, так как все реплики будут делать это одновременно, возможно, заставляя их все медленно отвечать за эту часть ваших данных. К счастью, есть способ обойти это, используя опцию -snapshot.

Это может быть хорошо, но на самом деле, нет -snapshot вариант для nodetool repair (см. справочную страницу или документацию) (эта опция была удалена?!)

В общем,

• Я не могу использовать nodetool repair -prКажется, потому что мне всегда нужно, чтобы система была достаточно отзывчивой для чтения / записи с ОДНОЙ согласованностью, без значительной задержки. (Примечание: у нас только один центр обработки данных.) Или я что-то упускаю / неправильно понимаю?
• Почему nodetool repair умный, сохраняющий один узел отзывчивым, а nodetool repair -pr делает все узлы медленными для части данных?
• Где -snapshot опция: была ли она удалена, никогда не реализована, или теперь она может автоматически работать, также при использовании nodetool repair -pr?

Answer 1

В блоге ниже рассматриваются эти проблемы:

http://www.datastax.com/dev/blog/repair-in-cassandra

Просто nodetool repair не только начнет восстановление самого узла, но и всех узлов, которые содержат реплики, если его диапазоны. Хотя это нормально, это очень дорого и обычно не является операцией, которую вы выполняете в загруженной производственной системе в пиковые периоды.

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

С другой стороны, Datastax OpsCenter предлагает сервис по ремонту, который все время выполняет меньшие ремонты поддиапазона, так что, хотя вы всегда восстанавливаете его в фоновом режиме все время на более низком уровне ресурсов.

Что касается моментальных снимков, то при выполнении регулярного восстановления будет вызван моментальный снимок, как вы сказали, вы также можете вызвать моментальный снимок самостоятельно, используя nodetool snapshot

Надеюсь это поможет!