Что Кассандра возвращает клиенту при удаленных мутациях?

Question

Когда на стороне Кассандры есть "отброшенные мутации", возвращает ли он соответствующий сбой вызывающему клиенту? Или это всегда успешный ответ на вызывающий клиент, который вызвал транзакцию, даже если соответствующие мутации сбрасываются на стороне сервера и приводят к потере данных?

В одном конкретном случае мы наблюдали множество пропущенных мутаций (около 6 тыс. Пропущенных мутаций в секунду), когда у нас был TPS около 80 К / с и увеличилось время ожидания более 4000 мс. Кластер состоит из 6 узлов кластера. Не связывайтесь со мной сейчас. В общем, как с трудом отстреливать эту «выпавшую мутацию». Как ни странно, мы не могли воспроизвести это поведение даже в более поздний момент.

Answer 1

При записи, если достаточное количество реплик отвечает в течение write_request_timeout_in_ms (по умолчанию 2 секунды), вы увидите успешные ответы на клиенте.

Так что рассмотрите тот случай, когда вы пишете с согласованностью QUORUM скоэффициент репликации 3. Когда запись отправляется от клиента координатору, координатор отправляет запрос записи всем трем репликам одновременно.Если 2 реплики могут ответить в течение write_request_timeout_in_ms, координатор затем отправит успешный ответ клиенту.Между тем, если третья реплика не сможет начать обработку мутации записи в пределах write_request_timeout_in_ms, она отбросит мутацию.

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

Однако с оперативной точки зрения это вызывает беспокойство.У вас есть реплики, которые даже не могут начать работу над обработкой мутации, пока не истечет время ожидания, это не хорошо!

Существует множество возможных причин этого, сбой сборки мусора, проблемы с оборудованием или, возможно,ваш кластер просто недостаточно обеспечен.Мониторинг пропущенных мутаций для выявления этих ситуаций является хорошим шагом к пониманию происходящего.

Если вас беспокоят проблемы согласованности между репликами, Кассандра использует несколько антиэнтропийных механизмов, чтобы войти в согласованное состояние.Если при чтении данных обнаруживаются несоответствия, восстановление при чтении приводит к тому, что реплики в этих узлах приводятся в согласованное состояние путем применения ячеек с самой высокой отметкой времени.Даже если данные совпадают между необходимыми репликами, восстановление чтения все равно может быть инициировано на основе настроенной в таблице вероятности восстановления чтения, чтобы обеспечить согласованность данных среди всех реплик.Вы также должны выполнить запланированные ремонтные работы .

Последнее замечание: в случае, если недостаточно реплик отвечают на ваш уровень согласованности, вы увидите WriteTimeoutException всплывающее сообщение для клиента,Это может означать, что ваши реплики сбрасывают мутации, но это не обязательно так.Они могли начать обработку мутации, но не завершить обработку в течение тайм-аута.В этом случае запись будет применена к этим репликам.