Назад | Перейти на главную страницу

Восстановление снимка Cassandra: случайные недостающие данные

Мне сложно восстановить снимок на 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. Запускаем сервис cassandra
  6. Восстановить mykeyspace из mykeyspace.cql только на одном узле
  7. Дождитесь репликации и остановите сервис cassandra
  8. Удалить .db файлы в папке /var/lib/cassandra/data/mykeyspace/
  9. Для каждой таблицы скопируйте файлы снимков (.db, .crc32, .txt) в /var/lib/cassandra/data/mykeyspace/$table/
  10. Перезапустить сервис cassandra
  11. Бегать nodetool repair mykeyspace -full, по одному узлу за раз

Результат:

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

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

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

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

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

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> на каждом узле, один за другим, после выполнения этой процедуры.