Restauração de instantâneos Cassandra: dados perdidos aleatórios

5

Estou tendo dificuldade em restaurar o instantâneo no Apache Cassandra (versão 3.0.9). Até onde posso dizer, estou seguindo o procedimento descrito no blog do datastax, junto com vários outros (por exemplo: link ). No entanto, posso estar perdendo alguma coisa e, toda vez que faço uma restauração, faltam dados.

Configuração: Cluster de 6 nós (1 DC, 3 racks com 2 nós cada) com um fator de replicação definido como 3. As máquinas são hospedadas no AWS.

Procedimento de backup (em cada nó):

  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

Eu obtenho os arquivos gerados pelo comando nodetool snapshot e os faço backup junto com tokens e cql no S3.

Procedimento de restauração (para cada nó, a menos que seja especificado):

(depois de ter criado novas VMs)

  1. Download de instantâneos, tokens e espaço de chaves
  2. Parar serviço cassandra
  3. Excluir /var/lib/cassandra/commitlog/* e /var/lib/cassandra/system/
  4. Inserir tokens em cassandra.yaml
  5. Iniciar cassandra de serviço
  6. Restaurar mykeyspace de mykeyspace.cql apenas em um nó
  7. Aguarde replicação e pare a cassandra de serviço
  8. Excluir .db arquivos na pasta /var/lib/cassandra/data/mykeyspace/
  9. Para cada cópia de tabela, os arquivos de instantâneos ( .db , .crc32 , .txt ) em /var/lib/cassandra/data/mykeyspace/$table/
  10. Reinicie o serviço cassandra
  11. Executar nodetool repair mykeyspace -full , um nó por vez

Resultado:

Sempre faltam linhas, aproximadamente a mesma quantidade para cada tabela, mas nunca as mesmas. Eu tentei "misturar" um pouco o procedimento, como restaurar o espaço de chaves antes dos tokens, executando nodetool refresh antes do reparo, mas eu sempre encontro o mesmo problema.

Como não estou longe de ter uma restauração "boa", acho que estou perdendo algo bastante óbvio. Analisar os logs realmente não ajudou, já que eles não mostram nenhuma mensagem de erro / falha.

Qualquer ajuda seria bem-vinda :) Posso dar mais informações, se necessário.

editar: ninguém? Eu atualizei a questão com a versão cassandra (3.0.9), que eu esqueci em primeiro lugar. Eu tentei novamente para restaurar, mas sem sorte. Eu não tenho mais nenhuma ideia: (

    
por P. Bender 24.10.2016 / 17:59

2 respostas

0

Ok, fim da história, estúpido comigo! A linha initial_token em cassandra.yaml foi erroneamente "sedada" durante meu procedimento de restauração. Se não houver espaço após o ':' para a chave initial_token , a cassandra não será inicializada. portanto, a linha foi mantida comentada e os tokens não interpretados!

tldr:

  • initial_token:<values> = ERRADO
  • initial_token: <values> = GOOD

Muito obrigado a você Josh Purvis por insistir na alta importância deste parâmetro: -)

    
por 17.11.2016 / 11:38
0

O comando sed nessa postagem do blog, que deve anexar -Dcassandra.load_ring_state=false ao $JVM_OPTS , não tem efeito em sua forma atual.

Se você estivesse copiando esse comando diretamente da postagem do blog, é possível que esse seja o problema. Você pode tentar este em vez disso, colocando-o na parte inferior do arquivo:

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

Você também precisará fazer um nodetool repair -pr <ks> em cada nó, um por um, depois de seguir este procedimento.

    
por 11.11.2016 / 17:58