Динамическое изменение кластера Cassandra с одного узла на два узла

Question

Итак, у меня есть приложение, которое будет очень бездействующим большую часть времени, но будет нуждаться в высокой нагрузке в несколько дней в месяц. Поскольку мы развертываем на EC2, я хотел бы держать только один сервер Cassandra большую часть времени, а затем в дни пиковой нагрузки я хочу поднять еще один сервер (с большим объемом оперативной памяти и процессора, чем у первого), чтобы помочь обслужить нагрузку. Как лучше всего это сделать? Стоит ли мне использовать другой подход?

Некоторые заметки о том, что я планирую сделать:

• Поднимите узел и немедленно отремонтируйте его.
• После окончания времени импульса выведите из эксплуатации мощный узел
• Используйте постоянно включенный сервер в качестве начального узла

Мой главный вопрос в том, как заставить узлы обмениваться всеми данными, поскольку мне нужен фактор репликации 2 (чтобы оба узла имели все данные), но это не сработает, пока есть только один сервер. Стоит ли мне поднять 2 дополнительных сервера вместо одного?

Answer 1

Кажется, что вы можете довольно легкоизменить фактор репликации.

Об этом также упоминается наКассандра вики, где вы можете найти инструкции как по увеличению, так и по уменьшению фактора репликации.

Это означает, что должно быть возможно сделать следующее:

• изменить фактор репликации с 1 на 2
• поднимите и восстановите ваш пакетный узел, чтобы он получил копию всех данных
• ... Выполнять работу ...
• вывод из эксплуатации узла разрыва
• изменить фактор репликации обратно с 2 на 1
• запустить очистку

Answer 2

По моему опыту, изменение фактора репликации на лету не работает так уж хорошо :-( Вы можете столкнуться с несоответствиями в схеме, исправление которых занимает много времени, по крайней мере, у меня.

Просто мысли вслух, но возможен и другой маршрут (измените время по своему усмотрению):

1. Увеличьте льготный период для сборки мусора в cassandra.yaml (он определяет, как долго будут существовать надгробия до их удаления с диска), например, до 30 дней.
2. Запускайте второй узел каждые 15 дней или около того, независимо от того, нужно это или нет. Убедитесь, что его данные / журналы коммитов и т. д. сохраняются между запусками. Это значит, что вы начнете быстрее, когда вам нужно будет запустить второй узел

3. с большим объемом оперативной памяти и процессора, чем у первой версии

Cassandra эффективно делит рабочую нагрузку на размер кольца, за которое отвечает каждый узел. Может быть проще, чтобы второй узел либо удвоил емкость первого, либо добавил 2 узла того же размера, что и первый, для более легкого разделения кольца.

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