Pull to refresh

Comments 23

А когда вы отключали ноды, вы одну оставили? Клиенты все к ней коннектились?
Простите, что отвечаю не сразу. Всё дело в разнице часовых поясов…

Я перезапускал по одной ноде за раз. Таким образом в кластере всегда было 4 рабочих ноды.
А в какой момент вы меняли нодам token range? Я правильно понимаю, что вы:
1. выключали ноду;
2. удаляли ей все файлы (кстати, просто через rm или как-то сложнее?);
3. включали ноду обратно в кластер, она затягивала данные, относящиеся к новому диапазону и начинала работать.

И задача была придумать такую последовательность отключений, чтобы ни один диапазон ключей не ушёл в оффлайн?
1 и 2 так и было. Потом нужно было сделать nodetool removetoken (описано тут). Иначе при включении старой ноды её узнают другие по IP-адресу и выдадут обратно старый участок кольца. Я это не проверял, но так сказали на семинаре.

После этого в конфиге на ноде выставлялся initialToken (в XML конфиге, у нас 0.6.x, в котором ещё XML). И я запускал сервис кассандры.

На счёт ухода диапазона в оффлайн — это не проблема как раз. Другие ноды это видят и принимают операции к себе, временно. И я даже видел, что это работает. С самой первой упашей нодой, после включения обратно после 15-минутного downtime на одной из других нод (кажется на следующей по кольцу) образовался файл в streams, который затем отправился на вернувушуюся ноду.

Проблема в том, что диапазон задаётся одним числом — границей конца диапазона. Поэтому чтобы получить сбалансированное кольцо надо было много раз перевтыкать ноды.

И ещё, это уже может быть моя паранойя, но я постоянно, когда после очередных перестановок все ноды включены, командовал nodetool repair. Это самая трудная команда. Известно, что в ней есть баги, нет никакой возможности узнать заверешилась ли починка. Зато известно, что нельзя одновременно чинить несколько нод. В общем я её запускал, ждал, глядя на статистику загрузки на всех нодах, и, когда мне казалось что починка закончилась, продолжал свои перестановки.

Вообще-то кусочек данных я всё-таки при этом потерял. Повезло, что это было в некритичной Column Family — кэше для данных из внешнего сервиса. Они повредились и возникала ошибка чтения. Кстати, при повреждённых данных я видел два разных эксепшена:
1. BufferUnderFlow — тут всё просто, мы получили два байта для int вместо четырёх и упали.
2. SocketTimeoutException на Read. Тут было сложнее, потому что сначала я думал, что эти эксепшены от перегрузки кластера, то есть реальный тайм аут. Но потом заметил, что эксепшен повторяется в 100% случаев для одних и тех же записей. Тогда появилась идея, что виновато повреждение данных, и удалил эти записи через консольный клиент.
Вот как. Спасибо огромное за обстоятельный ответ. Мы тоже делаем новый проект на Cassandra. Надо будет перед запуском все эти операции отрепетировать на тестовом стенде.
Ох, как много у меня к вам вопросов. Когда версию обновляли, надо было как-то базу данных конвертировать или формат совместим?
Формат совместим. Но есть опасность получить не совместимость по commitlog. Этом случае можно просто удалить его. Чтобы гарантировано избежать этого надо выполнить nodetool drain перед выключением — это запрешает write операции на ноде и довольно быстро (секунды) приводит к очищению commitlog.
Если перенести «Дао Cassandra» на абсолютно все продукты мы бы жили куда лучше
UFO landed and left these words here
Возможно меня ввели в заблуждение на семинаре. Семинар вели два человека: один всё время гвоорил, второй подключался в сложных местах и в ответах на сложные вопросы. В остальное время он писал код Cassandra (я заглядывал через плечо).
Когда долго с чем-то мучаешься и в итоге достигаешь нужного тебе результата, то по моему всегда "… ближе к концу процесса, получил удовольствие" ;)
Особенно когда «мучаешься» с «ломающеюся» девушкой :)
а зачем вам 5 нод, если сервис спокойно жил на одной (ну или на двух)?
Во-первых, в кластере не может быть меньше нод, чем Replication Factor. Минимальный рекомендуемый RF — 3. Это объясняется тем, что в случае проблем и порчей информации на одной ноде всё равно будет большинство нод с правильной информацией.

Во-вторых, сервера у нас неудачные, с маленькими жёсткими дисками и просто по объёму данных надо столько серверов. В нашем кластере ресурсы CPU и RAM избыточны, HDD недостаточно.

Следующий проект на Cassandra (который уже разработан, но ещё не запущен в продакшн) хостится в облаке. Как раз чтобы не было такого дисбаланса по ресурсам.
А то я изобрел велосипед с репликациями на бэк-сервера и прочими фигульками, дык может просто надо было взять Cassandr'у :)?
Ну просто я слабо себе представляю репликацию между 1800 mysql серверами… 8()
Ведь чисто по теории вероятности оно еще иногда и обламывается…
Насколько я знаю, Facebook больше не использует Cassandra вообще. Они используют HBase для тех задач, для которых раньше использовали Cassandra. Но я не в FB работаю, так что точно знать не могу.
на амазоне было бы намного проще. запустить пару новых серверов с новымы токенами и убрать старые сервера.
Именно! Мы учли этот опыт и в следующем проекте хостимся в облаке. Я об этом чуть выше в комментариях уже писал. Правда этот сервис ещё не скоро уйдёт в продакшен (в июне), так что про надёжность Cassandra в облаке я пока говорить не могу.
Извините за некрокоммент, но как надёжность кассандры в облаке? :)
присоединюсь ) было бы очень любопытно узнать о вашем опыте
Only those users with full accounts are able to leave comments. Log in, please.