Comments 23
А когда вы отключали ноды, вы одну оставили? Клиенты все к ней коннектились?
Простите, что отвечаю не сразу. Всё дело в разнице часовых поясов…
Я перезапускал по одной ноде за раз. Таким образом в кластере всегда было 4 рабочих ноды.
Я перезапускал по одной ноде за раз. Таким образом в кластере всегда было 4 рабочих ноды.
А в какой момент вы меняли нодам token range? Я правильно понимаю, что вы:
1. выключали ноду;
2. удаляли ей все файлы (кстати, просто через rm или как-то сложнее?);
3. включали ноду обратно в кластер, она затягивала данные, относящиеся к новому диапазону и начинала работать.
И задача была придумать такую последовательность отключений, чтобы ни один диапазон ключей не ушёл в оффлайн?
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% случаев для одних и тех же записей. Тогда появилась идея, что виновато повреждение данных, и удалил эти записи через консольный клиент.
После этого в конфиге на ноде выставлялся initialToken (в XML конфиге, у нас 0.6.x, в котором ещё XML). И я запускал сервис кассандры.
На счёт ухода диапазона в оффлайн — это не проблема как раз. Другие ноды это видят и принимают операции к себе, временно. И я даже видел, что это работает. С самой первой упашей нодой, после включения обратно после 15-минутного downtime на одной из других нод (кажется на следующей по кольцу) образовался файл в streams, который затем отправился на вернувушуюся ноду.
Проблема в том, что диапазон задаётся одним числом — границей конца диапазона. Поэтому чтобы получить сбалансированное кольцо надо было много раз перевтыкать ноды.
И ещё, это уже может быть моя паранойя, но я постоянно, когда после очередных перестановок все ноды включены, командовал nodetool repair. Это самая трудная команда. Известно, что в ней есть баги, нет никакой возможности узнать заверешилась ли починка. Зато известно, что нельзя одновременно чинить несколько нод. В общем я её запускал, ждал, глядя на статистику загрузки на всех нодах, и, когда мне казалось что починка закончилась, продолжал свои перестановки.
Вообще-то кусочек данных я всё-таки при этом потерял. Повезло, что это было в некритичной Column Family — кэше для данных из внешнего сервиса. Они повредились и возникала ошибка чтения. Кстати, при повреждённых данных я видел два разных эксепшена:
1. BufferUnderFlow — тут всё просто, мы получили два байта для int вместо четырёх и упали.
2. SocketTimeoutException на Read. Тут было сложнее, потому что сначала я думал, что эти эксепшены от перегрузки кластера, то есть реальный тайм аут. Но потом заметил, что эксепшен повторяется в 100% случаев для одних и тех же записей. Тогда появилась идея, что виновато повреждение данных, и удалил эти записи через консольный клиент.
Ох, как много у меня к вам вопросов. Когда версию обновляли, надо было как-то базу данных конвертировать или формат совместим?
Если перенести «Дао Cassandra» на абсолютно все продукты мы бы жили куда лучше
UFO just landed and posted this here
Когда долго с чем-то мучаешься и в итоге достигаешь нужного тебе результата, то по моему всегда "… ближе к концу процесса, получил удовольствие" ;)
а зачем вам 5 нод, если сервис спокойно жил на одной (ну или на двух)?
Во-первых, в кластере не может быть меньше нод, чем Replication Factor. Минимальный рекомендуемый RF — 3. Это объясняется тем, что в случае проблем и порчей информации на одной ноде всё равно будет большинство нод с правильной информацией.
Во-вторых, сервера у нас неудачные, с маленькими жёсткими дисками и просто по объёму данных надо столько серверов. В нашем кластере ресурсы CPU и RAM избыточны, HDD недостаточно.
Следующий проект на Cassandra (который уже разработан, но ещё не запущен в продакшн) хостится в облаке. Как раз чтобы не было такого дисбаланса по ресурсам.
Во-вторых, сервера у нас неудачные, с маленькими жёсткими дисками и просто по объёму данных надо столько серверов. В нашем кластере ресурсы CPU и RAM избыточны, HDD недостаточно.
Следующий проект на Cassandra (который уже разработан, но ещё не запущен в продакшн) хостится в облаке. Как раз чтобы не было такого дисбаланса по ресурсам.
Насчет facebook не понял, я вроде как вот здесь:
www.mysql.com/customers/view/?id=757
есть ссылка вот сюда:
perspectives.mvdirona.com/2008/04/22/1800MySQLServersWithTwoDBAs.aspx
Где говорится «Facebook is running 1,800 MySQL Servers»
Не поделитесь информацией, если кто знает более точно, все-таки Cassandra или mysql?
www.mysql.com/customers/view/?id=757
есть ссылка вот сюда:
perspectives.mvdirona.com/2008/04/22/1800MySQLServersWithTwoDBAs.aspx
Где говорится «Facebook is running 1,800 MySQL Servers»
Не поделитесь информацией, если кто знает более точно, все-таки Cassandra или mysql?
А то я изобрел велосипед с репликациями на бэк-сервера и прочими фигульками, дык может просто надо было взять Cassandr'у :)?
И то, и другое. И наверняка ещё много чего. В Facebook Cassandra используется для поиска по инбоксу. www.facebook.com/note.php?note_id=24413138919
Насколько я знаю, Facebook больше не использует Cassandra вообще. Они используют HBase для тех задач, для которых раньше использовали Cassandra. Но я не в FB работаю, так что точно знать не могу.
на амазоне было бы намного проще. запустить пару новых серверов с новымы токенами и убрать старые сервера.
Sign up to leave a comment.
Опыт спасения кластера Cassandra