2015-04-03 4 views
1

мы проводим тест Кассандры кластер из 8 узлов , работающих в одном DC с помощью простого стукач и DateTieredCompactionStrategy Cassandra Version 2.1.3 после добавления нового узла (девятой) в кластер мы см., что количество sstables на вновь подключенном сервере примерно равно сумме всех sstables на всех серверах в кластере. и это число огромно, как десятки тысяч sstables на вновь добавленном сервере.Огромного количества sstables после добавления сервера в существующий кластер

Вопрос 1: что мы должны ожидать?

Кроме того, новый сервер, похоже, не перегружен, в основном нет ожидающих/запланированных сборок, но количество sstables не уменьшается.

Q2: что может быть причиной не уменьшения количества sstables?

Q3: что нам нужно сделать, чтобы уменьшить количество sstables на сервер?

Спасибо за вашу помощь

+0

какой версии Кассандры? сколько sstables есть на других серверах? сколько ожидающих сбоев в разделе «nodetool compactionstats» –

+0

мы работаем 2.1.3 – Mantas

+0

Используете ли вы виртуальные узлы с таким же числом num_token? Когда вы выполняете «статус nodetool», как распределяются данные (собственный столбец)? Когда вы делаете «nodetool netstats» на новом узле, потоки заканчиваются? –

ответ

1

Это известно (неожиданный, но не удивительно) поведение в связи с конструкцией DTCs. Это произойдет каждый раз, если max_sstable_age_days находится ниже обрезания ttl. Это также произойдет, если вы удалите узел из кластера.

Я планирую обсуждать это на C * Summit 2015, если мой разговор будет принят, и я предложил альтернативный подход к DTCS в https://issues.apache.org/jira/browse/CASSANDRA-9666

+0

Спасибо, Джефф, это приятно знать. У меня также есть несколько CF, работающих на DTCS, но они уже вели себя. – Aaron

+0

И я просто проголосовал за ваш разговор. – Aaron

+1

Спасибо! Скажите привет на саммите. –

Смежные вопросы