Запросы Astyanax терпят неудачу в кластере с 4 узлами, когда один начальный узел не работает

У меня есть кластер Cassandra с 4 узлами. Один узел выступает в качестве начального узла для пула соединений Astyanax, предоставляемого с помощью метода setSeeds(...) при создании AstyanaxContext. Я также подключил свою собственную реализацию мониторинга пула соединений. Это показывает мне один добавленный хост (начальный узел), но не показывает мне три других узла. При удалении начального узла для Astyanax, например. отключив экономию через nodetool для этого конкретного узла, любой запрос Astyanax к Cassandra не будет выполнен. Я думал, что пул соединений узнает через начальный узел (узлы), как выглядит кластер, и не нуждается в постоянном запуске начального узла?

Я использую RING_DESCRIBE в качестве NodeDiscoveryType и TOKEN_AWARE в качестве ConnectionPoolType.


cassandra astyanax
person tsteinmaurer    schedule 01.07.2013    source источник
comment
Кто-нибудь знает, почему каждый запрос Astyanax терпит неудачу после того, как один начальный узел вышел из строя? Я думал, что Astyanax внутренне узнает, как выглядит кластер/кольцо, а затем выполняет аварийное переключение на другие узлы, даже если начальный узел больше не доступен.   -  person tsteinmaurer    schedule 04.10.2013
comment
вы нашли решение для этого?   -  person Adrian    schedule 13.01.2014

Ответы (1)


arrow_upward
1
arrow_downward

Предоставленная точка контакта всегда должна быть запущена, когда вы отправляете запрос с помощью Astyanax. Обучение начинается позже, когда вы начинаете писать в несколько реплик, и драйверу нужно определить, куда отправлять дополнительные реплицированные данные (потому что, как вы знаете, если у вас более 1 узла, данные записываются в несколько разделов).

Что именно я имею в виду?

127.0.0.1 <--- seed
127.0.0.2
127.0.0.3
127.0.0.4

// code where you initialize Astyanax
...
.setSeeds("127.0.0.1") // this node always has to be available
...
person Lyuben Todorov    schedule 18.11.2013