Сначала я бы изменил endpoint_snitch на GossipingPropertyFileSnitch на одном узле и перезапустил его. Сначала вам нужно убедиться, что этот подход работает. Как правило, вы не можете (легко) изменить логические имена центров обработки данных или стоек в работающем кластере. Какой технически вы этого не делаете, но SimpleStrategy может делать некоторые вещи под капотом, чтобы абстрагироваться от осведомленности о центре обработки данных / стойке, поэтому неплохо его проверить.
Если это работает, внесите изменения и перезапустите другой узел. Если это не сработает, вам может потребоваться добавить 6 новых узлов (вместо 4) и списать 2 существующих узла.
Или мне также следует изменить стратегию системных пространств ключей и коэффициент репликации?
Да, вы должны установить такое же определение репликации пространства ключей для следующих пространств ключей: system_auth, system_traces и system_distributed.
Рассмотрим ситуацию: если один из ваших 2 выйдет из строя, вы не сможете войти в систему как пользователи, назначенные этому узлу через таблицу system_auth. Поэтому очень важно гарантировать, что system_auth реплицируется должным образом.
Я писал об этом как-то go (обновлено в 2018 году): Фактор репликации использовать для system_auth
Кроме того, я рекомендую тот же подход для system_traces и system_distributed, так как будущие добавления / замены / ремонта узла могут завершиться неудачно, если не удается найти допустимые диапазоны токенов для этих пространств ключей. По сути, использование того же подхода к ним предотвращает потенциальные проблемы в будущем.
Edit 20200527:
Нужно ли мне запускать nodetool cleanup на старых узлов кластера после изменения топологии снитча и пространства ключей? Согласно документам «да», но только на старых узлах?
Вам нужно будет запустить его на каждом узле, за исключением самого последнего добавленного. Последний узел - единственный узел, который гарантированно будет иметь только данные, соответствующие назначенному диапазону токенов.
«Почему?» вы можете спросить. Рассмотрим общий процент владения, поскольку кластер постепенно увеличивается с 2 узлов до 6. Если вы увеличите RF с 1 до 2 (запустите ремонт), а затем с 2 до 3 и добавите первый узел, у вас будет кластер с 3 узлами. и 3 реплики. Таким образом, каждый узел имеет 100% владение данными.
Этот процент владения постепенно уменьшается по мере добавления каждого узла, до 50% при добавлении 6-го и последнего узла. Но даже если все узлы будут владеть 50% диапазонов токенов:
- Первые 3 узла все равно будут иметь 100% набора данных, что составляет дополнительные 50% данных, которые они должны.
- Четвертый узел все еще будет иметь дополнительные 25% (3/4 минус 1/2 или 50%).
- Пятый узел по-прежнему будет иметь дополнительные 10% (3 / 5 минус 1/2).
Следовательно, шестой и последний узел - единственный, который не будет содержать больше данных, чем он отвечает.