У нас есть новый кластер под управлением Cassandra 2.2.14, и мы оставили уплотнения, чтобы «разобраться сами». Это в нашей среде UAT, поэтому нагрузка низкая. Мы запускаем STCS.
Мы видим вечно растущие надгробия. Я понимаю, что уплотнение позаботится о данных в конечном итоге, как только sstable станет подходящим для уплотнения. У нас это происходит не так часто, поэтому я включил некоторые настройки в качестве теста (я знаю, что они агрессивные, это чисто для тестирования):
'tombstone_compaction_interval': '120',
'unchecked_tombstone_compaction': 'true',
'tombstone_threshold': '0.2',
'min_threshold': '2'
это действительно привело к некоторому уплотнению, однако количество упавших надгробий невелико и не опустилось ниже порогового значения (0,2). После применения этих настроек я вижу в sstablemetadata следующее:
Estimated droppable tombstones: 0.3514636277302944
Estimated droppable tombstones: 0.0
Estimated droppable tombstones: 6.007563159628437E-5
Обратите внимание, что это только один CF, и есть гораздо худшие CF (90% надгробий и т. Д.). Если взять это в качестве примера, то все CF страдают одинаковыми симптомами.
tablestats:
SSTable count: 3
Space used (live): 3170892738
Space used (total): 3170892738
Space used by snapshots (total): 3170892750
Off heap memory used (total): 1298648
SSTable Compression Ratio: 0.8020960426857765
Number of keys (estimate): 506775
Memtable cell count: 4
Memtable data size: 104
Memtable off heap memory used: 0
Memtable switch count: 2
Local read count: 2161
Local read latency: 14.531 ms
Local write count: 212
Local write latency: NaN ms
Pending flushes: 0
Bloom filter false positives: 0
Bloom filter false ratio: 0.00000
Bloom filter space used: 645872
Bloom filter off heap memory used: 645848
Index summary off heap memory used: 192512
Compression metadata off heap memory used: 460288
Compacted partition minimum bytes: 61
Compacted partition maximum bytes: 5839588
Compacted partition mean bytes: 8075
Average live cells per slice (last five minutes): 1.0
Maximum live cells per slice (last five minutes): 1
Average tombstones per slice (last five minutes): 124.0
Maximum tombstones per slice (last five minutes): 124
Очевидный ответ здесь состоит в том, что надгробия не подлежали удалению.
gc_grace_seconds установлен на 10 дней и не был перемещен. Я сбросил один из sstable в json и вижу надгробные плиты, датируемые апрелем 2019 года:
{"key": "353633393435353430313436373737353036315f657370a6215211e68263740a8cc4fdec",
"cells": [["d62cf4f420fb11e6a92baabbb43c0a93",1566793260,1566793260977489,"d"],
["d727faf220fb11e6a67702e5d23e41ec",1566793260,1566793260977489,"d"],
["d7f082ba20fb11e6ac99efca1d29dc3f",1566793260,1566793260977489,"d"],
["d928644a20fb11e696696e95ac5b1fdd",1566793260,1566793260977489,"d"],
["d9ff10bc20fb11e69d2e7d79077d0b5f",1566793260,1566793260977489,"d"],
["da935d4420fb11e6a960171790617986",1566793260,1566793260977489,"d"],
["db6617c020fb11e6925271580ce42b57",1566793260,1566793260977489,"d"],
["dc6c40ae20fb11e6b1163ce2bad9d115",1566793260,1566793260977489,"d"],
["dd32495c20fb11e68f7979c545ad06e0",1566793260,1566793260977489,"d"],
["ddd7d9d020fb11e6837dd479bf59486e",1566793260,1566793260977489,"d"]]},
Поэтому я не верю, что проблема в gc_grace_seconds. Я выполнил определенное пользователем сжатие вручную для каждого файла Data.db в папке семейства столбцов (только один файл Data.db, по одному). Сжатие прошло, но значения надгробных памятников изменились очень мало. Старые данные остались.
Я могу подтвердить, что ремонт действительно произошел вчера. Я также могу подтвердить, что ремонт идет регулярно, и в журналах нет проблем.
Так что с ремонтом все в порядке. Уплотнения в порядке. Все, о чем я могу думать, это наложение SSTables.
Последний тест - выполнить полное уплотнение семейства колонн. Я выполнил определяемый пользователем (не nodetool compact) 3 SSTables с помощью JMXterm. В результате получился единственный файл SSTable со следующим:
Estimated droppable tombstones: 9.89886650537452E-6
Если я ищу пример EPOCH, как указано выше (1566793260), он не отображается. И это не ключ. Так что это было уплотнено, или Кассандра что-то сделала. Общее количество строк, содержащих флаг надгробия («d»), составляет 1317 из 120 миллионов строк дампа. И все значения EPOCH находятся в пределах 10 дней. Хорошо.
Поэтому я предполагаю, что значение -6 - это очень маленький процент, и у sstablemetadata проблемы с его отображением. Итак, успех, правда? Но для удаления старых надгробий потребовалось полное уплотнение. Насколько мне известно, полное уплотнение - это всего лишь последний маневр по уклону.
Мои вопросы -
- Как я могу определить, является ли моя проблема здесь перекрывающимися sstables? Я не вижу другой причины, по которой данные не будут сжаты, если они не связаны с перекрытием.
- Как я могу разрешить перекрытие sstables без выполнения полного уплотнения? Боюсь, что это просто повторится через несколько недель. Я не хочу зацикливаться на регулярном выполнении полного уплотнения, чтобы не допустить надгробий.
- Каковы причины создания перекрывающихся конюшен? Это проблема дизайна данных или какая-то другая проблема?
Ваше здоровье.