2016-11-19 1 views
1

Я использую Cassandra 2.2, и у меня есть приложение, которое требует высокого уровня согласованности.Проблемы с консистенцией и таймаутом с Cassandra 2.2

Я настроил один кластер центров обработки данных с 3 узлами. Мое пространство ключей создано с replication_factor из 2. В каждом файле configuration.yaml я установил 2 seed_providers (например, NODE_1 и NODE_3).

Важно то, что мое приложение должно быть полнофункциональным, даже если один узел выключен.

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

Я прочитал весь Cassandra 2.2 документацию, и я пришел к выводу, что лучший CONSISTENCY LEVEL для моих операций записи должен быть QUORUM и для моих операций чтения ONE, но я до сих пор есть некоторые проблемы непротиворечивости.

Прежде всего, это правильный выбор, чтобы иметь сильный уровень согласованности? А также являются операциями UPDATE и DELETE, считающимися операциями записи или чтения, поскольку, например, операция обновления с предложением WHERE по-прежнему должна «читать» данные? Я не уверен, пространственно в контексте рабочего процесса кассандры.

Моей второй проблемой является тайм-аут во время операций записи. Простой и легкий INSERT иногда получают «Cassandra timeout during write query at consistency QUORUM (2 replicas were required but only 1 acknowledged the write)» или sometines даже «... 0 acknoledged», хотя все мои 3 узла UP.

Есть ли еще некоторые параметры, которые я должен проверить, например, write_request_timeout_in_ms, со значением по умолчанию 2000 мс (что уже является высоким значением)?

ответ

0

Для операций записи вы должны иметь прочную согласованность с Replication Factor = 2 и Consistency Level = QUORUM для операций записи и ONE. Но операции записи не удастся, если один узел опущен. Consistency Level = QUORUM - это то же самое, что и ALL в случае Replication Factor = 2.

Вы должны использовать Replication Factor = 3 и Consistency Level = QUORUM для операций записи и чтения, чтобы иметь сильную согласованность и полное функциональное приложение, даже если один узел выключен.

DELETE и UPDATE операции - операции записи.

Для проблемы с таймаутом просьба указать модель таблицы и запросы, которые не выполняются.

Обновлено

уровень Консистенция относится к репликам, а не узлы.

Коэффициент репликации = 2 означает, что 2 из 3 узлов будут содержать данные. Этими узлами будут реплик.

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

Кассандра размещает данные на каждом узле в соответствии с ключом раздела. Каждый узел отвечает за диапазон ключей разделов. Ни один из узлов не может хранить какие-либо данные, поэтому для выполнения операций вам нужны живые реплики (а не узлы). Здесь статья about data replication and distribution.

Когда вы выполняете запрос на запись QUORUM в кластер с 2 из 3 живых узлов, есть вероятность, что в кластере есть только 1 живая реплика для ключа раздела, в этом случае запрос на запись не удастся.

В дополнение: вот simple calculator for Cassandra parameters

+0

Спасибо вам ответить. Но, не могли бы вы объяснить, пожалуйста, немного, почему с 3-мя узлами в начале с коэффициентом репликации 2 произойдет сбой операций записи, если один узел завершит сбой. С одним неисправным узлом я все еще имею 2 доступных узла. На мой взгляд, в этом случае запись с QUORUM-консистенцией (2 повторения должны быть подтверждены) должна по-прежнему работать. Но я, вероятно, ошибаюсь. Спасибо. –

+0

@ TheWingman, я добавил объяснение о репликации на мой ответ –

+0

Большое спасибо за все эти объяснения. Это гораздо более ясно. –

Смежные вопросы