Разъяснения по ремонту nodetool -pr

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

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

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

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

Однако в блоге datastax эта проблема рассматривается:

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

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

Итак, в целом,

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