Я новичок в Cassandra и пытаюсь понять, как это работает. Скажем, если запись в несколько узлов. Насколько я понимаю, в зависимости от хеш-значения ключа решается, какой узел владеет данными, а затем происходит репликация. При чтении данных хэш ключа определяет, какой узел имеет данные, а затем отвечает. Теперь мой вопрос заключается в том, что если чтение и запись происходят из одного и того же набора узлов, в котором всегда есть данные, то как возникает несогласованность чтения, и Cassandra возвращает устаревшие данные?
Читает ли Кассандра непоследовательность?
Ответы (2)
Для настройки согласованности cassandra позволяет устанавливать согласованность для каждого запроса.
Теперь по вашему вопросу: предположим, что CONSISTENCY установлено в ONE, а коэффициент репликации равен 3.
Во время запроса WRITE координатор отправляет запрос на запись всем репликам, которым принадлежит записываемая строка. Пока все узлы реплик работают и доступны, они будут получать запись независимо от уровня согласованности, указанного клиентом. Уровень согласованности записи определяет, сколько узлов реплики должны ответить подтверждением успеха, чтобы запись считалась успешной. Успех означает, что данные были записаны в журнал коммитов и в memtable.
Например, в кластере из 10 узлов в одном центре обработки данных с коэффициентом репликации 3 входящая запись будет направлена на все 3 узла, которым принадлежит запрошенная строка. Если уровень согласованности записи, указанный клиентом, равен ОДИН, узел, первым завершивший запись, отвечает обратно координатору, который затем передает сообщение об успешном завершении обратно клиенту. Уровень согласованности ONE означает, что возможно, что 2 из 3 реплик могут пропустить запись, если они были отключены во время выполнения запроса. Если реплика пропускает запись, Cassandra позже сделает строку согласованной, используя один из встроенных механизмов восстановления: передачу обслуживания с подсказками, восстановление чтения или восстановление узла антиэнтропии.
По умолчанию подсказки сохраняются в течение трех часов после сбоя реплики, потому что, если реплика не работает дольше этого времени, она, скорее всего, окончательно не работает. Вы можете настроить этот интервал времени, используя свойство max_hint_window_in_ms в файле cassandra.yaml. Если узел восстанавливается по истечении времени сохранения, запустите восстановление, чтобы повторно реплицировать данные, записанные во время простоя.
Теперь, когда выполняется запрос READ, узел-координатор отправляет эти запросы репликам, которые в данный момент могут ответить быстрее всего. (Следовательно, это может быть любая 1 из 3 реплик).
Теперь представьте ситуацию, когда данные еще не реплицированы на третью реплику и во время READ эта реплика выбирается (шансы очень незначительны), тогда вы получаете несогласованные данные.
Этот сценарий предполагает, что все узлы работают. Если один из узлов не работает, а чтение-восстановление не выполняется после того, как узел включен, это может привести к возникновению проблемы.
ПРОЧИТАТЬ С РАЗНЫМ УРОВНЕМ КОНСИСТЕНЦИИ
person
undefined_variable
schedule
28.06.2017
Данные записываются во все 3 реплики (а не только в первую) от координатора одновременно, он просто подтверждает запись после достижения запрошенной согласованности.
- person Chris Lohfink; 28.06.2017
Если какой-либо из узлов не работает, координатор напишет подсказку, как только узел вернется в рабочее состояние, он передаст ему подсказки, чтобы он стал согласованным. Восстановление чтения — это просто еще один механизм. Отказ узла не означает, что он становится несогласованным
- person Chris Lohfink; 28.06.2017
Когда происходит чтение, он отправляет запрос DATA на самую быструю реплику и запрос DIGEST на другие реплики. Как только он получит достаточно ответов для соответствия CL, он вернется к клиенту. Он будет сравнивать данные, возвращенные из узла, с дайджестом других. Если они не совпадают, он отправит мутацию, чтобы исправить несоответствие. Блокировка и асинхронное чтение восстанавливаются в зависимости от того, что (ДАННЫЕ или ОБЗОР) является более новым. Это может произойти даже после того, как клиент получил ответ на чтение. Спекулятивная повторная попытка доступна, если запросы ДАННЫХ слишком медленные, когда он отправляет запрос ДАННЫХ другим репликам.
- person Chris Lohfink; 28.06.2017
@ChrisLohfink, вы правы насчет DIGEST и HINT... но HINT максимальное время ожидания по умолчанию составляет 3 часа... и DIGEST будет использоваться для выполнения
read_repair на основе read_repair_chance... В случае CONSISTENCY ONE результаты будут возвращены координатору как только 1 реплика ответит..
- person undefined_variable; 29.06.2017
Спасибо. Как я понял из комментариев и ссылки, прикрепленной к ответу, так это то, что если уровень CONSISTENCY соответствует уровню QUORUM, запросы на чтение будут согласованными и актуальными с последними данными. дайте мне знать, если это правильное понимание.
- person user3276247; 29.06.2017
Да.. если вы используете CONSISTENCY QUORUM, ваш запрос на чтение будет согласованным и актуальным
- person undefined_variable; 29.06.2017
@ChrisLohfink Спасибо за ваше предложение .... Соответственно изменен ответ ... Еще раз спасибо
- person undefined_variable; 29.06.2017
Рассмотрим сценарий, в котором CL является QUORUM, и в этом случае должны ответить 2 из 3 реплик. Запрос на запись будет отправлен на все 3 реплики, как обычно, если запись на 2 реплики завершится ошибкой и будет выполнена на 1 реплике, cassandra вернет Failed. Поскольку cassandra не выполняет откат, запись будет продолжать существовать на успешной реплике. Теперь, когда чтение приходит с CL=QUORUM, и запрос на чтение будет перенаправлен на 2 узла реплики, и если один из узлов реплики является ранее успешным, тогда cassandra вернет новые записи, поскольку у них будет последняя метка времени. Но с точки зрения клиента эта запись не была записана, так как cassandra вернула ошибку во время записи.
person
Ologn
schedule
07.01.2020
