Cassandra 2.1 меняет снитч с EC2Snitch на GossipingPropertyFileSnitch

Question

В настоящее время мы использовали EC2Snitch, используя два AZ в одном регионе AWS.Цель состояла в том, чтобы обеспечить отказоустойчивость, даже если один AZ не доступен.Большая часть данных реплицируется с RF = 2, поэтому каждый AZ получает копию на основе Ec2Snitch.

Теперь мы пришли к выводу о переходе на GossipingPropertyFileSnitch.Причина в первую очередь в том, что мы поняли, что выход из строя одного AZ является удаленным явлением, и даже если это произойдет, в нашем стеке есть другие системы, которые этого не поддерживают;так что в конечном итоге все приложение отключается, если это произойдет.

Другая причина в том, что с EC2Snitch и двумя АЗ нам пришлось масштабироваться с коэффициентом 2 (по одному на каждую АЗ).С GossipingPropertyFileSnitch, использующим только одну стойку, мы можем масштабировать с коэффициентом 1.

Когда мы изменим этот параметр snitch, изменится ли топология?Я хочу избежать необходимости выполнять восстановление nodetool.У нас всегда были сбои при запуске восстановления nodetool, и оно работает вечно.

Answer 1

Изменения в топологии зависят от того, как вы их выполняете.Если вы назначите тому же логическому постоянному току и стойке для узла, к которому он настроен в настоящий момент, вы не получите изменения топологии.

Вы должны сопоставить стойку с AZ после обновления до GossipingPropertyFileSnitch.Вам необходимо выполнить повторный перезапуск, чтобы выполнить перенастройку.

Пример cassandra-rackdc.properties для 2 узлов в 1 постоянном токе через 2 АЗ:

# node=10.0.0.1, dc=first, AZ=1
dc_suffix=first
# Becomes
dc=first
rack=1

# node=10.0.0.2, dc=first, AZ=2
dc_suffix=first
# Becomes
dc=first
rack=2

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