Eu tenho um cluster cassandra de 2 nós com um fator de replicação de 2 e AutoBootStrap = true. Tudo está bom durante a inicialização e os dois nós se vêem. Vamos chamar esses nós A e B.

Adicione um conjunto de chaves e colunas (vamos chamar esse conjunto K1) ao cassandra através do nó A.Conecte ao nó A e leia novamente o conjunto K1. O mesmo no nó B. Sucesso - bomMate o processo Cassandra no nó B.Adicione o conjunto K2 a A.Conecte-se ao nó A e leia o conjunto K2. BoaReinicie o processo Cassandra no nó B.Tente ler todas as teclas de B ... defina K1 presente, defina K2 MISSING. (Mesmo depois de 30 minutos)Adicione K3 a A / B.Leia todas as teclas de A - retorna os conjuntos K1, K2, K3Leia todas as teclas de B - retorna os conjuntos K1, K3.

B nunca sincroniza o conjunto K2 ... (já faz mais de 12 horas) Por que o nó B não vê o conjunto K2 ... alguém tem alguma idéia?

Informações Adicionadas :

Ok ... esse foi o problema. O read_consistency_level foi definido como 1 por padrão.

Portanto, quando solicitamos ao nó B o conjunto K2, e ele não o possui (quando deveria por causa do fator de replicação = 2), ele retorna imediatamente com um erro 'Não encontrado'.

No entanto, se usarmos a consistência de leitura para QUORUM ou ALL, B é forçado a perguntar A, que retorna o valor correto e B sincroniza essa chave (salva localmente).

Isso leva a outro problema - isso significa que, quando o nó B aparece, ele não está sincronizando todos os dados do nó A, mesmo depois de um longo tempo. Agora, se o nó A for desativado, como podemos acessar esses dados não sincronizados? (Acabei de testar que não podemos)

Eu acho que deve haver uma maneira de forçar a sincronização dos dados. Vejo o INFO na saída do terminal que ocorreu uma transferência sugerida de 15 linhas de A a B quando B apareceu, mas B não possui essas linhas localmente (porque ainda não podemos lê-lo em B com nível de consistência UM). Oque esta acontecendo aqui?