Кассандра ремонтирует на TWCS

Question

У нас есть кластер Cassandra с 13 узлами (версия 3.10) с RP 2 и согласованностью чтения / записи 1. Это означает, что кластер не полностью согласован, но в конечном итоге согласован. Мы выбрали эту настройку, чтобы повысить производительность, и мы можем допустить несколько секунд несогласованности.

Для таблиц задана TWCS с отключенным восстановлением чтения, и мы не выполняем полное восстановление для них

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

My Первый вопрос: как это могло произойти? Разве Кассандра не должна копировать все данные?

Теперь, если мы решим выполнить ремонт, он создаст перекрывающиеся надгробия, поэтому они не будут удалены, когда истечет их время. Мне известно о свойстве unchecked_tombstone_compaction, чтобы игнорировать перекрытие, но я чувствую, что это плохой подход. Есть идеи?

Answer 1

Уровень согласованности = 1 может иногда создавать проблему по многим причинам, например, если данные не реплицируются в кластер должным образом из-за мутаций, перегрузки кластера / узла, высокой загрузки ЦП, высокой скорости ввода-вывода или проблемы с сетью, поэтому в этом случае вы может страдать от несогласованности данных, однако read read обрабатывает эту проблему несколько раз, если она включена. вы можете go с ручным восстановлением, чтобы обеспечить целостность кластера, но вы также можете получить некоторые данные зомба ie для вашего случая.

Я думаю, чтобы избежать такого рода проблем, вы должны рассмотреть CL по крайней мере Кворум для записи или вы должны выполнить ручное восстановление в GC_grace_period (по умолчанию 10 дней) для всех таблиц в кластере. Кроме того, вы можете использовать инкрементное восстановление, чтобы Cassandra запускала восстановление в фоновом режиме для порции данных. Для более подробной информации вы можете обратиться по ссылке ниже

http://cassandra.apache.org/doc/latest/operating/repair.html или https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/tools/toolsRepair.html

Answer 2

Итак, вы, очевидно, сделали несколько осознанных решений относительно своего клиентского CL. Вы решили пожертвовать последовательностью ради скорости. Вы достигли своих целей, но предполагали, что данные всегда будут поступать на все остальные узлы кластера, к которому они принадлежат. Там нет никаких гарантий того, как вы узнали. Как это могло случиться? Я уверен, что есть несколько причин, некоторые из которых включают: сеть / проблемы, аппаратную перегрузку (I / O, CPU, и т. Д. c. - которая может вызвать пропущенные мутации), cassandra / dse, недоступную по любым причинам, и т. Д. c.

Если ни один из ваших узлов не был в автономном режиме в течение как минимум нескольких часов (будь то dse или хост недоступен), я предполагаю, что ваши узлы сбрасывают мутации , и я бы проверил две вещи: 1) nodetool tpstats 2) Посмотрите журналы вашей кассандры Для DSE: cat /var/log/cassandra/system.log | grep -i мутация | grep -i drop (и debug.log)

Я предполагаю, что вы, вероятно, отбрасываете мутации, и журналы cassandra и tpstats запишут это (tpstats покажет вам только после последнего перезапуска cassandra / dse) ). Если вы отбрасываете мутации, вам придется попытаться понять, почему, как правило, это вызывает некое давление нагрузки.

Я запланировал 1-секундный вывод vmstat, который непрерывно буферизуется в журнал с ротацией журналов, поэтому я могу go вернуться назад и проверить несколько вещей, если наши узлы начнут "неправильно себя вести". Это может помочь.

Вот где я бы начал. В любом случае, ваше решение использовать чтение / запись CL = 1 поставило вас на это место. Вы можете пересмотреть этот подход.