Кассандра: обслуговування

Я недосвідчений з Кассандрою, але маю певний досвід роботи з реляційними базами даних на основі SQL.

Мені не вдалося знайти інформацію щодо найкращих практик щодо того, як підтримувати Кассандру після розгортання. Чи потрібно VACUUM базувати дані? Я думаю, що навантаження читання / запису викликає фрагментацію у сховищі.

Або в цілому: які найкращі практики для підтримки розгортання виробництва Cassandra? Що потрібно робити через регулярні проміжки часу для підтримки здоров'я системи? Посібник з операцій дійсно не обговорює цей аспект.

Дякую.

Взагалі, добре розроблений кластер може жити протягом РОКІВ, не торкаючись його. У мене були кластери, які працювали протягом багатьох років. Однак ось декілька вказівок:

Моніторинг надзвичайно важливий:

1) Контролювати затримки. Використовуйте opscenter або ваші улюблені інструменти метрики для відстеження затримок. Зростання затримок може бути ознаками наступаючих проблем, включаючи паузи GC (частіше зустрічаються при завантаженні читання, ніж завантаження при записі), стійкі проблеми тощо.

2) Контроль стабільних підрахунків. Кількість SSTable збільшиться, якщо ви перевиконаєте ущільнення (кожен sstable пишеться рівно один раз - делетами обробляються комбінування старих sstables у нові sstables шляхом ущільнення).

3) Контролюйте зміни стану вузлів (вгору / вниз тощо). Якщо ви бачите, як вузли ляскають, досліджуйте, як це не нормально.

4) Слідкуйте за використанням свого диска - традиційно вам потрібно залишатись менше 50% (особливо якщо ви використовуєте ущільнення STCS).

Є кілька основних речей, які ви повинні і не повинні регулярно робити:

1) Не запускайте явно nodetool compact. Ви згадуєте, що ви це зробили, це не фатально, але це створює дуже великі сстабілі, які менше шанси брати участь у ущільненні, рухаючись вперед. Вам не обов’язково продовжувати працювати, але іноді це може допомогти позбутися видалених / перезаписаних даних.

2) nodetool repairзазвичай рекомендується кожні gc_grace_seconds(за замовчуванням 10 днів). Є навантаження, де це менш важливо - найбільша причина, з якої Ви потребуєте ремонту, полягає в тому, щоб маркери видалення ( tombstones) передавались до їх закінчення (вони існують gc_grace_seconds, якщо вузол не працює, коли видалення сталося, ці дані можуть повернутися до життя без ремонту!). Якщо ви не видаєте делетів і запитуєте з достатнім рівнем узгодженості (читає і пише в QUORUM, наприклад), ви можете реально жити життям без ремонту.

3) Якщо ви збираєтесь ремонтувати, подумайте про інкрементальний ремонт та ремонтуйте невеликі діапазони одночасно.

4) Стратегії ущільнення мають значення - багато. STCS чудово підходить для запису, LCS чудово підходить для читання. DTCS має деякі химерності.

5) Моделі даних мають значення - подібно до того, як середовища RDBMS / SQL потрапляють у проблеми, коли невкладені запити потрапляють у великі таблиці, Кассандра може бути проблематичною з дуже великими рядками / розділами.

6) Знімки дешеві. Дуже дешевий. Майже миттєві, жорсткі посилання, вони майже не коштують місця на диску. Використовуйте знімок перед оновленням версій, особливо основних версій.

7) Будьте обережні з делетами. Як натякнуто у №2, видалення створює більше даних на диску, а не звільняє їх НАЙДОЛЬШЕ gc_grace_seconds.

Коли все інше не вдається:

Я бачив статті, які говорять про те, що Cassandra in prod вимагає спеціальної голови для управління будь-яким розміром кластеру - я не знаю, що це обов'язково правда, але якщо ви стурбовані, ви можете взяти на роботу сторонніх консультантів (TheLastPickle, Pythian ) або мати контракт на підтримку (Datastax), щоб дати вам спокій.

Відповідно до документації з ремонту Кассандри , її nodetool repairслід виконувати в таких ситуаціях:

• Як найкраща практика, ви повинні планувати ремонт щотижня. Примітка: Якщо видалення ніколи не відбувається, вам слід запланувати регулярний ремонт. Майте на увазі, що встановлення стовпця на нуль - це видалення.
• Під час відновлення вузла. Наприклад, при поверненні вузла в кластер після відмови.
• На вузлах, що містять дані, які не читаються часто.
• Оновити дані на вимкненому вузлі.

Я думаю, що навантаження читання / запису викликає фрагментацію у сховищі.

Дані в Кассандрі не «фрагментуються» так, як ви думаєте. Однак видалення ініціює розміщення надгробків, і звичайний компактний процес усуває надгробні пам'ятники.

Зараз я розумію, що ущільнення - це велика справа і проходить автоматично

Правильно. Мені сказали представники DataStax, що коли ви запустите compactвручну, вам доведеться завжди запускати його вручну. Причина полягає в тому, що ущільнення працює за допомогою "ущільнення" всіх існуючих SSTABLES в просторі клавіш в єдиний файл SSTABLE. Можливо, у файлі SSTABLE, який є невеликим, і зайняти так багато часу, щоб перевищити поріг ущільнення, ймовірність автоматичного ущільнення повториться дуже низька.

По суті, переконайтеся, що заплануйте регулярний nodetool repair, ніколи не запускається nodetool compactта реалізуйте стратегію резервного копіювання (знімки, додаткові резервні копії або обидва).