Приведет ли согласованность записи к ONE к исчезновению данных?

В последнее время мы сталкиваемся с несколькими проблемами исчезновения данных. Наши данные - это данные журнала. Он имеет составной ключ (id, requestdate).

Наша программа постоянно вставляет новые записи в C*. Нет операций удаления. Данные были успешно записаны и удалось выбрать данные. Но через некоторое время данные по некоторым id пропали.

Одна из причин, по которой мы могли бы подумать, заключается в том, что мы используем драйвер kundera cassandra, для которого по умолчанию для параметра Consist_level записи установлено значение ONE. В системном журнале ошибок нет.

Считаете ли вы, что эта проблема вызвана записью консистентности_уровня? Спасибо.

Редактировать: мы некоторое время не запускали восстановление узла. Может ли это вызвать проблему с исчезновением данных?


cassandra kundera
person Yan Liu    schedule 18.01.2015    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Существует вероятность, что если вы сделаете чтение сразу после записи и используете одну из других реплик в качестве координатора, она еще не получила данные. Если вам нужна такая согласованность при чтении, используйте CL.QUORUM как для чтения, так и для записи. Можно с уверенностью предположить, что это окно прошло в течение ~ 500 мс или около того. См. раздел Конечная согласованность != Надежная согласованность

person Chris Lohfink    schedule 18.01.2015
comment
Наша проблема в том, что запись прошла успешно, и чтение после записи отобразило данные. Через день или некоторое время данные под каким-то идентификатором (ключом раздела) исчезли, невозможно выбрать ни с одного узла. - person Yan Liu; 18.01.2015
comment
Я предполагаю, что что-то либо удаляет его, либо устанавливает TTL для данных. Другая возможность заключается в том, что ваше приложение может пытаться использовать неправильный ключ раздела. - person Chris Lohfink; 18.01.2015
comment
Для данных нет настройки TTL. Как возможная установка неправильного ключа раздела может привести к этому? Спасибо. - person Yan Liu; 19.01.2015
comment
если вы сгенерируете неправильный ключ раздела, вы не получите никаких данных. - person Chris Lohfink; 19.01.2015
comment
Оказывается, я использовал драйвер Kundera Cassandra, который по умолчанию откатывает транзакции, если запись не удалась. (напишите timeout в нашем случае). Откат — это команда удаления, которая приводит к удалению данных. Ваши комментарии напоминают мне. Спасибо. - person Yan Liu; 29.01.2015

arrow_upward
1
arrow_downward

Непротиворечивость ONE указывает, что состояние возвращается, как только запись на одном узле реплики завершается успешно. Данные не должны исчезать из кассандры, если только сама запись никогда не была успешной.

Если вставка не удалась из-за неработающих узлов. В этом случае проверьте указанную передачу обслуживания. Увеличьте время для намека на снятие руки.

Какой у вас коэффициент репликации? Может быть, увеличить его до большего числа, чтобы предотвратить потерю обслуживания из-за неработающего узла?

person Desert Ice    schedule 18.01.2015
comment
Запись прошла успешно. После записи данных данные были выбраны и отображены. Репликация равна 3. Еще одна проблема, которую мы обнаружили, заключается в том, что восстановление nodetool не выполнялось какое-то время. При потере данных теряются все данные под одним идентификатором (ключом раздела), а не только последние данные. Спасибо. - person Yan Liu; 18.01.2015
comment
Есть ли шанс, что вы, ребята, используете TTL для своего пространства ключей? Восстановление Nodetool из того, что я знаю, должно быть запущено как минимум один раз gc_grace_seconds вручную. - person Desert Ice; 19.01.2015
comment
Проверьте, какой именно узел назначен одному идентификатору. Другой возможностью может быть отметка времени, когда данные для одного конкретного объекта не будут перезаписываться значениями с более старой отметкой времени. Кроме того, вы можете попробовать запустить nodetool flush, refresh {маловероятные сценарии}. - person vivek mishra; 19.01.2015