Início / dba / Perguntas / 335187
Accepted
adinas
Asked: 2024-01-25 17:50:11 +0800 CST

Login do Cassandra - AuthenticationFailed ... Não é possível realizar a autenticação: não é possível atingir o nível de consistência LOCAL_QUORUM

  • 772

Resumo: tenho um cluster de 2 nós e se um dos nós estiver inativo, não consigo fazer login. Eu recebo o erro.

Connection error: ('Unable to connect to any servers', {'192.168.1.104:9042': AuthenticationFailed('Failed to authenticate to 192.168.1.104:9042: Error from server: code=0100 [Bad credentials] message="Unable to perform authentication: Cannot achieve consistency level LOCAL_QUORUM"')})
  • Estou usando um ROLE que criei (não um SUEPRUSER, então o problema de SUPERUSER sempre usar QUORUM não deve se aplicar aqui. Pelo que li deveria usar LOCAL_ONE mas não é!
  • Eu configurei a replicação do keyspace system_auth para 2 propositalmente, pois isso é recomendado para não ter um único ponto de falha.

Aqui está uma captura de tela para mostrar que não estou usando o cassandra SUPERUSER e ainda estou recebendo o erro: insira a descrição da imagem aqui

Gostaria que o login continuasse funcionando mesmo se um nó estivesse inativo.

cassandra

2 respostas

  1. Primeiro, um cluster de 2 nós não é uma boa configuração de replicação para um nível de quorum, pois um valor de quorum de RF=2 seria sempre (2/2)+1=2. RF=3, em que cada nó de réplica é colocado em seu próprio rack, é sempre uma configuração inicial preferida, mas vamos deixar essa discussão de lado por enquanto.

    Você poderia forçar o nível de consistência por meio das opções CQLSH como abaixo,

    bin/cqlsh host:port --username=<user_name> --password=<password> --debug

    e, em seguida, aproveitar CONSISTENCY LOCAL_ONE;o shell fará com que você trabalhe com esse nível de consistência de leitura.

    Pude ver que o nível de consistência CQLSH padrão está LOCAL_ONEaqui para Cassandra®4.1.3 , a menos que você o reconfigure em outro lugar.

    • 1
  2. Best Answer

    Você está correto quando diz "Pelo que li, deveria usar LOCAL_ONE, mas não é!"

    Descobri que a documentação oficial de segurança do Cassandra 4.0 e 4.1 está desatualizada por faltar uma alteração na consistência de autenticação introduzida no Cassandra 4.0.

    No NEWS.txt você pode encontrar o seguinte na seção "Novos recursos" do Cassandra 4.0:

    As leituras e gravações de autenticação foram alteradas de uma combinação de ONE, LOCAL_ONE e QUORUM para LOCAL_QUORUM em leituras e EACH_QUORUM em gravações. Isso é configurável via cassandra.yaml com auth_read_consistency_level e auth_write_consistency_level respectivamente. Veja CASSANDRA-12988.

    Na documentação do Apache Cassandra para cassandra.yaml você pode encontrar as consistências padrão para leituras (LOCAL_QUORUM) e gravações (EACH_QUORUM) no keyspace system_auth.

    A boa notícia é que você pode configurar os respectivos níveis de consistência, ou pelo menos auth_read_consistency_level para LOCAL_ONE , em cassandra.yaml (verifique os links para leituras e gravações acima), reinicie o(s) nó(s) e então você poderá autenticar para cqlsh.

    Como observação lateral, nem todos os superusuários fazem login (ou costumavam fazê-lo) no QUORUM. Pelo menos até Cassandra 4, apenas o superusuário "cassandra" usava QUORUM. Todos os demais usuários, super ou não, autenticados com LOCAL_ONE. Ainda não testei, mas a partir da atualização do NEWS.txt presumo que a consistência configurada no yaml também se aplica ao superusuário "cassandra" do Cassandra 4 em diante.

    • 1

relate perguntas