Клиент Cassandra теряет соединение с исходным узлом, если исходный узел выходит из строя. Это нормальное поведение?

В настоящее время я делаю технико-экономическое обоснование с Cassandra 2.0.9. В ходе тестирования было замечено, что клиент, который подключается к кластеру с IP-адресом начального узла, теряет соединение при сбое начального узла.

Для подробностей кластер имеет два узла с IP 1.1.1.1 и 2.2.2.2 с 1.1.1.1 в качестве начального.

(1) клиент А соединяется с 1.1.1.1. (2) сбой начального узла 1.1.1.1 (3) клиент А теряет соединение (4) никогда не восстанавливается даже после перезапуска начального узла.

клиент продолжал работать нормально без проблем в следующей ситуации. +клиент соединяется с 2.2.2.2 и любой из узлов падает.

Должен ли я не использовать IP-адрес начального узла для конфигурации клиента??

Как настроить IP клиентов для кластера cassandra, если клиентов много и несколько узлов Cassandra.

Я доволен выступлением, но у Кассандры, похоже, есть некоторые недостатки.

Заранее спасибо.


person Joshua    schedule 02.08.2014    source источник


Ответы (1)


Начальный узел не представляет собой ничего особенного в Cassandra — единственная разница между начальным и обычным узлом заключается в том, что каждый узел в кластере должен знать начальный IP-адрес на этапе начальной загрузки. Таким образом, первое правило кластера никогда не устанавливает только один узел в качестве семени, потому что, если он недоступен, а некоторые другие узлы пытаются присоединиться к кластеру, они не смогут (я знаю, что это был просто пример, но это хорошее правило помнить). Чтобы ответить на первый вопрос: вы можете установить начальный узел для конфигурации IP-клиента.

Что касается вашего теста, вы не указали клиент, который вы используете - предполагая, что вы используете официальный драйвер Java, вы должны указать драйверу, как вы хотите, чтобы он пытался установить новые соединения, когда узел умирает и что делать, если чтение не удалось из-за TimeoutException | UnavailableException

Ознакомьтесь с ReconnectionPolicy. и RetryPolicy, возможно, по умолчанию значения не соответствуют вашим потребностям.

ХТХ, Карло

person Carlo Bertuccini    schedule 02.08.2014