Início / dba / Perguntas / 338035
Accepted
Stu
Asked: 2024-03-26 00:38:28 +0800 CST

Cassandra não replicará dados para o novo DC

  • 772

Tenho uma configuração Cassandra 3.11.4 de nó único em um datacenter.

Sei que isso é horrível e errado, então estou tentando consertar movendo os dados para uma configuração de 3 nós em outro datacenter.

Tirar um snapshot e copiá-lo significa muito tempo de inatividade, então estou tentando adicionar os 3 novos nós ao cluster e fazer com que o Cassandra replique os dados.

A estratégia para meu keyspace de usuário, bem como system_distributed, system_authe system_tracesé esta: {'class': 'NetworkTopologyStrategy', '(newdc)': '3', '(olddc)': '1'}

Todos os nós se veem corretamente (1 no antigo datacenter, 3 no novo). Todos os nós relatam UN. Todos os nós relatam 100% de propriedade efetiva. Posso consultar meu keyspace de qualquer nó e obter dados de volta. Há uma pasta para meu keyspace de usuário na pasta de dados nos novos nós, mas ela está vazia. Os novos nós mostram <1MB de carga, o que parece um pouco baixo em comparação com os 600GB+ do original.

Quando eu faço isso nodetool rebuild -- (olddc)em qualquer um dos novos nós, ele retorna quase imediatamente sem nenhuma mensagem. Esse é o comando que todos me dizem que deve realmente mover os dados, mas nada feito.

Como faço para que os dados sejam realmente replicados?

No log, eu obtenho Some ranges in (...all my ranges...) are already available, skipping streaming these ranges. Disponível sim, eu realmente gostaria que o nó tivesse os dados!

nodetool statusmostra isso:

Datacenter: (new)
==================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns (effective)  Host ID                               Rack
UN  XX.XXX.X.110  775.49 KiB  256          100.0%            XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  Unknown
UN  XX.XXX.X.109  929.93 KiB  256          100.0%            XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  Unknown
UN  XX.XXX.X.108  710.75 KiB  256          100.0%            XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  Unknown
Datacenter: (old)
=============================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns (effective)  Host ID                               Rack
UN  XXX.XX.X.233  676.17 GiB  256          100.0%            XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  Unknown

Reiniciei o nó antigo e agora nodetool rebuildme aparece isso:

nodetool: Unable to find sufficient sources for streaming range (-1652045364361720276,-1613609154633147610] in keyspace system_distributed

Reiniciei todos os nós novamente e tudo parece estar funcionando agora.

Parte disso parece ser porque o "cluster" original tem apenas um nó. NÃO FAÇA ISSO , eles não estão brincando quando dizem que as coisas vão mal quando você faz isso. Não é só redundância, as coisas simplesmente não funcionam direito.

A segunda parte parece ser uma conexão não confiável entre nossos data centers (ambos externos). Só porque seu provedor diz que você tem uma conexão gigabit sólida não significa que você deve acreditar neles.

Se você está lendo isso, pode estar tendo o mesmo problema.

Se estiver, leia todos os comentários e siga as excelentes sugestões do Mario para descartar outros problemas. Se você ainda estiver tendo esses mesmos problemas estranhos e intermitentes, seus passos são:

  • Reinicie todos os nós (ambos os datacenters) em rápida sucessão.
  • Aguarde 24 horas.
  • Reinicie todos os nós (ambos os datacenters) em rápida sucessão.
  • Aguarde 4 horas.
  • Tente novamente.

(Não vou responder a essa pergunta porque a "solução" é essencialmente equivalente a uma dança da chuva e totalmente insatisfatória.)

cassandra

1 respostas

  1. Best Answer

    O DC de nó único não é a causa raiz dos seus problemas. Com base nos sintomas que você descreveu, meu melhor palpite é que os novos nós não foram adicionados corretamente ao cluster.

    Por exemplo, se você (a) configurou os nós como uma semente E (b) não os definiu, auto_bootstrap: falseentão (c) eles teriam passado pela sequência de bootstrap normal sem nada transmitido porque (d) como um nó semente eles não têm nada para bootstrap, então (e) irão "se juntar automaticamente" ao cluster.

    Esta afirmação é uma pista crucial:

    No log, eu receboSome ranges in (...all my ranges...) are already available, skipping streaming these ranges.

    Isso significa que o nó acha que tem todos os dados necessários e, portanto, nodetool rebuildnão solicita réplicas para transmitir nenhum dado.

    Quando um nó pensa que foi inicializado com sucesso, ele marca todos os intervalos de tokens para todos os keyspaces como "disponíveis" na system.available_rangestabela ( system.available_ranges_v2em C* 4.0, CASSANDRA-14406 ). Para solicitar um novo fluxo de dados de réplicas com nodetool rebuild, você precisa excluir as entradas correspondentes em system.available_rangesou truncar a tabela.

    É importante notar que você continuará a ter outros problemas se a rede estiver instável. Esse é o mesmo motivo pelo qual você está recebendo Unable to find sufficient sources for streaming range .... Esse erro indica que a conexão com o nó no DC original foi interrompida. Saúde!

    • 1

relate perguntas