есть кластер из 3х нод с RF=3, на 3.11.0. Для перехода на 3.11.1 там есть нюанс с материализованными представлениями. Что нас афектнуло. Соотвественно переделали чуть свои таблицы (DROP, Create). Но DROP materialized view не прошел и у кассандры что-то сбилось в логике. Я нагуглил как народ советует рестартануть кластер и типа все ок. Но по ошибке начал с сид ноды, и она не поднялась после растарта с матюком: INFO [main] 2018-01-17 11:37:46,847 ColumnFamilyStore.java:406 - Initializing our_keyspace.our_new_table Exception (java.lang.IllegalArgumentException) encountered during startup: Unknown CF a3d7a8f0-f9c6-11e7-afe2-eb56781b9354 java.lang.IllegalArgumentException: Unknown CF a3d7a8f0-f9c6-11e7-afe2-eb56781b9354 at org.apache.cassandra.db.Keyspace.getColumnFamilyStore(Keyspace.java:204) at org.apache.cassandra.db.view.ViewManager.addView(ViewManager.java:152) Сделав это на сид ноде я сам себя поставил в невыгодное положение. Беспокоюсь о том, что если сейчас я поменяю сида на другую ноду, то другая нода тоже может не стартануть и кластер развалится вообще. Поэтому хотелось бы совета бывалых. В том числе как мне с сида удалить корректно все данные на которые ругается, чтобы сид хотябы стартанул.

пиздани ваще /var/lib/cassandra/system/*

И да, тут где-то посередине запрятался jenkins =)

вам надо было дропать вьюхи и после грейда заново create’ить, имхо

кстати чисто девопсный вопросик... я вообщем давно уже считаю что создавать схемы данных должны клиенты (приложения) при коннекте к кластеру. Задача админа собственно только дать креды этому приложению. Мы собсно так это и раскатывали из-под k8s, но сегодняшний дебаг меня заставил призадуматься. Потому что может получатся что два клиента запровижинят одну и тужу схему. Кубер, конечно, их стартанет поочереди, но оба клиента могут решить что схемы еще нет (create if not exist не гарантия) Вообщем как быть.....брать опять на свои плечи создание схем, че-то не охото, но и и так жить нафиг нафиг.

понаблюдаю...может так звезды сложились, что был и дроп и креэйт

Не делайте git pull, делайте git fetch && git reset —hard origin/master

https://www.opennet.ru/opennews/art.shtml?num=47902

Не понятно, радоваться ли, что сделали хоть что-то без js, или негодовать, что использование нецелевое, и не на пользу юзера

это ж кассандра 😉 там все ноды равнозначные. Я, правда, не берусь пока утверждать что это 100% так, но даже с k8s strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 вполне возможно что при деплое первый клиент делает инициализацию быстренько (и уже отвечает на readyness probe что все ок), но схема не успевает отреплицироваться по всему кластеру, и тут второй клиент из репликисет такой стартует: "опа, да тут нет нужной мне схемы, создам ка" Кароче, тема для приличного инвестигейта. Можно затянуть, конечно, в архитектуру еще и очередь, чтобы на её базе делать лок, но как-то попахивает оверинженерингом. Вообщем, если у кого есть аргументированные кейсы, чтобы не провижинить схему данных в базы приложением - буду весьма благодарен

вы что-то путаете. Зукипер это отдельная тема.

датастакс помер, кстати 🙂

покажите эту настройку. https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/configCassandra_yaml.html

всем привет. есть у кого опыт анализа производительности по linux perf (perf_events) и networking подсистемы? столкнулся с тем, что дебаг ядро openvz, судя по perf, проводит много времени в tcp_write_xmit/tcp_ack сисколах, в топе стек трейса которых фигурирует save_stack вызовы. при этом swapper жрет 25% ресурсов из-за softirq, в топе опять же, tcp_ack.