Восстановление снимка Кассандры: случайные пропущенные данные

Мне трудно восстановить моментальный снимок на Apache Cassandra (версия 3.0.9). Насколько я могу сказать, я следую процедуре, описанной в блоге datastax, а также нескольким другим (например: http://datascale.io/cloning-cassandra-clusters-fast-way/). Тем не менее, я могу что-то упустить, и каждый раз, когда я делаю восстановление, данные отсутствуют.

Настройка: кластер из 6 узлов (1 DC, 3 стойки по 2 узла в каждом) с коэффициентом репликации, равным 3. Машины размещены на AWS.

Процедура резервного копирования (на каждом узле):

  1. nodetool snapshot mykeyspace
  2. cqlsh -e 'DESCRIBE KEYSPACE mykeyspace' > /tmp/mykeyspace.cql
  3. nodetool ring | grep "$(ifconfig | awk '/inet /{print $2}' | head -1)" | awk '{print $NF ","}' | xargs > /tmp/tokens

Я получаю файлы, созданные командой nodetool snapshot, и копирую их вместе с токенами и cql на S3.

Процедура восстановления (для каждого узла, если он не указан):

(после создания новых виртуальных машин)

  1. Скачать снимки, токены и ключи
  2. Остановить службу Кассандра
  3. удалять /var/lib/cassandra/commitlog/* а также /var/lib/cassandra/system/
  4. Вставьте токены в cassandra.yaml
  5. Запустить службу Кассандра
  6. Восстановить mykeyspace из mykeyspace.cql только на одном узле
  7. Дождитесь репликации и остановите службу Кассандра
  8. удалять .db файлы в папке /var/lib/cassandra/data/mykeyspace/
  9. Для каждой таблицы скопируйте файлы снимков (.db, .crc32, .txt) в /var/lib/cassandra/data/mykeyspace/$table/
  10. Перезапустите службу Кассандра
  11. Бежать nodetool repair mykeyspace -fullодин узел за раз

Результат:

Всегда есть пропущенные строки, примерно одинаковое количество для каждой таблицы, но никогда не одинаковые. Я попытался немного "перепутать" процедуру, такую ​​как восстановление пространства ключей перед токенами, запуск nodetool refresh до ремонта, но я встречаю одну и ту же проблему каждый раз.

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

Любая помощь будет приветствоваться:) Я могу, конечно, дать больше информации, если это необходимо.

редактировать: никто? Я обновил вопрос с версией Кассандры (3.0.9), которую я забыл в первую очередь. Я попытался снова восстановить, но не повезло. Я понятия не имею, на самом деле:(

Источник

2 ответа

Решение

Хорошо, конец истории, глупый я! initial_token строка в cassandra.yaml была ошибочно "отправлена" во время процедуры восстановления. Если после ":" нет пробела для initial_token ключ, то Кассандра не запускается. поэтому строка была прокомментирована, а токены не интерпретированы!

Tldr:

  • initial_token:<values> = НЕПРАВИЛЬНО
  • initial_token: <values> = ХОРОШО

Большое спасибо вам, Джош Первис, за то, что вы настаивали на высокой важности этого параметра:-)

Источник

sed Команда в этом сообщении в блоге, который должен добавить -Dcassandra.load_ring_state=false к $JVM_OPTS, не имеет никакого эффекта в его нынешнем виде.

Если вы копировали эту команду прямо из поста в блоге, возможно, это проблема. Вы можете попробовать это вместо этого, который помещает его в конец файла:

sudo sed -i '$ a\JVM_OPTS="$JVM_OPTS -Dcassandra.load_ring_state=false"' /etc/cassandra/cassandra-env.sh

Также вам нужно будет сделать nodetool repair -pr <ks> на каждом узле, один за другим, после выполнения этой процедуры.

Источник
Другие вопросы по тегам