Попытки перебалансировки кластера Datastax Enterprise 5.0 завершаются неудачей

#cassandra #datastax #datastax-enterprise #datastax-startup

#cassandra #datastax #datastax-enterprise #datastax-запуск

Вопрос:

У нас есть кластер DSE 5.0 из 4 компьютеров. Во время приема данных на одной из этих машин хранилась большая часть данных (100 Г), в то время как на трех других хранилось гораздо меньше (около 15 г каждая). Я не знаю, почему это произошло, и планирую провести расследование и, вероятно, задать отдельный вопрос.

Теперь я пытаюсь перебалансировать кластер. Единственный известный мне способ сделать это — нажать Cluster Actions -> Rebalance в OpsCenter. Перебалансировка запускается и воспроизводимо прерывается примерно через 5 минут с этой ошибкой:

 Rebalance Failed: java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: 
java.net.SocketTimeoutException: Read timed out

Часть данных передается, как предложено в предварительном просмотре перебалансировки, большая часть — нет.

Журнал событий:

 Error   Rebalance failed: java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.net.SocketTimeoutException: Read timed out       admin
Info    Moving node xx.xx.xx.xx from token 5848419665553670365 to 2542108353485192999   NODE-04 
Info    Starting rebalance

В чем может быть причина и как мне ее исследовать и исправить?

Кластер развернут на 4 выделенных компьютерах в Azure.

1. Не могли бы вы подробнее рассказать об этом фрагменте приема данных? Мы говорим о массовой загрузке данных или обычных операциях? Я просто пытаюсь лучше понять, почему это могло произойти в первую очередь. @helmser прав, что в обычном варианте использования с хорошей моделью данных данные должны быть равномерно распределены. По-прежнему вызывает беспокойство сбой задания балансировки, и об этом следует сообщить вашему менеджеру по работе с клиентами в DataStax, чтобы он связал вас с техническими специалистами на этом конце, если это ошибка, которую они смогут вместе с вами диагностировать и устранить.

2. @mando222 — PK — это простой хэш SHA, сгенерированный из остальных данных, поэтому я предположил, что PK хорошо распределены. Еще не удалось должным образом проанализировать фактическое распределение. В любом случае, неспособность перебалансировать тоже выглядит для меня ошибкой.

Ответ №1:

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

1. Спасибо хелмсеру, это звучит вполне правдоподобно. Я должен проанализировать распределение PK. Однако это не отвечает на вопрос — я предполагаю, что сбой функции перебалансировки, вероятно, имеет и другие причины. В конце концов, он предлагается в официальном пользовательском интерфейсе, вероятно, именно для этой ситуации, поэтому я предположил, что он должен работать лучше. Вы случайно не знаете, что можно было бы сделать с тайм-аутом?