Проблемы с новым узлом bootstrap

Question

Мы используем Cassandra 3.11.2 и при попытке bootstrap нового узла потоковая передача занимает много времени. Кластер состоит из трех узлов, и мы находимся в процессе добавления четвертого. Данные, доступные на трех других узлах, близки к 190 ГБ, а размер экземпляра составляет 5 ядер, 5 ГБ на вращающихся дисках.

nodetool netstats на новом узле говорит о потоковых файлах и 106 файлах 15 получено от узла A. Но то же самое netstats на узле A утверждает, что все 106 файлов были отправлены.

Кроме того, мы столкнулись с некоторыми проблемами, связанными с поддержкой активности, и мы увеличили то же самое на новом узле. Это наша вторая попытка, и в первой попытке bootstrap продолжал давать сбои, и мы либо возобновляем ее, либо перезапускаем Cassandra на новом узле, и данные увеличиваются до 500 ГБ, а затем происходит сжатие и уменьшается до 236 ГБ. .

Но тогда bootstrap продолжал терпеть неудачу. Поэтому мы от него отказались и снова начали fre sh. На этот раз, как предлагается в выборе аппаратного обеспечения, c, мы пошли с другим физическим диском для журнала фиксации и данных, чтобы посмотреть, была ли проблема с iops.

И процесс никогда не заканчивается. Это означает, что между ними происходит сбой при сбросе соединения по исключению peer или IO, и мы боролись с этим уже почти неделю.

Как вы думаете, сколько нужно в идеале для начальной загрузки узла с данными, близкими к 190GB? Любые советы / предложения будут очень полезны. Новый узел запускается с флагом auto_ bootstrap, установленным в true.

Answer 1

Как вы думаете, сколько в идеале потребуется для начальной загрузки узла с данными, близкими к 190 ГБ?

К сожалению, на это нет простого способа ответить. Много факторов go в определении того, как быстро новые узлы будут bootstrap, по сути, очень сильно c к базовой инфраструктуре.

Мы используем Cassandra 3.11.2

Рекомендую обновить (как минимум) до 3.11.4. Это простое двоичное обновление, которое не требует запуска nodetool upgradesstables. Причина в том, что 3.11.4 имеет функцию, позволяющую возобновить неудачную загрузку с того места, где она остановилась. По крайней мере, вам не придется каждый раз полностью запускать.

данные увеличивались до 500 ГБ, а затем происходило сжатие до 236 ГБ.

Так что есть несколько причин, по которым это может произойти. Являются ли определения стойки (cassandra-rackd c .properties) одинаковыми или разными? Если вы загружаете узел как новую логическую стойку, вы можете увидеть, что один новый узел отвечает за владение 100% доступных диапазонов токенов. Принимая во внимание, что если вы присоединитесь к новому узлу с той же логической стойкой, что и у других, процент владения (и занимаемая площадь) уменьшится на go.

Любые советы / предложения будут очень полезны.

Я также сталкивался с такими проблемами при загрузке узлов в новые физические центры обработки данных. Одна вещь, с которой у меня был успех, была установка auto_bootstrap: false и запуск nodetool rebuild для потоковой передачи с удаленного D C. Конечно, если у вас нет другого D C для потоковой передачи, это не сработает.

Вы также можете запустить узел без включенной начальной загрузки и запустить nodetool repair, как только он появится , Это имеет некоторые недостатки, заключающиеся в том, что новый узел все равно будет пытаться обслуживать клиентские запросы независимо от того, действительно ли он имеет данные. Но это позволит вам, по крайней мере, присоединить узел и передавать данные более постепенно.

Вот почему обновление до 3.11.4 , вероятно, является вашим лучшим вариантом. Затем вы можете перезапустить узел, когда потоки не будут работать, он определит, где остановился, и не будет принимать клиентские запросы, пока не завершится потоковая передача данных.